Dear Agile….

“Agile is dead.” People keep saying that. (It’s an effective attention grabber.) Then they quickly say never mind, they’re just kidding. What they meant is that the way YOU do Agile is dead. And stupid. But “real” Agile isn’t. It’s just that everyone happens to do Agile wrong.

This begs the question, what is this Platonic ideal of Agile that is allegedly so different from our run of the mill, Brezhnevian “actually existing Agile”? And why do we so vehemently rush to defend it? Even I have done this. And you know what? I’m sick of doing it.

I was recently mustering the same old defenses: “But but but, the problem is Waterscrumfall, not Agile as intended in the manifesto….” Then Bob Marshall gave it to me straight. He basically said, “Shut up Charles. The manifesto is a crock.” He made some points I had to agree with. I thought about it. The result is this post.

Here’s a quiz for you. How does the first line of the Agile Manifesto begin? No peeking. Don’t know? That’s fine. It says, “We are uncovering better ways of developing software….”

Stop. 

Notice it says, “developing software”. It does not say, “flattening your org”, “making planning nimbler”, “improving decision quality”, “getting better at discovery”, “fixing your medieval budgeting system”, or any of the other far more value-adding things people have tried to glom onto Agile after the fact. What is more, when people argue that Agile in fact pertains to all these things, it’s a tad dishonest. Some might say the Agile values and principles can be applied to, say, org design, but so what?

There are two big issues with this. First, the manifesto was not the first thing to espouse such thinking, so why do we remain so firmly anchored to it, like these dudes at a ski resort two decades ago somehow plumbed the depths and divined secrets hitherto unrealized? It’s revisionist history. Second, Agile as expressed in Scrum, which is how 99% of orgs “do Agile”, is actually very command and control—not much org agility there at all.

Further, the manifesto also begins by saying, “We are uncovering…”. It does not say, “We have received from on high…”. So, don’t you think we’ve learned a thing or two since 2001? I mean, yes, most large orgs are still stuck in 1987, but come on. Contrary to popular belief, the photo below is not from the Snowbird signing of the Agile Manifesto. Can we finally stop pretending otherwise?

Let’s face it, the manifesto served a purpose, but it’s not going to get you where you need to go. So get to studying. Your knowledge has a shelf life, and it’s sometimes not as long as you assume. Prime example: If your leaders are still trying to grok Scrum, then you’re firmly stuck in the 90s.

As my friend John Cutler has put it, teams and organizations that are really killing it today aren’t sitting around debating Agile anymore. They are just experimenting and adapting as they learn their way forward and continuously improve within their given contexts. (This last part is key.)

Agile is and always has been a local optimization providing little gain to the larger system. More to the point, it has typically been used as a cudgel. It placed product teams, which are seldom the constraint, unfairly under a microscope. This has been used to exonerate leadership from much-needed change, which has in a great many cases only served to delay real progress.  

Interestingly, Agile was an attempt to, in the words of Ken Schwaber (see his “unSAFe at any speed”), “undo the damage that Waterfall had done”. Yet ironically Agile never gave organizations a viable alternative to this bogeyman it used as a foil to define itself. Thus, when we complain about “fake” Agile in order to defend some Platonic ideal, we’re just not being honest. Actually existing Agile is a hell of a lot closer to fake Agile than the Agile of the heavenly realms—and it always will be.

And this seems a problem with the movement itself, doesn’t it? Yes. Yes, it does. So instead of focusing on the productivity of teams, which again are not the constraint in the system, focus on value. As UX would stress, focus on the creation of real pivot triggers. Without this you cannot really be “Agile” in the first place, can you? No! Remember, your definition of value matters more than your definition of done.  

Now some might object and say, “But but but, inspect and adapt!” Uh huh. Except I don’t see Agile teams inspecting and adapting. I see Agile teams adding increments from backlogs, futzing about with Jira and Rally, and acting like they’re building brick walls. Sure, they claim they’re “iterating”, but this just means they’re using time-boxed wheelbarrows to fetch more bricks for the preplanned wall. Big whoop. (But who can blame them for the confusion? As I point out here, even the Agile Manifesto signatories do not agree on what “iterating” really means.)

Agile also masks a deeper problem, which is a systemic bidirectional lack of vertical trust. The Agile trainers leave, having made things worse, with the managers speaking Pig Latin and the dev teams now speaking Esperanto. The teams think management is broken and management thinks the focus should still be deadlines and velocity, ignoring that the deadlines are often arbitrary and that the time estimates are largely a form of waste. (Did you know story points were actually invented to obscure time and help alleviate this problem? That backfired too, didn’t it?)

As argued here, this political stalemate is precisely where most Agile transformations go to die. What you’re left with is two camps, with radically different perspectives, but with one group receiving their performance reviews from the other. Guess which side will win? If the poor teams are like the blind people feeling the elephant and disagreeing on what exactly it is, then leadership is like a bunch of blind elephants stepping on people then agreeing they’re all flat. 

The bottom line is that we need to stop treating teams like they work in a factory. They are not making plastic cutlery. The same rules do not apply. You are not running the same tried-and-true recipe—you’re creating new recipes. If you haven’t figured it out, that’s discovery work, not just delivery.

Ignoring this is costly. Jeff Patton nailed this when he said that if you double delivery demand will quadruple. What you really need is maximum outcomes per minimal output. This can be thought of as similar to Tufte’s “data-to-ink ratio”, only here it’s an “outcome-to-output ratio”. In design, delivering faster than you can learn is waste.  

This is when some people tell me, “But but but, Agile does care about design and discovery work!” Really? Be honest here. If you do design or UX research for a living, then answer this question. How are you typically treated when working with Agile teams? Are you seen as an asset and asked to help teams inspect and adapt? Or are you accused of slowing things down and asked to “demonstrate your value”? Yeah….

As Alan Cooper has said, when you’re asked to demonstrate your value, they are letting you know you are in a system that already doesn’t value you. They don’t ask this of every role. Notice too they’re asking this of certain individual contributors but aren’t asking how much work in general moves outcome metrics in the right direction. Now, you’ve heard of throwing spaghetti against the wall to see what sticks, right?

Well, all this worry about “slowing things down” without any focus on outcomes is sort of like focusing on the speed of throwing spaghetti…but without a wall. Who knows what “sticks” if no one is even looking and it’s always just “On to the next thing!” So, if you do discovery work with Agile teams, the next time you’re asked to “demonstrate your worth”, try this. Turn the tables and start asking them questions: 

Do they know what cost of delay is? What exercises are they using to estimate it? What concrete outcomes are they trying to achieve? Do they even know? What proportion of what they build moves target metrics in the right directions? If there are faster and cheaper ways of learning what to build, would they be interested in learning? What’s their flow efficiency? How much of that time do they spend stuck in meetings? If there are activities that can drive better decisions in much less time, would they be interested in learning? 

Forget demonstrating your value. You’re valuable because YOU CAN HELP THEM CREATE MORE VALUE IN EVERYTHING THEY DO.

You can help them go after and obtain more value than they were even considering.

Keep the focus on demonstrating value, just expand the scope of the question.

Until next time.