“This is just a case of Agile failing,” said the project leader when he informed me that the team I was coaching would no longer be using Scrum to build a mobile application. The explanation was unsatisfying as well as curious. There had to be more to the story than just “failing agile”.
The mobile team was part of a large organization undergoing an Agile transformation and Scrum was their framework of choice. As a coach embedded in the team, I could easily enumerate how Scrum was working as intended.
After two months of sprinting, the team tackled some thorny challenges to provide visibility into their work:
So why assert that “Agile failed”?
In the past, I would have pointed to problems with building software and blamed it on Agile. It seemed like every new user story exposed some complexity I wasn’t counting on. Nothing was more unnerving than having to communicate to my boss the actual time that a release would take. Being transparent and honest was frightening. But I was lucky. When I expressed to my manager that things seem out of control, he responded: “This is working. We’ve exposed the problems so that we can work through them.”
Not everyone reacts the same way. From my perspective, it wasn’t Agile that failed our mobile application delivery, but an inability to confront uncomfortable truths, to listen to the people doing the work, or to step outside of the comfort zone of business as usual. The team found very little support in removing roadblocks, negotiating scope, or in providing resources to implement improvement ideas.
The dynamic above spurred negative behaviors. The team started taking on more work than they could successfully complete in a sustainable way. They put their focus on starting features rather than finishing them. At sprint reviews, large number of bugs and technical debt were exposed. The combination of having too much work in progress and mounting technical debt prevented the team from confidently reporting on how close they were to delivering a minimally viable product.
Instead of confronting the issues that the team exposed, leadership declared that the train had gone off the rails. The fix was to use a project plan, to embrace more waterfall ways of working, to abandon Scrum, and to declare that Agile had failed.
It’s natural in times of stress to go back to what you know to feel like you’ve got a situation under control. However, the organization missed out on a valuable part of their transformation by declaring Agile a failure.
As coaches, we call upon teams and leaders to look at issues surfaced by embracing Agile values as learning opportunities. Exposing the true amount of value that can be delivered with high quality in predictable ways, reducing technical debt, exposing roadblocks, and prioritizing efforts to achieve the most amount of value, are all gifts to be capitalized upon. Knowing that these issues are present allows us to change them, with continual prioritization and time boxes as forcing functions.
There are some organizations whose cultures will have a hard time seeing problems as gifts. Their values may be at odds with values that increase agility: openness, honesty, transparency, and collaboration across all levels of an organization. Organizations whose cultures are not aligned with Agile values will advance when they prepare themselves to see what might be labeled as failure for what it really is: a chance to change the culture for the better, and to use better ways of creating value while respecting the people who produce it.
To achieve the full benefits of Agile, individuals at all levels of a company must have the bravery, endurance, and patience to face changes that embracing its principles may cause. So, which will it be: a declaration of failure, or the courage to rise to the occasion?
