Failures drive agile transformation

An agile approach is a fail-quick approach. Failures - more than successes - are the bread and butter of agile transformation.

Every agile delivery organization goes through 4 failures in order to be successful.

1. We don't deliver enough

2. We have too many defects

3. We pick up too many features

4. A lot of our features are useless

These failures are inevitable and thus form a natural phasing of any agile transformation. That in itself is a strange finding. But even stranger is the sequence in which they occur. This sequence reveals the fifth failure, which we will discuss at the end of this article.

Note that the timelines below are indicative. And your company might do better. But in a lot of cases this timeline is even an optimistic scenario.

Failure 1 - If you set up an agile organization, don't expect too much working software in the first quarter. At quarter end a lot of tickets are ticked off, but those are mainly tasks. We are generally very good at being busy, but very bad at delivery. Agile provides tools to quickly identify this failure (DoD & Demos) but it takes at least a few sprints before a solution is envisaged. The reason is that the team goes through three stages of denial:

1. There is no problem
2. It's not my problem
3. I can't fix this

For example, suppose you end up in the 3rd sprint and find that only 20% of the user stories for Q1 are delivered. That's only 20% delivered when 50% of the quarter is gone; we're obviously in trouble. Yet, the team will fight this figure (there's no problem) arguing that the other 30% is 90% done. This 90% finalization rate is nonsense in delivery terms. Something is delivered or it is not. Then comes the blaming (not my problem) and then the flight of ownership (not my solution). Ultimately, a solution will be found by strictly respecting the DoD, descoping, strict demo rituals, making real user stories, etc. But at least 3 sprints or more are gone.

Failure 2 - In the best case scenario, you will have a more or less predictable delivery at the end of the first quarter. Still, most of the software can't go in production, because it contains too many bugs. For example, 1 out of 3 user stories contains a blocking or critical (UAT) bug. That bug rate is calculated in a straightforward way, but expect the team to go through the three stages of denial again. The solution is agile textbook: direct collaboration between developers and testers, but this insight takes time. The coach sets up some root cause analysis sessions and gives it a few sprints to sync in.

Failure 3 - By the end of the second quarter you will have a predictable delivery with a manageable number of bugs. In Q2, the coaches can also take a look at the feature level. Ideally, failure 3 and 4 are tackled before failure 1 and 2. But the chance of that happening is very small because of failure 5, which we will deal with at the end of the article. Your predictable delivery organization continues to falter because of an error in the upstream process: too many features are introduced. We now start the conversation between business and IT. You're right to say that we are 6 months late. But, hey, we had to wait until the issue was clearly on the table. For example, value stream A has a capacity of 10 features per quarter, but there are already 50 in the backlog for the next quarter. The problem is clear, yet also business and IT stakeholders need to go through the three stages of denial. The optimal outcome is a process of common prioritization and regular discussion between stakeholders based on clear capacity and demand figures. This provides much-needed end-to-end predictability. You’re at the end of Q3.

Failure 4 - And then it gets embarrassing. The coach calculates the added value of the delivered features. He uses analytics, reports, focus groups, etc… A lot of the new features appear to be useless. It turns out that the customer hardly clicks on these beautiful new pages, or we don't get the expected impact on conversion rate, etc. With these figures in hand the agile coach makes his most dangerous enemies. In many organizations, this failure may never surface, due to politics. But where it does, this is a trigger for a major cleaning. Useless features cost money to maintain and make the system unnecessarily complex. If the company recognizes this failure, capacity is made available for clearing this functional debt.

Looking at the failure sequence at the top, one must conclude that this is the world upside down. It would make more sense to first evaluate features for their usefulness (MVP, customer focus group, ...), then prioritize them and only then set up a delivery organization downstream that regularly delivers good quality software. And according to the agile textbook, this is the way forward. But reality is not driven by textbooks, but by everyday problems. People only change their way of working when a problem shows itself and not a moment earlier. Failure 5 is our inability to make a transformation based on reasonable arguments and rational planning. What is not felt in the day-to-day business does not exist, no matter what the textbook says. This is where an agile approach offers its greatest advantage. Agile starts from the assumption that certain failures are inevitable and even necessary to perform a transformation. Any sound agile approach offers tools to bring these failures to the surface as quickly as possible. It’s up to the coach to use them.

Do you recognize the above?