The Problem with Agile at Scale

LeadingAgile has worked with lots of clients 13 years into our existence. In our experience, the number one barrier to doing Agile at scale, to running a successful Enterprise Transformation, to achieving true Business Agility is creating complete cross-functional teams at the lowest levels of the organization.

What do I mean? If we can’t create complete cross-functional teams at the work surface, where code actually gets written and deployed, how do we expect to run a successful Transformation or achieve any notional idea of Business Agility?

Why don’t we do this? Because a lot of companies aren’t set up that way. Technology isn’t built in a way that supports it. Dependencies are rampant across the organization. And no one besides us, as far as I can tell, is even talking about the problem, let alone coming up with a way to do something about it.

So, we get trapped in this mental model that it’s all about bad leaders. If management would just get out of the way and let us do our thing, all would be right with the world. If managers would stop putting pressure on us to deliver on time, on budget, and on scope, life would be good.

Let me tell you why they don’t. Agile practices on top of a functionally siloed organization, a poorly architected solutions architecture, and a traditionally governed enterprise are a recipe for chaos. If I was your manager, and these were my constraints, I’d be top-down command and control too.

Centralized orchestration would be the only way.

Again, I feel like a broken record. Can’t tell you how many rooms I sit in where these ideas are ignored. We can’t get the conditions we want, so we double down on the idea that management is bad, the culture is bad, and that the organizational anti-bodies are the things that are shutting us down.

Agile is about fixing time and cost and varying scope to maximize value. How many teams do you know that are complete and cross-functional and have everyone and everything necessary to deliver a working tested increment of product? How many have an empowered Product Owner or direct access to a real customer? How many can actually deliver something of value at the end of every sprint?

Let alone how many can regularly meet a sprint commitment or a release commitment with defect-free, potentially shippable software. Maybe it’s a function of what I write about, the people that call us, or the people that show up to Agile conferences, but my sense is that it’s not many.

Release trains are made up of collections of Agile teams. Value streams are made up of collections of Agile teams. Workgroups are made of collections of Agile teams. Departments are made up of collections of Agile teams. Business units are made up of collections of Agile teams. How can I have Agile release trains, Agile value streams, Agile workgroups, Agile departments, or Agile business units if I don’t have Agile teams?

How would I expect any aspect of my larger enterprise to operate with Agility if my teams can’t operate with Agility? The short answer is that you can’t.

That is why properly formed teams, operating off properly formed backlogs, who can produce a properly formed increment of value, is the first step. And if those types of teams aren’t in place, then forming those kinds of teams is the only step that matters.

When we talk about Agile at scale, we’re talking about collections of these kinds of teams. When we talk about Agile governance, we’re talking about how you feed work to collections of related Agile teams so that their efforts can be integrated into larger deliverables. When we talk about Agile metrics, we’re talking about how to scale concepts like velocity or cycle time up to these larger increments of value.

In the Absence of Agile Teams, Nothing Makes Sense

You see, none of the higher-order concepts make any sense unless you have teams that can do what they say they’re going to do when they say they’re going to do it. There is a way to guarantee that happens, but getting there is really hard. So, as I unpack this over the next however many weeks. If we want to talk about higher-order constructs of an agile enterprise. If we want to unpack how to achieve measurable business results with Agile, we’re going to have to assume that Agile teams exist. That they’re working off well-formed backlogs. And able to produce a working tested increment of product at regular intervals. Potentially shippable and deployable.

If you don’t have that, you have no chance of doing Agile at scale in a meaningful way.

So, think about that. What are the barriers in your company to forming the kinds of teams you need to form? Building the kinds of backlogs you know you need to build? And getting to a point where you can deliver a working tested increment of software to your customers every two weeks?

I know the stuff that used to get in the way when I was a project manager delivering work. I know what gets in the way for our clients. But what’s your experience?

What is preventing you from doing Agile the way you know it’ll work?