The nonsense called "Enterprise Agile Development"

The "Manifesto for Agile Software Development" is the basis for many "agile approaches". Enterprises worldwide have been sold to the idea that they need to become "Agile" in order to remain competitive. And anecdotal evidence of the success of "Agile" is abundant.

There's a dirty little secret that most organizations, coaches and consultants are either unaware of, don't understand - or they just don't realize the impact thereof: "Agile", as originally proposed, is a local optimization, intended to improve the work of software developers! This begs the question: "What if Software Development isn't even the problem?"

Synopsis

If we look at organizational processes from end to end, we realize that even if Product Development were a flawless, instantaneous activity, not much would be different in the big picture. Why do we spend so much time and energy to make irrelevant changes?

95% of changes made by management today make no improvement. -Peter Scholtes

"Agile Transformation" is often one of these ineffective changes.
To find a better solution, we need to frame the problem differently.

The scope of "Agile"

"Agile" is intended to bring the entire IT development organization together. It's irrelevant whether we're talking Scrum, Crystal, XP or whatever, this idea is fundamental to "Agile".

From the time a "requirement" (or: "user story" - or whatever) is scoped for delivery until it's delivered, people from IT collaborate, involving business stakeholders, to minimize cost, overhead, quality risks and delay in the process.

Why "Agile" looks so appealing!

It sounds very appealing to any IT manager worldwide to reduce defect rates, cost and cycle times by margins of fifty percent plus each, while making IT employees happier, especially since those benefits can actually be achieved compared to siloed approaches!

But what if I told you that none of this matters at enterprise level?

The real picture

In a 100.000+ people enterprise, there are hierarchies, reporting lines, budgets and highly complex dynamics going on. Not everyone talks to everyone else.

In an enterprise context, it's fairly normal that from idea until approval, different rounds of experts, stakeholders and boards are involved - long before an item lands in IT's actual toDo list.

The idea goes through some kind of process, where people who are not involved in actual development clarify what's actually going on, whether it's worth doing and have to make sure it will get done.

While Scrum specifically has a "Product Owner" and Scrum proponents might argue that this is "refinement" for which the Product Owner has this responsibility - in an enterprise, that's too much work for one person, so it will be delegated: We end up with handovers in the process, multiple queues and waiting lines. 

This picture depicts what's actually going on in most larger organizations:

Careful - "Agile" doesn't even talk about the big picture!

The lead time of the yellow chevrons, in a Waterfall world, tends to be 3-6 months, and in an Agile universe, it's much shorter. 

Let's do a thought experiment: What if the yellow part of the process were conducted by a little fairy with a magic wand that could complete all these activities at zero cost, in zero time and without any defects? 

How agile, how fast, how cheap would this process now be?

In large enterprises, each of the gray chevrons takes weeks to months, is quite expensive and error-prone. Considering the end to end process chain, even if we disregarded everything happening in the "Agile" parts of the process - we'd still have a slow, inflexible and expensive process! 

The overall effect of introducing "Agile Software Development" into Enterprise processes is neglegible.

End-to-end Agility

Now, we get to the revolutionary idea of simplifying the entire process by means of moving to "Business Agility": bringing developers straight to the users!

A paradigm shift: entirely removing the men-in-the-middle!

Once an item is prioritized, we jump straight into development. There's just a small fly in the ointment: how do we prioritize it? In order to determine whether it's the most valuable thing, it still needs to be refined - so the same process still applies!

The problem, unfortunately, in the Enterprise world, is not even whether we have a handover in the process between a "Refinement Team" and a "Development Team". The real problem is overall lead time!

As long as it takes weeks to do the clarification rounds, the umpteen mandatory boards only meet once in a full moon, every new feature requires comprehensive user trainings and there are manual compliance audits, there is no way for a change in development to significantly affect overall outcomes!

Unless you're part of the problem, you're not part of the solution.

The illusion of improvement

When overall processes retain their massive overhead, and communication structures remain untouched, Agile Development alone is irrelevant to the overall business outcomes. Even if we get it right - which is extremely hard in the governance straight jacket so nicely provided by many organizations - the enterprise as a whole will not feel much of an impact by the introduction of "Agile Development" into a cluttered, overcomplicated jungle of processes, rules and regulations.

If we are looking for significant improvements to the enterprise, Software Development is often not the right place to look - yet agilists have spent nearly a decade developing increasingly intricate ideas for optimizing exclusively this part!

Moving Enterprise Software Development from "Waterfall" to "Agile"  is like using white sand instead of yellow sand to mix concrete - we feel as if we made a difference, while an outside observer wouldn't recognize any change!

And that's why Enterprises who have invested heavily into "Agile Software Development" often feel underwhelmed with the outcome and become entirely disillusioned.

A change in mindset

"Agile" brought a massive change in mindset, it gave developers a voice - and it's people from Technology who are now educating the business world how to change their ways of working, in order to take advantage of Agile processes.
Unfortunately, we see that many agilists are stuck in their little Technology world, not realizing that optimizations made exclusively from a Technology perspective alone are exactly as ineffective - and potentially equally harmful - as those made by Finance (namely, Cost Accounting - but that's another story, to be told another time).

Much more important than doing an "Agile Transformation" and converting legions of decently functioning teams with decently performing individuals to "Agile ways of working" would be to look at the real problem the organization is facing - it's not a development problem. It's a flow problem, in end to end value.

I believe that not just agilists, but struggling organizations as a whole, will find significant value in moving beyond the new structure and processes suggested by Agile Frameworks and tackle the real issues their organization is facing, which are hidden in plain sight when adopting Agile Frameworks.

In the past years, I have come to realize that we need to move beyond IT, beyond Technology, beyond Product Development, to see the need for a Unity of Purpose, optimization at the bottleneck and relentless improvement. Try not making any change to anything other than the bottleneck: Development can work however they consider fit, unless and until that's where the bottleneck is.

Closing remarks

Let's just not make changes that don't matter. Too much harm and grievance has been inflicted upon managers, developers and entire organizations in the name of this "better way of working". So many "Agile Transformations" caused great people to lose their job, their sanity or the respect they deserve, while giving the organization nothing to show in return. It's time to stop this madness.

Let's put Agile Frameworks where they perform best: into Product Development. Let's not try to stretch their purpose beyond their applicability, and let's not overzealously convert everyone to one specific way of working. Give people the freedom to work in whatever way they consider is best for them, Offer people Scrum, Kanban, SAFe or LeSS as an option if it makes them happier - but don't force anyone into any of this, especially not when development isn't even the problem.