When Agile causes Product Debt

Agile is meant to minimize wastage. But today, misguided use of Agile has become one of the leading causes of Product Debt.

In fact, it's not the Agile methodologies per se that are at fault. It's the illusion of adopting Agile methodologies which is the true root cause of product evil.

The illusion of adopting Agile practices

It states that:

• We misunderstand the teachings of Agile Methodologies.
• This leads to a flawed, misguided, and superficial adoption of the underlying practices.
• We remain oblivious to this fact and continue believing we are following Agile even when we are not.

Let’s see why and how this happens.

Agile teaches us ‘iterations’

Agile at its core states that “Good products are built through multiple iterations and not in a single go”.

Eric Ries, the author of the blazingly popular book, ‘The Lean Startup’, championed that each iteration consists of 3 distinct phases:

What we do:

1. We take a look at the set of Product Features we want to ship out.
2. Look at the deadline.
3. See the available Engineering bandwidth.
4. Marry the 3 together to try and create iterations based upon what is possible to be delivered in the given timeline, with the available resources.

What this leads to:

1. We tend to lose sight of customer value.
2. We ignore the ‘Pareto Principle’ which states “80% of your customers will use only 20% of your features”. When we form iterations solely based upon bandwidth, we might actually end up working majorly on the 80% of the features that the customers might seldom use.
3. We (unsurprisingly) struggle to build traction.

What we should do:

The sole goal of an iteration is to validate the biggest assumptions and hypotheses. Nothing else.

Every product is built on top of certain assumptions and hypotheses. Some of them are more dangerous than others. Through iterations, we want to test the biggest and the most threatening assumptions and hypotheses as early as possible.

The MoSCoW Prioritization model is perfect for this. It directs us to break down our Product Features into the following categories:

1. Must-have (M): These are the absolute non-negotiable needs that have to be a part of the product. The Must-haves encompass the most threatening assumptions and hypotheses. If proven to be wrong, they could kill the entire product and hence they should be validated as early as possible.
2. Should-have (S): These product needs are not vital, but they add significant value. In contrast to the Must-haves, the Should-haves hold the less menacing assumptions and hypotheses. These assumptions and hypotheses are not life-threatening to the product but may demand noteworthy effort.
3. Could-have ( C ): These are nice to have initiatives. Non-critical, less impactful.
4. Will-not-have (W): Things that will not be added to the product. It’s important to make a note of what the product is going to be and what it is NOT going to be. This is important to avoid scope creep and to ensure that we do not lose sight of customer value.

We should associate our iterations with the different MoSCoW stages. Start by creating iterations from Must-have. Only once our iterations have validated the underlying assumptions and hypotheses of the Must-have stage, we can move over to the Should-have stage, and so on.

With this, we do not lose sight of Customer Value. We are also able to follow the Pareto Principle to continue focusing on the mission-critical, 20% features. We are thus more likely to build traction.

Hence, we should be careful not to associate our iterations with Engineering bandwidth, but rather associate them with the assumptions and hypotheses we wish to validate.

2. Iterations are NOT Sprints. An iteration means go-live

What we do:

We tend to believe that just because our product is being built through Agile Sprints, it is safe to conclude we are following Agile practices.

In such cases, a major product feature might take a long period of time before it goes live, but because it was being built through Agile Sprints during this time, we continued to believe we were Agile.

What we fail to see is, this is only the Build phase of our iteration. An iteration is not complete till we have gone through the Measure and Learn phases as well.

Marty Cagan has said this very well in his book, ‘Inspired’. He says:

While almost everyone today claims to be Agile, in all fairness, the only one following agile is the Engineering team. The rest of the process in product building is still waterfall. — Marty Cagan

What this leads to:

1. Measuring and Learning happen too late, in the very end. By this time, it is difficult to correct the course.
2. We are actually following a waterfall model and suffering its consequences.

What we should do:

Remember that there are 3 phases in an iteration and we can only enter the Measure and Learn phase once the product goes live.

Therefore, we should create our iterations based upon how we plan to go live, and what assumptions and hypotheses we wish to validate with each release.

Iterations thus, do not simply mean following Agile Sprints. In fact, it’s not an iteration until it goes live.

3. Iterations should NOT be abandoned. They should be concluded.

What we do:

Often the Iteration-1 of a product or a major product feature is extremely lean because it's an MVP(Minimum Viable Product). Here the goal, as we saw earlier, is to validate the most dangerous assumptions and hypotheses.

It is thus natural to include only the bare-bones skeleton in this Iteration-1 with the promise of fleshing it out in the next iteration.

However, it is common for the Build phase of Iteration-1 to span over a couple of months, and during this time the following factors tend to change:

1. Competitive forces. A competitor might launch a new product or a major feature that creates buzz and pushes the market dynamics.
2. Business goals. Most product companies follow a quarterly OKR cycle and thus by the time the Iteration-1 goes live and enters the Measure and Learn stage, we might be putting together next quarter OKRs that are aligned over different Business goals.
3. New ideas. As humans, we love building newer things. Thus, if and when we encounter a different customer problem or a new idea, it is quite easy and even natural to get excited about it.

These factors, though legitimate, might cause our interest in the current Iteration to wane out.

What this leads to:

As Product Managers, we shipped out a skeleton with the promise of fleshing it out once the underlying assumptions and hypotheses are proven to be valid.

However, since we might now either be chasing down a competitor, targeting different business goals, or even excited about a new problem statement, we have a tendency to:

1. Dismiss the Measure and Learn stage completely. Here we do not try to see if the Iteration-1 was able to hit the right success metrics or not. We simply pushed the iteration out and never checked on its performance. Sounds extreme, but this happens more often than we would like to admit.
2. Draw learnings for Iteration-2 but do not prioritize it. From the Learning phase of Iteration-1, we discovered what we need to do in Iteration-2, but we did not initiate it. We often label it as bandwidth issues. In reality, it's a lack of prioritization.

Nevertheless, there is now a subpar product offering that our customers continue interacting with and they keep getting disgruntled. Some of their feedback might eventually reach us, but by then, it could be too late to set things right.

What we should do:

Agile is not a license to build subpar products

Once an iteration goes live, it will end up in one of these states:

1. Finalize. The iteration was well received by the users. It also seems from the collected data(quantitative and qualitative), that no further work is needed. Users are deriving value and are happy with what we have released.
2. Optimize. The iteration itself was not well received. From the collected data, we know what needs to be worked upon. We will now begin the next iteration fueled by these learnings.
3. Maximize. The iteration was well received. It validates our hypotheses and assumptions. We now have the proof-in-the-pudding to initiate our next iteration as per the initial plan, for improving the overall product offering.
4. Retire. The iteration was not well received because our underlying hypotheses and assumptions were proven to be wrong. We will neither try to optimize nor maximize it. We will retract it from the market.

The phases can be put together in a 2x2 grid as follows: