Categories
Agile Customer Success Digital Transformation Insights Lean Startup System Engineering

What Dev Teams Are Missing.

UX designers, check. QA designers, check. Developers, check. The list goes on… but most highly-trained dev teams are missing a vital piece of the puzzle.

Software development is an inherently technical activity but without solving a real human need a project has no purpose. So why are those with the most immediate needs, the arbiters of purpose in this instance, missing from the team?

Standard processes for software development demonstrate the issue (sometimes jovially).

@johncutlefish

Customers and end users, the foremost experts on the business and its goals, are the critical missing piece from software development.

Aren’t they included already?

Well, yes… but not enough.

Towards Customer-Centric Software Development: A Multiple-Case Study found that, even in organisations with a high level of customer focus, that customers were only present at the beginning and end of the development process.

The authors found four key challenges with this approach:

  • Indirect access to end-users led to a lack of understanding of the reasons behind customer requirements.
  • Feature prioritisation is done based on employees’ opinions and is not continuously validated with customers.
  • Testing is seen as an opportunity to identify defects but not to validate mismatches between customer needs and product offerings.
  • A lack of systematic ways to collect, analyse and incorporate customer data into the product development process.

What’s the real problem?

By omitting the customer and end-users from the delivery team you are working on hypothesis (and to some extent guess work).

Even projects undertaken with extensive and painstaking research are based on what a potential solution could look like. This hypothesis isn’t tested until the end of the development phase when complete features are presented to the users and customers.

And now for the grand reveal… The software has been built to the customer’s specifications, or has it been built to the team’s interpretation of the customer’s initial specifications? Without fully understanding the customer’s situation there is a high chance of building the wrong software.

This of course has a huge impact on budget, schedule and, worst of all, the trust between the client and team.

So how does putting the customer and users into the project team help?

Shortening feedback cycles is a central principle of Agile delivery. By embedding key stakeholders within the team, feedback cycles are reduced from weeks to days.

Developers can demonstrate early prototypes and benefit from the unique expertise and feedback that only customers and end users possess. Rather than thinking, “what would the customer want?” at key decision points they can be asked directly.

No grand reveals, no surprises. A product is developed in collaboration with the customer and ultimately the people that will be using it.

Customers and users are busy people – do they have two jobs now?

Obviously we can’t expect the customer to be turning in 40 hours a week, that would be slightly impractical (and rather unnecessary). Attending weekly team meetings and being able to respond to questions from the team is enough.

The point is to ensure the developer feels comfortable making a call to the customer or uses to clarify a requirement or gain feedback on an early version. Essentially, you remove the subjectivity and guesswork to ensure the right product is being built.

Sounds nice – does it really work?

Digital Village recently completed the first iteration of the Race Around Australia project and was rolled out for a successful pilot in NSW schools. Program manager Emily McLachlan was deeply involved in reviewing the work in progress and making critical feature decisions and prioritising application features.

Her involvement allowed the delivery team to frame technical decisions within the needs of the department, schools, teachers and students, which reduced uncertainty around the product to practically zero.

You can read about the project’s success here.

Next Steps

Convincing busy professionals to attend another meeting/ create time for the demands of a project team sounds, well, trick. In fact, the hardest part may be convincing people who feel somewhat out of their depth in a technical project to participate in delivering it.

With the right support, however, non-technical stakeholders like clients and end users can provide invaluable contributions to a project delivery team.

The first step, of course, is a conversation with project stakeholders. Luckily that conversation will be about how they can save money, reduce risk and enjoy the benefits of their new software as soon as possible. We have a suggestion…

Working closely with the customers means the team will share the customer’s disappointments and triumphs, and hopefully shifts the team’s mindset from focussing on feature delivery to customer success.

Categories
Insights library meetups

Why IT Projects Fail

What causes IT projects to fail & what does a successful project take?

Since the 1950’s, when humans started writing software and programming machines to do things, failure was common. It was also very expensive, but it was necessary. Most of the proceeding years were focused on improving the technology and it is a testament to humans of our capability, intelligence and dedication. I feel it is important to take a moment to stop and look at what humanity has achieved in terms of technology advancement.   ?

Jump to the present and the technology we have at our fingertips enables us to build amazing products and services and solve some serious problems as well as open up amazing opportunities for people and business. But now that we have the technology, the demand and expectation from markets (people) is pushing us to innovate more, build faster, be more efficient.  Makes you wonder where it ends or if it ever does.

However, now that we have the most advanced technology, this has not necessarily reflected in more successful projects. So makes you wonder, If technology is not the problem, then why do IT projects fail?

This month, at a Digital Village Meetup, we explored this question as a group. 

Session Outline

At Digital Village Meetups, we sometimes play a card game. The card game is simple; 6 decks of cards. Each deck representing a category, each card has a question or statement on it. A player rolls a dice, and picks up a card from the respective deck, reads it out, has a go at answering it and then the group discusses it.

In this session, we decided to focus on only one card from one deck and go deep on it as a group.

The original plan of the game was for each group to pick up a card from the deck without knowing what each other group selected. We did this to avoid group think, but we had rigged it so that each person would pick up a card with the same question on it (so we are all answering the same question without knowing).

BUT as each group came to select their card, they would dig into the deck so not to choose the card from the top (as we had planned to happen). The unpredictable nature of people set the tone for what was to come.

Once we broke into groups, each group spent 30 minutes coming up with a summary of their thoughts and ideas about the card they pulled from the deck. Below are the finding for each group:

Group 1:

Question Discussed: Why do IT Projects Fail?

Group 2:

Question Discussed: When running a project, what can you do to improve the feedback loop?

Group 3:

Question Discussed: Why do IT Projects Fail?

Group 4:

Question Discussed: Waterfall vs Agile?

Findings

As a collective group we discussed each groups findings and went deeper into peoples reasoning and experiences and explored what makes a successful project happen? The high-level results were:

Empathy & Attitude towards ‘right and wrong’ 

Of course culture is central to success but having a team culture and attitude and belief that “it is OK to fail, so Im not scared of experimenting and trying something new” is crucial for people to feel comfortable to be relaxed and be intuitive. However, there is a difference between it being OK to fail and and just being incompetent. The difference is in the learning. Were lessons learned and will that happen again?

Leadership

One thing that was obvious is that there needs to be one person holding the torch and keeping everyone aligned and heading in the right direction. This person is crucial to resolving issues and making sure that everybody understands each other. This person is a listener and a communicator and doesn’t necessarily have to be the most liked person in the team.

Process

Having a process in place makes things easier for everyone. So people know what to expect and they don’t ever feel lost about what is supposed to happen next. It gives a structure to something that is very peopley and soft.

Flexibility & Balance

An interesting observation was that there is not necessarily a ‘right’ or ‘wrong’ way to run a project. Agile vs Waterfall; it doesn’t matter and it is unhelpful to argue. It comes down to what is the best process and design for the project at hand.

Project Teams

However a proven structure of running teams is small, cross functioning teams. With complimentary skill sets and knowledge. The formation of the team is that of a group of 3-5 with one project leader. An example of a successful team structure is 3Wks, a software development firm which was acquired by GrowthOps in 2017. Project teams like this are well balanced in their individual capability and this gives a flexibility to solve most problems that are faced within a software project.

Conclusion

It was a lot of fun, but the general gist was humbling. The theme that kept being raised was PEOPLE.

#Peoplearecrazy. They are unpredictable. Everyone is unique and we cannot expect people to behave or think in a particular way.

The silver lining here, is that although the communication and  difference between people is the cause, if we combine these differences in a unified, harmonious and collaborative way, the outcomes are amazing.

This is why Design Thinking and related methods work so well. Because they extract and present each persons thoughts for others to see and understand.

What makes a successful IT Project?

Creating a common ground and shared understanding for all people around the same problem, solution, goal and outcome.

3wks, practiced a relatively unique project management method they designed to include all project stake holders in the development process. With a focus on outcomes that all people (tech and non-tech can understand, it is easier to keep people aligned on track and engaged in the project and the goal.

If you are interested in this process I highly recommend reading this book written by the 2 founders of 3wks; Beyond Agile.

Thanks for reading and hope to see you around the Village sometime soon.

Jason Hardie

Get Involved

See how DV runs Projects

Join the next monthly Meetup

Join the Village to work on a project

Engage Digital Village to run your project