Dear Agile, I’m Tired of Pretending (2018)

“Agile is dead.” People keep saying that. But then they say, “We’re just kidding.” They tell you they meant the way you do Agile is dead. And stupid. But “real” Agile isn’t dead. It’s just that everyone does Agile wrong . So I guess real Agile is, you know, Agile in theory . Even I have done this. And you know what? I’m sick of doing it.

I was recently mustering the same old defenses online: “But but but, the problem is Waterscrumfall, not Agile as intended in the Manifesto…blah blah blah.” Then Bob Marshall gave it to me straight. He basically said, “Shut up Charles. The Agile 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 peaking. Don’t know? That’s fine. It doesn’t matter. It says, “We are uncovering better ways of developing software….” Stop. Notice it says, “developing software.” It does not say, “leaning out your org,” “paying down transformation debt,” “cutting it out with this command-and-control crap,” “focusing on outcomes and getting better at discovery work,” “fixing your medieval budgeting system,” or any of the other far more value-adding things people have tried to glom onto it. But the thing is, when people say that Agile pertains to the whole org, it’s revisionist history. It’s dishonest.

Notice too it begins, “We are uncovering ….” It does not say, “We have received from on high….” 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 actually from the Snowbird signing of the Manifesto. Can we finally stop pretending otherwise?

The Manifesto served a purpose, but it’s not going to get you where you need to go. So get to studying. Our knowledge has a shelf life, and it’s sometimes not as long as we assume. We all have colleagues (usually leaders) who claim they “don’t have time to learn,” and you know what, they’re way too overconfident in what they think they know. So find a good booklist. Follow some good blogs. Here’s a start: If you haven’t read Sense & Respond , Lean Enterprise , A Seat at the Table , and Everyone Is a Change Agent , I suggest you do so pronto. Your leaders too.

Start reading posts by John Cutler, Melissa Perri, Bob Marshall, Allen Holub, Laura Klein, Erika Hall, Neil Killick, and branch out from there. Do they all agree with each other (or with me)? No — but they’re smart and they’ll make you smarter. Get to reading, and start encouraging others as well. Fast Company says the average CEO reads 60 books a year. How many books do your leaders read? And what are they reading? ( HBR articles, Gartner reports, and Maeve Binchy novels don’t count.) Because, let’s face it, if your leaders are still trying to grok Scrum, then you’re firmly stuck in the 80s and 90s.

So let’s get on board with continuous learning, and let’s stop pretending Agile was some sort of cure all. This needs to be said: Agile is and always has been a local optimization providing little gain to the system. All Agile did was put software development teams unfairly under a microscope. This does nothing to increase organizational agility. NOTHING. 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,” and yet Agile never gave organizations a holistic, viable alternative to Waterfall. Because there’s a difference between theory and practice. Product work is more about practice. When we complain about “AINO” (Agile In Name Only), we’re not being honest with ourselves.

Theory vs. practice, remember? We need to be pragmatic. Agile in practice is almost always AINO. Seems a problem with the movement itself, doesn’t it? There are more important things to learn about anyway, including (but not limited to) Lean UX, Lean Enterprise, Beyond Budgeting, Theory of Constraints, Throughput Accounting, Design Thinking, DevOps, Marshall’s Organizational Therapy, and so forth.

Why, you might ask, would Lean UX top the list? Outcomes, that’s why, a concept largely popularized by Lean UX. Think about it: If you don’t know what behavior change you’re trying to create, then you won’t know how you should really pivot. If you don’t have unambiguous pivot signaling, then you can’t really be “agile” in the first place. That’s what agility is, after all, pivoting . Some might object and say, “But but but, inspect and adapt!” Sure. Theory vs. practice, remember? 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 wherever they’re told to.

Agile actually tends to mask the core 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 scope and deadlines and efficiency, ignoring that the deadlines are arbitrary and the requested time estimates are 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? Theory vs. practice.)

Well guess who’ll win? Two camps with two radically different perspectives, but with one camp receiving performance reviews from the other? If the teams are like the blind people feeling the elephant and disagreeing on what it is, then leadership is like blind elephants stepping on people and agreeing they’re all flat. The way out is to recognize that the system is the team. Quit with the local optimizations already, and realize trust is the №1 issue. Stop unfairly putting dev under a microscope and letting everyone else hide in a black box. (Why aren’t we just as concerned with how strategy teams operate? Or how legacy architects are constraints in the system?)

And while we’re at it, we’ve got to stop treating dev teams like they work in a factory. We’re not making plastic cutlery. We’re creating software. We need to stop acting like we’re running a pizza joint . The same rules do not apply. We’re not running the same tried-and-true recipe. We’re designing recipes . If you haven’t figured it out, that’s discovery work , not just delivery. A neglect of discovery generates massive waste: Unused features and other work that doesn’t achieve outcomes. This exposes another of Agile’s deep flaws. It assumes users will be OK with being treated like guinea pigs: “Here, just use this crap product then we’ll improve it.” Except it’s typically left a crap product, isn’t it? The future improvements are deemed unnecessary “cost.”

But but but, Agile does care about discovery work! Really? Be honest here. Theory vs. practice, remember? If you do design or discovery work for a living, then answer this question. How are you typically treated when working with Agile teams? Are you seen as value-adding and asked to help them “inspect and adapt?” Or are you asked to “demonstrate your value?” As Alan Cooper has said, when you’re asked to demonstrate your value they are letting you know you are in a system that doesn’t value you. Notice they’re asking an individual contributor to prove her worth — they’re not asking how much of their code actually moves outcome metrics in the right direction. In other words, they’re still focusing on people and not the work itself . They’re probably still focused on cost, not value, ignoring where most of the value is actually leaking away.

If you do discovery work with Agile teams, the next time you’re asked to “demonstrate your worth,” try this. 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? What proportion of what they build actually achieves their outcome metrics? They don’t know? If there are faster and cheaper ways of learning what to build other than just shipping code, would they be interested in learning? What’s their flow efficiency? How bad is it? How much of that time do they spend stuck in meetings? If there are design games and facilitated activities that can drive better decisions in much less time, would they be interested in learning? Because I won’t just show you how valuable I am — I’ll teach you to create more value in everything you do .

This is a different way of thinking. It’s meta. It’s strategic. As Austin Govella notes (and it’s well worth letting this sink in), both Agile and Waterfall are focused on building . Design is about validating . If they’re not interested, look elsewhere. If they’re just heads down, churning out output, focusing on cost, they’ll never even learn enough to realize you tend to get more of what you focus on (ahem, cost). They’re a feature factory. Bail. They’re pretending they are creating plastic cutlery. You’ve got better things to do. Because real value is ensured by options , and options are generated by discovery . The more options you generate and the more flexible your approach, the more possible paths there are to positive outcomes. What are they trying to achieve? Have they explored three to five ways to achieve it? That will drive better decision making by a longshot. One option is no choice. Two is a dilemma. Three, now you’re getting somewhere.

Have you ever heard of the Law of Requisite Variety? The component with the most options controls the system . Apply this to the stupid “Agile vs. Waterfall” power struggle. You had leaders trying to keep control of the system at the top and Agile teams trying to drive value closer to the source (the actual users and customers). The way out of the inane civil war is to teach people to generate options at all levels . The way forward is not “Agile vs. Waterfall.” It’s smart top-down Waterfall strategy work with bottom-up, empirically-driven tactics. Design and discovery work helps with all of this .

So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value.

Now get to learning. (Image adapted from John Cutler.)

So…does this mean Agile’s going away? Of course not. This is just a blog post, silly. I don’t have any power. And if I had my way, Agile still wouldn’t go away. The Agile movement made much of the thinking mentioned here possible. Plus, contrary to popular belief, agile practices were not invented by the Agile movement. They predate it by many decades.

So, no, I don’t want Agile to go away.

I just wish we could start being more honest about it.