When Agile is not working, ask this ….

Agile project management contains many excellent ideas, which can and should make a real positive difference in the delivery of projects.

However, as is often the case when new ideas come along that seem to show great promise, the reality falls a long way short of the promise.

What we are seeing more and more:

We are working more and more often with organisations who have tried to implement Agile, not having been brought in ourselves to discuss Agile, but that’s what we end up doing.

In short, we find that people are struggling, and when you start to talk to them about what they are actually doing, it usually highlights fundamental flaws in the interpretation of Agile – often many.

At this point, we have to hold up our hands and say that this usually happens after they have selected and paid for a consulting or training firm to come in and show them how to do Agile. They may have spent considerable effort and money making the change, so what they really need to hear having already done so does not always go down very well.

Recent Examples:

In the past 4 weeks, I have worked with two separate businesses that have moved to Agile, and with both clients, a quick conversation revealed some serious weaknesses, and it’s not around Story Points or Scrums, even though these can through up some challenges and issues.

It is around areas such as how you combine the right level of ‘planning’ (or in truth I should say definition) of projects to be delivered using Agile, with a more Agile approach at all stages. It is easy to see that many organisations have been given dangerous messages such as “we don’t need to do that (old fashioned) stuff anymore; Agile is flexible and we will work all that out along the way”.

This is a fundamental error. Scrums and Sprints are simply mechanisms for collaborative decision-making and allocation of development effort and tasks in a (hopefully) highly structured but flexible way.  You still need to understand and agree on the goal of the project and what, in business terms, it is trying to achieve.

Projects should never start with a Product Backlog!

The whole project team still needs to understand things like fundamentally, why we are doing this project on behalf of the business, Sponsor or Customer. If that information is not apparent to all, the end result (in terms of outcome and deliverables) can and most likely will still fall far short of the mark.

In the examples I have seen in the past few weeks that’s exactly what is happening on dozens of projects – and these are not small businesses. They are executing many important projects, and delivery performance (as judged by the internal customers of one of these businesses at least) has actually got worse, not better.

Know what to use and when:

The other thing we see is rigid and incorrect interpretations of what you do using Sprints and Scrums.

Whether the end client has misinterpreted what they have been told, or their consult/trainer just was not up to the task, I don’t know. I suspect it is more often the latter, given the freshness of Agile still in business.

One example was planning poker – one customer was doing this for every story point, on a group basis. A huge overhead and not always necessary. Planning poker is not new at all – it was borrowed straight from an Estimating method (Delphi) developed in the 1940s, intended to be used only where there is major uncertainty around specific items to be estimated, not on every single item.

Another major issue can be sprint planning. It is a fine balance between involving too many and the wrong people in doing this, making it ineffective, cumbersome and expensive. Once again, someone who is really experienced and has a track record already in successful project delivery is unlikely to make such errors.  The Sprint planning process should involve the right people at each step – not necessarily everyone at every step.

There is a huge benefit if you get things right:

Agile can work really well and potentially represents the most effective development environment you can have. Agile is about collaboration, communication, team work, flexibility and transparency.

Scrums and Sprints are important but on their own, they do not necessarily give you an Agile project at all.

In the worst case, implementing Sprints and Scrum and tossing aside the fundamentally important decision-making and formalisation of projects, will be a huge step backwards.

And if you get yourself someone to help you with Scrum or Agile, make sure they understand fundamentally what’s important in projects, and have not just earned themselves a ‘certificate’ after a few days training somewhere and now call themselves an ‘expert’.