Agile is Broken !

Why Agile?

For many years now introducing Agile has been one of the key priorities for a lot of organisations out there. After hearing great things about how Agile helped other companies transform and be quicker to react to market changes, many companies decided it was their turn to have a go at it.

Some people sold Agile internally as the way to minimise risks through the use of incremental developments - learning what you need as you go and always delivering value early. Some others saw it as the perfect opportunity to reduce the perceived bureaucracy associated with Waterfall project management and a path to simpler governance and practices.

Having said that, many companies took shortcuts when implementing Agile, and down the road realised it was not working as it should. To be fair, many companies still haven't realised where they went wrong. To exemplify this I will bring us back to the differences between Agile and Waterfall.

Agile vs Waterfall

The first thing that is important to be said is that they are different and none is better than the other - they simply function better depending on the situation or project you have at hand.

Perhaps the most significant principle of Agile is understanding its fixed and variable elements.

With Waterfall you have clear requirements to be delivered and the project deliverables only get signed off once these requirements have been met, even if that means taking longer and paying more than originally planned.

With Agile is the opposite, requirements might vary but whatever you deliver must be delivered on time and budget, no matter what. This means that you sometimes need to temporarily (or permanently) de-prioritise some of the requirements.

Prioritising Requirements in Agile

So how to you decide what needs to be delivered if you can't deliver everything on time and budget? Most of you are already aware of it, but it's important to review this element before we tackle how companies are breaking Agile.

In order to understand what requirements have higher priority, Agile uses the MoSCoW prioritisation model.

What this picture shows is that without the patty there is no burger, therefore it considers it to be a must. In other words, without it the project will fail or the customer will not sign off the delivery.

You then have the Shoulds, Coulds and Wonts. To know more you can go here.

One of the key aspects of Agile and MoSCoW is that no release should contain more than 60% of requirements classed as "Must". The general understanding is that if more than 60% of all requirements are Must, you are not being able to identify your priorities.

Once you set the requirements for your sprints and consequent releases, you need to have at least 40% of requirements not being critical (Shoulds, COulds), this way you can drop them from the release and bring them back to the backlog / drawing board - so you can revisit them when you plan the next sprints. This will allow you to reduce the workload for that sprint and still be able to deliver on time and budget. For many people this a concept that is hard to grasp, as it means not putting all your critical requirements to be released first.

In Agile DSDM they have something called Minimum Usable SubseT, which equates to your Musts. This is the minimum you should deliver to satisfy your customer. This is also known as MVP (minimum viable product).

In Scrum they also have a term called Minimum Marketable Product, which includes your Musts and some of your Shoulds. The MMP means this is above the absolute minimum and aims to achieve your customer's ultimate satisfaction / delight.

So how has Agile being broken?

Many companies are running multi-year programmes and end up adopting Waterfall in order to outline the benefits they want to realise and build a roadmap of when these benefits will be achieved.

Having said that, their IT departments use Agile methodology and work on the basis of incremental sprints, epics, etc. Often the Programme Manager maps the sprints and epics to the key high-level requirements the programme wants to achieve (benefits to be realised) so it is easier for senior management to translate Agile into a high level plan they can understand.

The problem starts when the IT team starts developing their releases consisting almost completely of "Must" requirements and call this the MVP for that business need. As a consequence of having way more than 60% of Must requirements they will have very little (or nothing) they can drop in order to achieve that release on time and budget, should they face any issues. This is what I call the "Antichrist of Agile".

What happens in the end? Agile releases end up being delayed and costing more than originally intended - which completely defeats the purpose of adopting Agile. Yes, many people might call it WAgile, the crossover between the two concepts, but in many ways this example I highlight ends up taking on the worst of both worlds: not planning ahead and having schedule and budget overruns.

Many people might say you don't need to follow Agile "by the book". Having said that, what is the benefit of doing things this way and removing "bureaucracy" in favour of a situation where you still have the same issues you had with Waterfall?

If you face this same scenario, you might want to review the reasons why your organisation uses Agile and understand if it is still worthwhile and delivering enough value. If you have "time critical" deliverables in your projects, I would highly recommend you fix your broken Agile processes before going any further.

What are your thoughts?