Brenda Murray is an Agile Coach at MATRIX with a rich background in Business Analysis, UI/UX, and technology consulting. She holds many certifications, including: CSM, SPC4, Safe Agilist, Certified Product Owner, and Certified Career Coach.
Did Agile Fail Us or Did We Fail Agile?
“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:
- Individuals from the different technologies needed to build the application were working together as one team.
- All features and work were now visualized in one place – the backlog. Previously, it was not, and that obscured the real amount of time needed to deliver the product. Now the team could expose to stakeholders that the original timeline for the project was going to take four months longer than originally expected.
- Because of a focus on delivering value instead of tasks, the team revealed organizational roadblocks that they needed help removing to get the tools and infrastructure necessary to accelerate testing and delivery.
- Most importantly, the team was showing working software early and gathering feedback from their business partners to ensure that they were building a useful product.
So why assert that “Agile failed”?
Reacting to Truth Serum
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.
Failure or Call to Courage?
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?