“Failure is not fatal, but failure to change might be.”
I often think about patterns of success and failure in life. What is it about certain people, teams, and organizations that make them successful over others? Why do others, despite seemingly good intentions, fail? Is there anything we can learn from these failures?
As a coach and consultant of Agile change efforts, I am always on the lookout for patterns of success and failure. As in most other areas of life, I’ve seen that success with Agile requires a lot of hard work and that it helps to have someone with deep experience coaching you along the way. And similarly, I’ve seen that there are nearly endless opportunities for failure. Of course, this shouldn’t be surprising – an Agile change effort is fairly significant as it involves the complex intersection of many people, processes and tools. That’s messy!
But while there may be many different ways such an initiative could fail, there is one pattern of failure I have seen and heard of so often that it is worthy of the label, “The Failed Agile Adoption Pattern”. It is so common that I believe it needs to be more widely acknowledged and accounted for by all partaking in an Agile change initiative.
The pattern looks like this:
- Workers are largely disengaged
- Agile Adoption is dictated from the top down
- Minimum (Not So) Viable Process is implemented
- Inspecting and Adapting rarely or never occurs
- Few if any tangible benefits are realized
Let’s explore each of these steps in a little more detail.
Step 1: Workers Are Largely Disengaged
Gallup’s “State of the American Workplace” in 2013 showed that 7 out of every 10 workers are disengaged at work. Only 30% admit to being fully engaged at work, while 52% admit to being disengaged, and an astonishing 18% admit to being actively disengaged. Think about that. Potentially 20% of your organization is knowingly acting in ways that are counterproductive to the organization’s goals.
If you were thinking Step 1 of this pattern didn’t apply to your organization’s Agile initiative, you were likely wrong.
And that’s where the failure pattern begins – lack of awareness of this problem, lack of willingness to admit this problem is real and is affecting your organization, or lack of willingness to dig into and address this problem.
Step 2: Agile Adoption Is Dictated From The Top Down
For any number of good reasons, management decides the organization needs to pursue Agile. Unfortunately, management often sees this as primarily a team-level pursuit and so instructs those below them to “adopt Agile”. Their presence and engagement is limited to the kickoff of the initiative while the teams are left to struggle with the challenges of the change effort.
There are two main problems with this approach:
First, your workers are already disengaged. Major change initiatives will likely be met with cynicism, if not outright, active resistance.
Second, Agile is not simply a “process for the developers and testers to adopt.” Agile will eventually require you to rethink everything from project, program and portfolio management, to staffing, to team design, to organizational alignment, to performance management, to budgeting, and beyond. Agile is a transformative journey and therefore requires active, engaged leadership from those with the positional power required to enact real change. Anything less than fully active engagement from management and the chances of success will be greatly reduced.
Even at this early point, the failure of the initiative is already highly likely. It is not the final nail in the coffin though as I have seen some cases where the principles of Agile brought about a renewed sense of autonomy, purpose, and mastery and thereby increased worker engagement. This increased engagement was enough for the organization to realize moderate team-level success. It should be noted however that these were outlier cases and the success was constrained.
Step 3: Minimum (Not So) Viable Process Is Implemented
Step 3 is the natural outcome of the previous two steps. When the workers realize that management is not willing to bear the burdens of change alongside them and actively lead, they will do the bare minimum necessary for management to be convinced the teams are “doing Agile now”. In some cases, they will actively resist and try to torpedo the initiative. Yes, this is insubordination. And, yes, I’ve seen it happen more than once.
The irony of this step is that the workers determining which practices to keep and which to throw out are the ones least qualified to make such decisions. In fact, even highly experienced Agilists tread carefully when altering known, proven frameworks and methods.
Step 4: Inspecting and Adapting rarely or never occurs
As Amber Deibert recently illuminated in her post, “Steering the Agile Ship”, a foundational principle of Agile is the need for frequent inspection of results and adaptation in order to continue improving. This cycle of inspecting and adapting cuts across both your product(s) and your process. The idea is that Agile is not so much of a destination. It is not a new process or tool you simply install, wipe your hands of, and declare, “Done!” It is more akin to an endless journey, a pursuit of a better state than where you were yesterday, a week ago, a month ago. It is animated by the guiding thought that “we can always do better.”
Unfortunately, for teams and organizations that have progressed through the first three states, this fourth state is almost guaranteed to happen. Inspecting can feel like a waste of time for those unaccustomed to regularly reflecting on their work despite research demonstrating an average of 20% performance improvements. And adapting often requires team empowerment and/or positional power to apply changes to team and organizational processes. So this part of Agile gets tossed overboard early and often. And it is usually the final nail in the coffin.
If you are currently in this state, you can be rescued through a renewed engagement of management and a vigorous commitment to frequent inspecting and adapting. But this is no small task and will usually require outside expertise (i.e. self-rescue is very difficult).
Step 5: Few if any tangible benefits are realized
Lacking an awareness of the actual root problems of the change effort, an organization having progressed through the first four steps will eventually come to believe that Agile must be a fad or that they were too unique for Agile to apply to them. Failing to see any tangible benefits they will proclaim that Agile failed. The sad reality though is just the opposite – it was their own efforts that led to the failure. In fact, most any other process, tool or methodology requiring significant change in their organization would be just as likely to fail.
In closing, there is an underlying, false belief embedded in this pattern that sets an organization up for failure from the beginning. It is the difference between an Agile adoption and an Agile transformation. Adoption implies installing and following a new process or practice whereas transformation implies leaving the old and becoming something completely new and different. Transformation speaks not just to the mechanics (process & practice) of how we work, but ultimately to how we think and talk about the work. We should look, feel, think and act fundamentally different. It might be like deciding to radically change your golf swing (transformation) versus buying a new driver (adoption).
If we understand this difference, it will lead us to think and act in much different ways than the five steps in this pattern. And that would be a much better place to start an Agile journey.
Have you seen this pattern of failure before or similar ones? Are you potentially in the middle of such a pattern right now? We would love to hear from you – please join in the conversation by commenting here or on twitter @joshfruit and @SolutionsIQ.