Agile Abandonment Syndrome is a phenomenon where—after implementing agile practices and seeing direct evidence of their benefits—a company stops improving, its agile behaviors degrade, and ultimately loses market share or productivity. We have seen this in many companies.
I am researching Agile Abandonment with Scott Downey. Our research seeks to establish common root causes of agile abandonment, and to propose practices that reduce the chances of agile abandonment.
Create a Root Cause Map
When a failure occurs, such as agile abandonment, I use Root Cause Maps to reveal the “Five Whys” that caused the failure. When created with colleagues, it becomes both a social exercise, and a way to reinforce a culture of continuous improvement.
- Assemble the relevant parties involved in the failure. If everyone is physically present, bring them together around a large white board. Otherwise, use an online conferencing system, such as GoToMeeting and use an application like OmniGraffle or Visio.
- Puts the obvious failure in a node at the center of the board.
- In succession, call on attendees to state something that caused a named problem on the screen. “Why did the named problem occur?”
- Create a new node for the newly stated cause, and draw an arrow to the problem. The cause now becomes another problem to consider.
- After talking to each person once, a map starts to emerge. Sometimes something causes multiple problems, in which case that node has many arrows leaving it.
- Keep iterating until a linear chain of “Five Whys” appears somewhere in the graph, or until attendees run out of causes.
- Then help the team examine the map to find causes that could have been easily prevented. Using those preventable causes, put together a mitigation plan, in the form of an A3 [citation].
The following graph shows an example of such a Root Cause Map.
- Abandonment Map Iteration 1
Through conversations with Pat Reed, Jeff Sutherland, Charlie Rudd and Scott Downey, I created this root cause map as an iteration and demonstration.
Examine chains of five whys
According to Toyota’s Five Whys method of failure analysis, before we can feel comfortable that we have thoroughly examined a failure, we must generate at least one chain of five reasons the failure occurred. Let’s try this on our graph to find a possible root cause.
1 Lost key leader → Agility Lost
The obvious problem is “Agility Lost.” Why was agility lost? Because the organization lost an agile leader.
2 Replacement not agile → Lost key leader
The organization lost an agile leader. Why did that cause loss of agility? Because the replacement leader did not support agile.
3 Hiring managers chose poorly → Replacement not agile
The replacement was not agile. Why? Because even though the company says it supports agile, hiring managers chose a non-agile candidate to hire.
4 Management culture is not agile → Hiring managers chose poorly
Hiring managers chose poorly. How is that possible? One possibility is that the management culture does not value agility.
5 Managers do not practice agile → Management culture is not agile
Management culture is not agile. How could this happen in a company where developer teams are agile? One possible answer is that the managers do not practice agile, and thus have no direct agile experience to help gauge the skills of a candidate.
It could be easy to get managers to practice agile, and thus avoid this problem: We could put together management scrum teams, whose seek to remove productivity impediments in the company. This would give all managers the experience and culture to find new hires, should the need arise, who will sustain our agile gains.
This post did three things:
- It shared our early thinking about Agile Abandonment.
- It illustrated the Root Cause Mapping strategy of failure analysis.
- It showed how Root Cause Maps reveal Five Whys chains and expose possible preventions.
As we continue working on the project, we intend to add the experiences of others, better analyze the causes of agile abandonment and consider mitigation steps to help companies avoid agile abandonment or start agile recovery.
If you have thoughts on this topic, please comment.