Abandoning Agile and the “Faux Agile” of the so-called Agile-Industrial Complex
I have been recently chatting with some of my friends about pretty interesting articles with anecdotal examples of why Agile, and particularly Scrum (Scrum Sucks), has failed to deliver on its promises (see the links here and here). The overall sentiment of these insights is that the Agile methods aren’t always the best tools for the job. Let’s explore in more depth, why?
Some anecdotes come from Santiago Valdarrama’s article published here. What he lists below are some bad analogies:
- "They tried to convince me that Poker is a planning tool, not a game.
- If you want to be more efficient, you must add process, not remove it. They had us attending the "ceremonies," a fancy name for a buttload of meetings: stand-ups, grooming, planning, retrospectives, and Scrum of Scrums. We spent more time talking than doing.
- We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
- We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.
- I had to use t-shirt sizes to estimate software.
- We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points.".
- Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.
- Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously.
- We paid people who told us whether we were "burning down points" fast enough.
- Weren't story points about complexity instead of time? Never mind."
Well, it seams these are not anecdotes abut real life pain experience. And others say that there is an ever-present micromanaging going on, what is a big part of the failure.
"Scrum micromanagement of meetings especially daily stand-ups. Scrum masters, Agile coaches who are custodians of subjective buzz words and non empirical evidence but treated as so. Its continuous and fine-grained making things mindless mind-numbing and measured, like velocity, slicing etc."
And the tread is going on and on. Well, it seams that too many organizations have gotten caught up with the Agile buzzwords and Scrum Masters telling them how to work in an “Agile” way. Notwithstanding my development peers’ issues with Agile methods, my problem with Scrum, and Agile methodology as a such is of a different nature.
Very often I bump into statements that “traditional” project methodologies (whatever that means) are not up for the job, as quoted in this Monday’s post here. Quoting the post, “In 2019, only 18% of companies reported that their projects succeeded at least most of the time.” And of course, there is a magic bullet, “Scrum and Lean are both project frameworks designed to help improve your success rate”. They just hit my forehead with a hammer. First, what is that authority that summarized all the projects failures in this wide world found this highly likely suspicious rate failures. Impossible, my first guess is they just made it up.
Despite all the mystique and hype, the “faux agile” of the so-called agile-industrial complex doesn’t live with the developers but with the oversold and pale information technology managers. Scrum’s scientific approach and enthusiastic promotion swayed many corporate managers from inefficient processes into a false sense of security, looking for a magic bullet. Maybe the Scrum's emphasis on empirical management is logically sound, but in a practice, Scrum is all about the project management, not the software. Therefore, Scrum per se is not an “agile” software-development method—because it is not a software-development method at all. At best Scrum is an addition to Agile Methodology, not a replacement for Agile.
But in a reality, to mitigate their own inefficiency, the software development managers used Scrum to be a “wrapper” around any kind of new product development method was well meaning but ignored a fatal logical flaw: If you wrap a non-agile method, the whole thing is no longer Agile. Scrum is not about the software, but about project planning and execution, emphasis of which is generally considered harmful. In this light it’s easy to see how Scrum became a bloated, corrupted, fragile, anti-agile monster loathed by developers worldwide.
The Scrum has lost his flare because his association with Agile became imposed rules and ceremonies, and instead of “embracing Agile”, or “be Agile”, Scrum got associated with the need of corporate managers to ‘do Agile”. In his article “Understanding Fake Agile”, Steve Denning went even further, emphasizing the obvious.
“Without an Agile mindset, Agile remains an inert, lifeless set of ceremonies."
Steve Denning
Meaning, Agile is described by a set of principles and values, not ceremonies and processes.
Every senior executive asking a question “Why are we not doing Agile” should know that Agile is not a magic potion what employee drink up to become Agile. Following this path without Agile mindset, that organization and its people are going to become “Agile in Name Only.”
If there is any lesson her to learn, don't look for the magic bullets but use the methodology that has proven in the organization’s journey.
