“Agile is dead.” People keep saying that. But then they say, “We’re just kidding.” They meant the way YOU do Agile is dead. And stupid. But “real” Agile isn’t. 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: “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 peeking. 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, “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 Agile after the fact.
When people say that Agile pertains to all these things, it’s 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.
Moving on.
The Manifesto also begins, 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. Your knowledge has a shelf life, and it’s sometimes not as long as you assume. You probably 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 book list. Follow some good blogs.
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 90s.
Get on board with continuous learning, and stop pretending Agile was some sort of cure all. 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.
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. When we complain about “AINO” (Agile In Name Only), we’re not being honest with ourselves: Agile in practice is almost always AINO.
Seems a problem with the movement itself, doesn’t it? Yes. Yes it does. Instead of focusing on the productivity of teams (that probably are not your constraint in the first place), focus on the value you are going after. What outcomes are you trying to achieve? If you don’t know, then you won’t really know when you should pivot. So how can you really be agile in the first place? That is what agility is, after all, the ability to pivot.
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. They’re “iterating” and adding “increments,” which in effect means they’re using time-boxed wheelbarrows to fetch the bricks. Big whoop.
Agile actually tends to mask 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 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.
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 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.
Quit with the local optimizations already. Stop unfairly putting teams under a microscope and letting everyone else hide in a black box. Why aren’t you just as concerned with how strategy teams operate? Who gets to decide what problems teams should be solving in the first place? That is probably where far more of your value is leaking away.
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.
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? Do they even know? What proportion of what they build moves target metrics in the right directions? 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?
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.
To close, what Melissa Perri calls “the build trap” is frequently “the Agile trap.”
Avoid it. Turn the freakin’ tables and focus on value.
Charles Lambdin 