A cure to "Welcome Changing Requirements" misbehavior

The second Agile Principle states, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”?

This principle is often misused in the name of agility.

[Case 1]?

Imagine the product team changing the requirements on the seventh day of the iteration (the sprint). Under pressure, the development team forcibly accepts and completes the change and labels themselves Agile. With their exceptional skills, they measure the story points of this change and record them as ‘story points added’ metrics. This cycle of forced changes repeats with no end in sight, leading to a sense of frustration.        

[Case 2]?

In another scenario, the market research team conducts exceptional research on a new feature. If this feature is released quickly, it could give the organization a competitive edge. The product team asks the developers to stop their current work, switch their focus immediately, and start working on this new idea. While everyone praises the immediate switch to the new work, the resulting waste from the aborted (later discarded) work goes unnoticed. Consequently, the leaders attribute reduced team productivity to this situation and suggest reorganization.        

Many such examples create a “un” agile culture and give the impression that agile is merely a power game.?

The individual with more power to demonstrate value will have their requirements prioritized. They anticipate the team to immediately shift their focus to a new piece of work, as the second principle of agile states, “Welcome changing requirements, even late in the development.”

Prevention and Cure using?Kanban

However, there is prevention and a cure for such behavior. It all started in the 1940s with Taiichi Ohno, who created the first Kanban System. Later, in 2004, David Anderson pioneered the Kanban method for knowledge work management.?

This approach follows a simple model: Visualize, Isolate, Measure, Improve, and repeat. I will keep this discussion short for this article.

Applying the?model

Visualizing, isolating, and improving can improve both the above case studies and many more such anti-patterns. Let me explain it briefly.

[For Case 1]

Put an identifier on all the requirements the product team wanted to change.        

[For Case 2]

Create a separate swimlane or “Abort Work” column. Move all the “Aborted” work to accommodate the research team’s new phenomenal feature.        

This visualization will make all such work transparent to all stakeholders. It will help visualize why the work is delayed and which work went through a requirement change.

Measure:

[For Case 1]

Measure the cycle time (a.k.a lead time) for all the completed requirements. Identify the additional time to address the requirement change?—?plot using the lead time distribution curve or cycle time plotter.        

[For Case 2]

Measure the Abort Rate (% of the work aborted vs completed over a period of time). Measure the time spent in the Abort swimlane/column. Measure the cycle time from Start to Abort. If re-started, measure the cycle time from Abort to Complete.        

This measurement will help you collect and prepare the metrics needed to identify improvement areas. It is based on actual time spent, not estimates. The more data there is, the better the predictability.

Improve:

First, "limit" the capacity by limiting the "Work in Progress". An overburdened team tends to create poor-quality outcomes under the pressure of timelines.

Then,

[For Case 1]

Identify the increase in the cycle time due to changing the requirements during the development. Understand the root cause that leads to a change in the requirement. If this root cause is out of control, create a different work type?—?“floating requirement work.” Set the expectations that “floating requirement work” can lead to increased cycle time. Or create a separate class of service to identify such type of work. Analyze and manage the demand of such type of work and accordingly allocate the capacity to complete it.        

[For Case 2]

Measure the waste generated due to the aborted work. Measure the loss in productivity due to the context switch from the current work in progress to the new phenomenal feature. Develop a cost-benefit analysis. If it is profitable, find ways to avoid such waste (e.g., Should we byte size the new requirements so that we do not need to abort them?). If it is not profitable, find ways to improve upstream processes (requirement research and detailing) and “start finishing, stop starting.”        

All the above practices can generate a multi-fold improvement if you start thinking outside the loop/iteration. Consider work as a “flow”. Unlearn working in an iteration and delivering increments your customers/stakeholders cannot use. Learn to create value for your customers and not for your QA team, Dev team, or UX team.?

"Agility" is delivering a valuable (that customers can use) product/service at the right time (when it is ready) and not in a loop. Apply Kanban practices and principles to improve the quality of the deliverables and the team's motivation. Kanban will help you adopt a service-orientation approach with better sustainability and survivability.