I recently worked as a lead on a project which I thought was going well. The development team was working well together – they were building an application they were proud of and coding things quickly; The customers were happy – they liked the ideas and mockups we were showing them and I was giving them regular updates on what we were doing. All seemed to be ticking over nicely, but management were becoming increasingly unhappy and I couldn’t understand why. That was until one person said one phrase to me:

“Identify failure early”

A that point, it all became clear.

The problem that management had identified was that we were not getting things “Done” as quickly as we should have been and, as a team, were failing to see that as a problem.

The problem

The team knew the work that was coming up in the backlog – language translations, white labelling etc – so while we were implementing the requirements for our current backlog item, we were also allowing for those future requirements instead of adhering to the last responsible moment and only building what was required now.

That meant the team was happy because they were able to show that the application could do this and could do that, but in reality we had not delivered the basic requirements that were needed first.

In allowing for these future requirements it was delaying us delivering the current backlog item to the client, which meant the client was not able to “try it out” in live to see if it was having the effect that they thought it was going to.

Early point of failure

Delivering little and often is one of the fundamental rules in Agile. It is widely known that delivering little and often allows for a fast feedback loop so that you can fix problems and even change direction quickly, but the point that the team was missing is that it also allows us to identify failure earlier.

The product that we were working on was a new version of an existing product so we really needed to prove that it was worth investing the money instead of just carrying on with what they have got. If it did not prove a worthwhile investment, then the client needed the opportunity to stop work on it and invest the money on other features.

The sooner we can recognise a bad investment, the less money is wasted.

Working on what is required now

Since recognising what we were doing wrong we have felt like we have been flying through the work.

• The backlog items have become much easier to plan for because there are less unknowns and less background work to account for.
• The team has been able to better hit their commitments, which has been great for moral
• The customer has been even happier for getting more regular releases.
• And management has been happier for seeing things get “done”

We are still waiting to see whether the investment is a worthwhile one, but in the mean time we have found that by focusing on only what is required now we are actually achieving much more.