Introduction
In this provocative second episode from 2016, our protagonists reunite on a project where Mr. Waterfallon reveals a disturbing revelation – his “conversion” to agile methodologies has actually become weaponized against development teams. This dialogue exposes the cynical exploitation of agile practices that became known as “Agile Theater” – a phenomenon that unfortunately grew more prevalent over the subsequent decade.
As you read this dialogue, updated with 2025 perspective, you’ll discover:
- How agile practices can be misappropriated as control mechanisms
- The fundamental disconnect between agile values and their implementation
- The real prerequisites for successful agile transformation
- Why the Product Owner role became one of the most challenging positions in technology
- How organizations create “Agile Theater” while maintaining command-and-control cultures
This conversation primarily operates in the Confused domain of the Cynefin framework, where the same term (“agile”) is being used to describe fundamentally different approaches. It also touches on Chaotic elements when exploring the weaponization of agile practices, and the Complex nature of true business-technology collaboration.
Stage – Post from 22. February 2016, Updated with 2025 Perspective
Mr. Waterfallon and Mr. Aguilero recently met after years at a conference. They used to work together in the past. By chance, they are now again working together on a project.
Mr. Waterfallon is one of those seen-it-all been-there-done-it guys with lots of project experiences – good ones and bad ones. Mr. Aguilero is a hot-shot. He is the one who neither knew nor cared it was impossible and did it anyway.
Raise the curtain again for another round in the ring of deathmatch arguments on business, IT and all the rest.
Mr. Waterfallon
I must admit I converted to agile! Since we met the last time, I had the opportunity to be part of a large scale agile project. And you won’t believe it, and I am fully convinced now.
Mr. Aguilero
Somebody pinch me please, I must be dreaming. What happened? Did you read the agile manifesto for the first time?
Mr. Waterfallon
I knew the manifesto probably even before you did, but I believed it was about fairies and unicorns. Now I know it is the American Dream of the IT industry. Make the team believe in it, and they will accept any additional pressure. We did Scrum, and I learned to love it. It turned our team into slaves.
Full commitment, direct personal responsibility and accountability, daily stand-ups with full transparency of individual failures, and all the blame went to the product owner. It was wonderful. You know as in old times, and I know you are used to this, so let us do this in our project. Please be my product owner.
Mr. Agilero
A slave team? A scapegoat product owner? What the…?
Mr. Waterfallon
As said: it was great. I’ve never seen that kind of absurd control over a development team. Although a lot of time was wasted because the scrum master in charge, the product owner, and the developers were on different planets. Due to the pressure and transparency, all mistakes became public. The developers wanted to cover their errors and compensated by overtime, and the provider added extra staff no one was charged for. The customer did not have to search for an Achilles’ heel. It was served to him on a silver plate.
Mr. Agilero
I am speechless!
Mr. Waterfallon
And now comes the catch: There was even the choice whom to blame in each situation. Where there is Scrum, there are backlog items. Its the product owners responsibility to write them – and everyone knows the POs of the world are neither qualified nor do they have the time to do it. So one could choose whether to blame the developers or the product owners for screwing it up as I said: excellent!
Mr. Agilero
Well… The gods created the earth and hades. They also established an outpost of hades on earth to prepare some of us here on earth – I have no idea where I got that bad karma, but it is the way it is… They created this Fegefeuer in the roles of Product Manager, Product Owner, and Business Analyst.
The pressure a team allows is within their control. It is the old prisoner’s dilemma they must overcome. This is where a scrum master, a real team player, can help. I somehow envy them because the various agile frameworks have some tools for them. It is also solely focused on the team itself, which lowers the overall complexity.
The product owner or business analyst approach is a different beast.
But please, be my scrum master, and I will tell you my plan to survive.
Mr. Waterfallon
You can call me your evil scrum master from hell. I can’t wait to heat the fire!
Mr. Agilero
So first of all, Agile is currently at the peak of the hype cycle. Your arguments are the best evidence for this.
Agile is not about controlling. It is about collaboration. You can control a contract, but then you will need a plan that is carved in stone. You will get what you asked for, and each change will have a high price, as everything is predefined. Sticking an agile tag on this project perception and perceiving it as a tool to squeeze the last drop of blood out of the team is exactly what agile is trying to prevent. It responds to change, and the result is better as the initial plan since business, development, and users are working together to build the best solution.
The development team has to be perceived as part of the solution. Right now, in the best case, the development team is kept at arm’s length. This is contract thinking and not collaborative – therefore not agile from the very beginning! Most often, the development team is just a bunch of slaves, and the business expects execution only. I have seen this too many times: the senior management likes agile, as it is suitable for marketing but still asks at the end when all features (which they always can remember from the kick-off) are going to be delivered – of course at the same fixed price.
The architecture is an epic story for itself. It has to be in place as a solid foundation when we are talking about a service life cycle of more than two years, which should be hopefully the standard. I think we agreed on this last time we met. Today I see MVPs, and the architecture is just a documentation of a very early prototype – so the business and the development team is doomed by technical debt right from the start.
The development team should have a personal interest in building the right solution. Idealy they will use it for themselves. This knowledge is 20 years old and can be found in the famous cathedral vs. bazaar article from 1997. It is a good starting point for a product manager or product owner to sell the vision. This might not work for every solution, but at least for some aspects or components. It will require a leader and not a boss.
Last, not least, you need to cover more than just frontend, backend, and design. At the very beginning, there must be a strategy in place. You will need to understand your users truly, this is an ongoing process. Technology and implications must be outlined – this maps directly to the architecture. Production and operation must be thought out from the very beginning. The best frontend user journey is useless in terms of business value when the support tools suck. This links to an essay from Jesse James Garrett back in 2003. When those roles are in place, agile project management really kicks in and delivers.
Mr. Waterfallon
Nice sermon. You know too well that all these prerequisites have never been observed in corporate reality. So shall we heat hell now, or what?
Mr. Agilero
Damn it. Yeah, heat hell!
2025 Retrospective Analysis
The Rise and Fall of “Agile Theater”
The cynical manipulation of agile practices that Mr. Waterfallon describes became widely recognized and named “Agile Theater” in the years following this dialogue. Organizations adopting the ceremonies of agile while maintaining command-and-control cultures created exactly the toxic dynamic portrayed here – increased visibility of team activities without the corresponding trust and empowerment.
By 2025, the concept of “Agile Theater” has become a cautionary tale in transformation circles. In a 2022 McKinsey survey, 79% of organizations admitted to practicing some form of Agile Theater, while only 14% reported achieving true agility that delivered measurable business outcomes.
The Product Owner Burnout Crisis
The hellish existence Mr. Agilero describes for Product Owners proved prophetic. Between 2018-2022, studies showed Product Owner/Product Manager roles had among the highest burnout rates in technology, with average tenure dropping below 18 months in many industries. The fundamental problem remained unaddressed: bridging the chasm between business vision and technical implementation while being held accountable for outcomes without corresponding authority.
Some organizations eventually recognized the pattern and implemented solutions like:
- Duo Product Ownership – Pairing business and technical Product Owners
- Team-based Ownership – Distributing ownership responsibilities across team members
- Product Operations – Creating dedicated support roles to handle administrative burden
Technical Debt: The Prophecy Fulfilled
Mr. Agilero’s warning about MVPs creating crippling technical debt came true for countless organizations. By 2023, Gartner estimated that “technical debt management” had become the #1 priority for 67% of CTOs, as hastily constructed MVPs became permanent production systems, and the interest payments (in terms of maintenance, outages, and security incidents) began exceeding the value delivered.
This led to the rise of “Sustainable Delivery” practices, where many organizations began requiring architectural runway and technical debt remediation as explicit elements of their product delivery approach.
The Contract-Collaboration Paradox
The fundamental tension between contractual control and collaborative agility that Mr. Agilero identifies persisted. While agile contracts evolved somewhat (with time & materials, capacity-based, and outcome-based models gaining traction), the majority of large enterprise projects remained trapped in the paradox described in this dialogue: wanting both fixed scope/price and agile adaptability.
By 2025, this led to a clearer distinction between different types of work:
- Commoditized IT – Where traditional contracts and metrics remained appropriate
- Product Development – Where true collaborative agile flourished
- Innovation Work – Where even more flexible approaches like Design Thinking took precedence
What We Got Right
Mr. Agilero’s emphasis on architecture, strategy, true user understanding, and operations-aware development perfectly predicted what would become known as “DevOps culture” and “Product Thinking.” These approaches became mainstream by 2025, with organizations recognizing that siloed feature factories couldn’t deliver sustainable business value.
The observation that technical teams should “have a personal interest in building the right solution” anticipated the rise of developer experience (DevEx) as a critical success factor. Organizations where developers use their own products (“dogfooding”) consistently outperformed those with disconnected teams.
What We Got Wrong
What neither character anticipated was how AI would transform the development landscape. By 2025, AI coding assistants have automated many of the routine tasks that created friction in agile teams, allowing more focus on higher-order problems like user experience and business outcomes.
The pessimistic ending – “heat hell” – didn’t fully capture how many organizations eventually did find effective middle paths, combining elements of structure and flexibility in context-appropriate ways.
Looking Ahead: The Next Frontier
As we look beyond 2025, the eternal tension between control and autonomy continues, but with new dimensions:
- AI-Augmented Agility – How will autonomous systems change team dynamics and planning horizons?
- Platform Ecosystems – As organizations build composable businesses, how will agile practices evolve to work across organizational boundaries?
- Outcome Engineering – Can we move beyond feature output to truly engineer for business and user outcomes?
Perhaps in their next meeting, Mr. Waterfallon and Mr. Agilero will find themselves discussing these new frontiers, still maintaining their dialectic approach to extracting wisdom from opposing viewpoints.