Agility When the Music Stops

Part 2 - where we went wrong.

So what responsibility do agile folks have for all this.

First, I’ll make a strong distinction between looking at the root causes of a problem and victim-blaming.

I ride motorcycles, and as I’ve told my fellow riders frequently, _every_ motorcycle crash – with very few exceptions – is the fault of the rider, even when someone else caused it or is legally responsible. Because no one is more responsible for your safety than you, and it is part of a rider’s role to anticipate problems others will create. Similarly, it’s the job of professionals to understand and respond to market conditions.

The external forces I described yesterday are the trigger and main driver for what is happening in agile today. It is the environmental change around us. But…

Agile as it is practiced and theorized has drifted away from ‘maximizing utility’ for a while.

In my model of the world – which I’m sure is going to be challenged – Agile folks got wrapped around the axle of craft-as-artistry to an unsustainable extent and of broadening employee empowerment from “the person doing the work knows best how to do to work” to “the person doing the work knows how to run the company.”

On software quality, is delivering the absolute best systems a worthwhile goal?  Mmmmaybe. Is delivering the best systems possible to meet an organizational goal worthwhile? Always.

In the history of the Civil War, the Union Army spent a lot of time fruitlessly seeking ‘a perfect battle’ and a series of Generals who were incredibly well-schooled in the arts of war led the Army of the Potomac.

But it wasn’t until a general who simply took battles as they came and won them – Grant – came along that the path to victory truly became clear (yes Civil War buffs, I’m wildly oversimplifying complex history to make a point).

We need to meet our organizations where they are and make them better, not stop them until they can be perfect.

A lot of folks I know and read here who focus on “engineering agile” push back on managers who demand schedules and cost estimates because they don’t understand that perfection takes time.

There are two problems with this.

The first is that the scale of quality for any product varies. What’s needed for Halloween decorations is different that what’s needed for surgical tools which is in turn different that what’s needed for nuclear weapons control systems.

Am I suggesting we should deliver crap? Nope. But am I suggesting that operating at the top edge of the appropriate band of quality for the product we’re delivering is the right thing to do? Absolutely.

How do we get there? I’ve always favored a kind of tug-of-war where the different stakeholder all pull on the rope, and I find that the knot in the middle often winds up in more or less the right place. It requires facilitation to keep the more forceful stakeholders from dominating, but when done well it works.

The second problem is that – as I’ve said a bunch before – ‘software is no longer the product.’ Having autonomous development teams made sense when the product was a floppy disc or CD-ROM.

But in today’s world, software is deeply embedded in physical products and business processes; it’s not stand-alone anymore. And delivering those physical products and business processes requires orchestration. (nb. This is why shifting to a ‘product focus’ makes so much sense)

Much as success in military battles requires that multiple groups act in coordination – and when they fail to, battles are lost – successful product delivery or process implementation requires a bunch of different things to happen together. To me, the centrality of this kind of orchestration drives the value of estimation. (to orchestrate, I need to be able to predict)

But there’s another. Time equals money – in two ways. First, we spend money on the people doing work, and that spend rises over time because people get paid every two weeks. Second, we lose money because we can’t sell/use what’s delivered (cost of delay).

And…as I tried to make clear yesterday, right now making money and saving money are core drivers in business strategy.

So the ‘engineering artistry’ branch of agile practice runs up against the brick wall of the organizations’ need to survive. And – bluntly – isn’t going to power through those walls.

The second branch is made up of folks who strongly believe that – as an example – “we shouldn’t move any teams to agile practices unless they choose to change.”

And beyond calling for empowering teams to work as they choose – often on what they choose – and sometimes using the tools they choose.

Kind of anarcho-syndicalist communes.

There are also two material problems with this model.

First, in most companies, the teams don’t work autonomously on an individual customer-facing product where they have direct contact with the customer. They are working on a component within a larger system, and too often lack real perspective about the context they are operating in.

They also lack strategic context around the broader corporate issues – what competitors are in the market, how the changing cost of capital impacts decisions, and so on (this is why the contextual presentation in SAFe’s PI Planning is so useful).

Next, the kind of orchestration I mentioned above that is required for modern products and processes requires mutual understanding. That implies (as an example) that we can roll up state from multiple teams to give perspective on overall delivery and that teams can lean in to support each other if needed (hard to do if there are no common work patterns or tools).

A friend worked at a game company where every team got to develop in their own way suing their own dev tools and work management tools. The teams were super happy, and arguably individually very productive. But the games didn’t ship, because orchestration among teams was virtually impossible.

So they reversed course and standardized.

There’s a final, and political take to bring to this.

All of the things I mention above have the impact of denying managers what they need to function. Some practitioners see this as a feature, not a bug, and really want to see management wither away (more than it is under financial pressure).

There’s a whole other discussion to have about what the optimal role of management (especially middle management) is in organizations, but the simple fact is that in today’s world the managers who these practices denigrate make the decisions about how the organizations will work.

And people are shocked that the managers aren’t interested in investing in change that directly challenges their role?

Practically, to succeed in this new reality, change agents need to adapt. We need to be deeply focused on value delivery and value retention (making, keeping, and saving money to be blunt). We need to help solve the problems of orchestration, not make them worse by folding our arms and stamping our feet.

And if we want to be ‘in the room’ where decisions are made, we need to demonstrate that our interest is the survival and health of the organization and be able to link our work directly to those outcomes. And, finally, we need to operate with an appropriate level of humility.

Managers got their seats for a reason, and I have consistently found that it’s useful in trying to get someone to change to respect where and who they are and try and understand why they make the decisions they do.

If you can’t do that – why would you expect them to listen to you?