Are You Failing the Agile Test?
I’m often asked, by clients, by colleagues, and by other coaches, what I see is the biggest reason behind failed Scrum adoptions. I’ve come to realize that it all comes down to the people who are entrusted with guiding the transformation not understanding that they’re actually facing a test; will they face their problems and fix them? This lack of understanding results in either ineffective action that doesn’t address the problem, or no action. I have coined a term to describe this situation, when leaders are facing a decision, called the ‘Agile Test,’ because the Agile approaches don’t solve your problems, they expose them and test you to solve them. The Agile Test is really a way of asking if you realize you need to apply inspect-and-adapt to your processes, and if so, are you doing so in an organized, methodical way. In short, asking if you’re learning and improving.[1]
In this first of two articles on the subject, I’m going to go into more detail on the Agile Test, why understanding when you are being tested matters, and give you a high-level approach to pass the test. In the second article, “Six Steps to Pass the Agile Test,” I’ll provide detailed information on a proven approach to problem identification and solving and a specific example based on a real-life Agile Test to show how the Six Steps works… and how you can use it successfully.
Why It Matters
Why is this important? Are you getting everything you hoped for out of your Agile implementation? Quickly, and by that I mean in a matter of weeks to a few months? Let me emphatically state that if you do not observe significant, measurable improvements in throughput, quality, and team morale within a couple of months, it’s because you are likely not aware you’re facing the Agile Test much less failing it.
The problem with failing the Agile Test is, if you keep failing, if you keep not learning, these failures will damage your credibility and your teams’ morale to the point where your Agile transition will fail, because people will eventually stop believing in it. They stop believing the organization is serious about Agile or change.[2] It’s just the same, er, stuff… with a different name. You’re stuck in the Insanity Loop, doing the same thing while expecting a different outcome, and that will drive your teams to the brink of insanity.
There’s no reason to fail, and when you start passing the Agile Test, the credibility of your efforts grows to where your people… your teams and your stakeholders… increasingly trust you to get things right. So, even if you make mistakes they start to be perceived as no big deal, minor setbacks that lead to vast improvements. People begin to understand that reasonable mistakes are the inevitable price of learning, and so reasonable mistakes… when you think through a problem and come up with a prospective solution that seems reasonable but that doesn’t provide the expected results… go from being criticized to tolerated to accepted, and then to encouraged. The outcomes from facing and fixing your problems include: higher productivity and throughput, better quality, less rework in the form of defects and redesigns or re-implementations, an increase in predictability because you start to accomplish your sprint goals, and an increased capability to deliver without adding resources.
Your organization will start to see quicker releases, more satisfied customers, and eventually, the capability to respond more effectively to change, whether it’s a change in technology, in the product, or in the market… the benefits of becoming more and more Agile. All because you understand when you are taking the Agile Test, and you know how to pass it.
The Agile Test… an Opportunity for Change Through Inspect-and-Adapt
Let me expound on what I mean by the term ‘Agile Test,’ a term I’ve developed and used over the past decade or more to describe the opportunities for improvement that arise as we discover problems in the way things work… or don’t work… in our organizations. Lean and Agile approaches like Scrum or Kanban (or both, embrace the and!) never solve our problems, they just expose them. You and I, the movers and shakers, along with our people, must do the heavy lifting. We have to solve these problems because they won’t solve themselves and they won’t go away.
Why We Don’t Improve
As someone who’s led software groups, who’s consulted, instructed, and coached hundreds of organizations and thousands of people, I can tell you that the single reason things don’t improve is because we don’t make the necessary changes that enable improvement. These opportunities, these chances to learn and fix our problems, are right in front of us, if only we can see them.. but we don’t. Whether we’re blinded by the fear of being wrong, by inertia and thus a reluctance or even a resistance to change, or by our cognitive bias that keeps us from recognizing that we need to change, too often we keep doing the same things, maybe with different labels, while hoping for a better outcome… and we keep failing.
Reasonable Failure is the Price of Learning
Now, failing per se isn’t bad. Good leaders give explicit permission to their people to fail reasonably. It’s the same way for all human activity. No one can ride a bicycle the first time they try. It takes falling, or failure, and the mindset to recognize this as feedback, to learn. Yet, the people who struggle to learn often do so because they aren’t actually learning. The system is telling them something but they aren’t listening. They’re just repeating what doesn’t work. This isn’t due to a lack of ability to learn, but instead because of a combination of lack of understanding and cognitive bias. We think that it’s us, that our approach is right, but we just aren’t doing it well enough, that if we only did it better we wouldn’t fail. What we don’t understand is that we need to do it differently, not better. We need to open our eyes and realize that, as Will Rogers said, it’s not what we don’t know that hurts us, it’s what we do know that just isn’t so. Doing more of what doesn’t work doesn’t work, and it’s not reasonable… it’s stubborn.
So, if doing more of what doesn’t work doesn’t work regardless of how much we hope it will, what does work? It’s simply this: stop hoping and start changing. Stop trying to do things better, start doing things differently. Stop accepting the way things are and start changing to the way things should be. That is the crux of the Agile Test: when faced with a problem, are you going to step up, step in with your teams, and solve it by doing things differently based upon thinking through the problem? Or are you going to double down on what’s not working, or try things randomly with no hypothesis of the problem… in a word, guessing? Even worse, are you going to let it go, accept it as integral to the work and thus unavoidable or outside of your control, and then continue to do what you’re currently doing that isn’t working? Not if I have any say.
The Solution: Six Steps to Passing the Agile Test
Your problems aren’t going to solve themselves. You have to do it… and for me this is the really enjoyable part of leading transformations. If you’re starting to see that perhaps there are things that need to be challenged in your organization… problems to be solved, and you want a proven approach to solving them, read my second article, “Six Steps to Pass the Agile Test,” for specific guidance on how to recognize, clarify, and solve your problems.
If you find this article interesting, please let me know in the comments… your feedback is valued and appreciated. If your organization is struggling to pass its Agile Tests, feel free to reach out to see if I can be of assistance.
_____
[1] Yes, this applies to other Agile and Lean approaches, including Kanban, etc. Leaders must understand how to find and fix problems in their organizations if they are going to be successful… and to be able to coach and mentor others to do so.
[2] David Anderson has described this effect as a function of the ‘J-Curve’ where, if the temporal gap between process disruption with its consequent loss of productivity and the re-achievement of comparable productivity as the new process is adopted and absorbed into the org culture exceeds the organization’s ability to tolerate the disruption, the process change will fail. Not fixing problems greatly exacerbates this.
