One of my clients has many reasons for wanting an agile transformation. Their old products are at the end of their lives. They need agile approaches so they can get feedback from customers as they develop the new products. They need to deliver to their customers more often. They need to create a mix of new products and services, which means they need to use an agile approach for their projects and their project portfolio. Agile approaches are perfect for their corporate needs.
The problem is that the managers want guarantees about the projects: they want to use what’s proven, what works. They want predicted dates that the teams can commit to. They want assurances that things will progress as they planned.
The problem is that the teams are doing all new work. The one guarantee is that things won’t go as they planned. The teams will encounter problems. And, I suspect that the teams will also discover they need a lot less for their “minimum” features than anyone suspects. The teams—and therefore management—will need to consider plans A, B, C, D, and possibly more.
What the teams, managers, and the organization as a whole need is more experimentation. (You might want to check out What’s Minimum: Thinking About Minimum Viable Experiments.)
Their agile transformation is stuck because even though they know their why, the managers need to practice change so they can change their culture.
Their agile transformation is stuck.
A senior manager, frustrated by their small progress, turned to me in a meeting and loudly said, “Failure is not an option!”
The problem is that failure is always an option. In fact, in this case, they are guaranteed to “fail,” as in not deliver exactly what the customer wants every single time. The projects won’t complete “on time” (they might finish earlier). The managers will realize they need to change the project portfolio more often than they now think.
It’s how we think about “failure” that can help us move to more experimentation.
When we have the mindset that failure is not an option, we might not consider multiple ways of managing risks. For example, one way is to learn early (instead of calling it failing fast) deliberately. What small experiment can we try today, to measure and assess the results?
Using the ideas of experiments with measurements appeals to these folks. They are starting to reassess their agile approaches to build more experiments in. They are looking for data. Not failure, but data.
Failure is always an option. I prefer to consider how we can see and manage risks to achieve the outcomes we want.
If some of the people in your organization also struggle with this mindset, please join Gil Broza and me at the Influential Agile Leader workshop in Boston, June 7-8, 2018. The early bird registration ends May 1, 2018.
You’ll have a chance to assess your progress, your system, and culture. Once you do that, you’ll be able to create action plans that will unstick your agile transformation. Do join us.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Agile Transformation When Failure Is “Not” an Option Opinions expressed by Java Code Geeks contributors are their own. |
