TL; DR: Essential Agile Failure Patterns — When Noise Interferes with Signal
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. When Scrum becomes an element of an agile transformation, the following three common essential agile failure patterns prove to be an exceptionally tough nut to crack for any Scrum Master.
Join me and explore the consequences of foreseeable failure patterns and what you can do about them in a little more than seven minutes.
Update: I am running a poll on LinkedIn—join the voting: “What is your top agile failure pattern in organizations?”
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 31,000-plus other subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
Join more us on July 6, 2021, for the Hands-on Agile #32: How to Win with Agile Resistant Teams—Scott Weiner.
Reasons for Becoming a Learning Organization
There are various excellent reasons to become agile, for example, by adopting Scrum:
- The competition drives innovation at an even higher pace, and the organization starts lagging,
- The organization faces problems hiring senior people in an increasingly competitive war for talent,
- The overall productivity is low,
- The organization is losing skilled members, which adds to low morale,
- There are budget constraints: there are no more funds to waste on waterfall projects.
But the fact is also, that the scope of an agile transformation is often wholly underestimated. That “Agile” is not the quick fix for everything that is going wrong. Each organization has its own set of dysfunctions, and hence solutions dealing with them need to be tailored specifically to that organization. However, there are several essential agile failure patterns common in many organizations, three of which I like to introduce in 7:31 minutes.
1. Is Agile a Fad or a Trend?
The Problem: Parts of the leadership—particularly the middle management—pay lip service at best to the idea of becoming an agile organization. Besides business cards, the business analysts are now Product Owners, not much has changed, except for the inevitable “agile playbook” created by a well-reputed consultancy that the lower ranks are asked to “roll out.”
The Consequences: Remember that probably about 10 % of the member of a social group are change agents, 5-10% are refuseniks pushing back, and 80 % typically comprise the silent majority joining when the dices have fallen. With a lot at stake for management folks, why not wait and see? Maybe, it goes away in a few months?
Leadership is about being the first to explore unknown territory at personal risk, thus being a role model. This wait-and-see approach of the leadership will “earn” support from significant parts of the organization: If the leader is not entirely in, why should I be? And now, everything is either stalling or done by half-hearted measures.
The Solution: Awaken the Alexander the Great in you and be a leader. Show support for the massive task at hand by being present and support the effort in every way possible, for example, by:
- Communicating the goals time and again by authoring a blog, a newsletter, creating a podcast,
- Practicing Gemba walks,
- Attending events, meetups, and communities of practice makes everyone understand that Agile is here to stay. (The Sprint Review is an excellent opportunity, for example.)
- Pointing at successes & failures, establishing a failure culture, see below,
- Empower the teams to solve customer problems autonomously by defining guide-lines,
- Include team members in the hiring process,
- Initiate the abandonment of individual incentives and bonuses.
2. My Budget, My Feature
The Problem: The organization nominally adapts agile practices but sticks with the old ways of figuring out what is worth building:
- Pitch an idea to the management,
- Get a budget,
- Treat the product people as an internal agency to deliver what you want.
The Consequences: Think “Agile PMO,” metered funding, contract negotiations, and servant-leadership by status reports. (Concerning the Manifesto of Agile Software Development, we are back to square one.) Typically, this results in misalignment of efforts at an organizational level and stimulates local optimization initiatives within functional silos.
The Solution: Break up functional silos, consider practices like Beyond Budgeting, create empowered product teams tasked with autonomously solving customer problems, and link bonuses strictly to the organization’s overall progress during the agile transformation.
3. There Is no Failure Culture
A former client of mine, a large utility company, practiced at the time a no-failure approach to promotions: A failed project on your internal record meant you would not take the next step on the career ladder. As a result, everyone played safe, which resulted in short-term orientation as not-failing became more important than innovation. Consequently, the organization was increasingly struggling to attract new (tech) talent when software started eating the world.
Suppose “good” failure is not celebrated as a critical part of the learning process, and incrementalism becomes the name of the game. In that case, the Innovator’s Dilemma, as coined by Clayton Christensen, becomes a more likely fate of the organization. When resilience is a worthwhile goal to achieve, think of Netflix’s chaos monkey, failure needs to be an option.
And failure needs to be openly discussed—without repercussions—so everyone can learn from the case. And as it should be, leaders need to confess first. One approach could “failure nights,” or sharing your wrong decisions from the past openly. For example, see Bessemer Venture Partners’ “The Anti-Portfolio. Honoring the companies we missed.”
Essential Agile Failure Patterns — Conclusion
Shouldn’t it be a low-brainer that solving complex adaptive problems of the 21st century does not work by applying methods from the 1890ies? Apparently, it is not. The Manifesto for Agile Software Development has been instrumental in addressing the systemic issues resulting from clinging to Taylorism that numerous organizations still face today. Nevertheless, the overall progress among organizations has been mediocre at best. It is time to change gears.
How is your organization progressing on its path to becoming a learning and agile organization? Are you experiencing one of the many essential agile failure patterns? Please share them with us in the comments.
✋ Do Not Miss Out: Join the 10,000-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📖 Related Posts
Agile Failure Patterns in Organizations 2.0
A Sprint Review without Stakeholders — Making Your Scrum Work #3
Three Wide-Spread Product Owner Failures in 6:09 Minutes—Making Your Scrum Work #5