I have definitely seem people take ‘we’re Agile’ to mean ‘we don’t plan anymore.’ And it usually leads to a lot of activity but not a lot of value.
“We’re agile—we don’t need to plan.” “If you fail to plan, you are planning to fail.” Which is right?
In this episode, Peter and Richard explore two common mistakes around planning—either trying to plan everything or not planning at all—and why the alternative is something that looks like both planning and execution at the same time.
Contact Us
Interested in implementing these ideas in your organization? Contact us to schedule a conversation with our team. We’re here to help you transform your planning processes and achieve better results.
Subscribe, Like, Share
If you haven’t subscribed to the show yet on YouTube or your favorite podcast app, why not do that now? We’re planning to continue shipping an episode every week, and we’d love to have you on the journey with us. Click to subscribe now.
And please rate and review the HW Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share. Your help spreading the word is super meaningful to us!
Episode transcription
Peter Green
Richard, I was recently searching several national audio archives, and I came across some real gems that were all surprisingly related to today’s episode.
Richard Lawrence
You were searching which archives, now?
Peter
Yeah, several national archives. So today, I’m happy to be able to provide a world premiere of this historic media. Ok, here’s the first one, and the attribution of this audio was a little shaky in the archive, and it’s hard to tell from the audio:
“Failing to plan, is simply planning to fail.” Now, it’s unknown who is speaking in this recording. Some sources I looked at say it is Ben Franklin, which would be pretty surprising from a timeline point of view. Others claim it’s Winston Churchill. It’s hard to say for sure. It may have even been my grandfather, who used to say the same thing frequently enough that I remember him saying it, and it does sound a bit like him.
Richard
Uh, Peter, it really just sounds like you doing a bad British accent.
Peter
Yeah I know, it’s pretty interesting how similar my voice is to those historical figures! Ok, here’s our second clip, which we do know the source for:
“In preparing for battle I have always found that plans are useless, but planning is indispensable.” Now, many of our older generation listeners will recognize that voice as former president Dwight D. Eisenhower, talking about his experience leading the allied forces in WWII.
Richard
I’m pretty sure that was still you but doing a bad 50s midwestern accent this time.
Peter
I know, the similarities are kind of eerie. Ok, two more quick clips to go here. This next one is quite old, and the audio is pretty scratchy, but I think you can still make out what they’re saying:
“No plan survives first contact with the enemy.” Now that was Prussian military strategist Helmuth von Moltke the Elder, sometime in the mists of the 19th century.
Richard
No, that was definitely you channeling your inner Flula Borg.
Peter
Hahaha, I know it’s so weird how those historical figures all sound so much like me. Ok, last one, and this one is pretty recent. Ready?
Richard
Yeah, I guess.
Peter
Ok, here we go:
“Yeah, everybody got a plan till they get punched in the mouth.” Our listeners may remember this quote from the 1996 press conference preceding Mike Tyson’s fight with Evander Holyfield.
Richard
<sarcasm> Mm hm. That was definitely Iron Mike Tyson in that audio clip.<sarcasm>
Peter
I’m glad you finally are coming around on the provenance of these historical clips, Richard.
Richard
Oh man.
Peter
And just so the lawyers don’t need to get involved, (sped way up): “these clips are reenactments of famous quotes. Anyone with half a brain will recognize that there were no recordings made in the time of Ben Franklin or Helmuth von Moltke, and that we’re doing a silly bit here.”
Richard
Seriously though, there are so many famous quotes about planning. Agilists will certainly recognize this bit of the Agile Manifesto: “…through this work, we have come to value Responding to Change over Following a Plan.”
Peter
Ah, that sounded a bit like Ward Cunningham. Have you been in the audio archives too Richard?
Richard
No, that was just me. Anyway, planning is a uniquely human capability–to cast our minds into the future and imagine what we’ll do, and then capture those ideas, and if the effort is big enough, try to get others excited and on board with participating.
But planning really is, in its essence, predicting the future. Two important things about that process: One, some things are more predictable than others. and two, some things are more costly to get wrong when we’re predicting them. This leads to all kinds of interesting psychology, where we try to talk ourselves into believing the future is predictable and that if things go wrong, we’ll be able to correct them.
Peter
And it leads to the two most common mistakes related to planning. The first mistake is to plan everything down to the last detail, and the second is to say, “Well, this thing is pretty unpredictable,” and then throw up our hands and jump in to working on it with no plan. We’ve found this to be a false dichotomy. There’s a third way. Over the years, we’ve developed this third way to work across multiple industries and contexts, and in this episode, we’ll share the key breakthrough. But first,
This show is a free resource sponsored by the Humanizing Work company, where we help organizations get better at leadership, product management, and collaboration. Visit the contact page on our website, humanizingwork.com, and schedule a conversation with us if your organization wants to see stronger results in those areas.
Richard
If you find this content useful and want to support the show, the best thing you can do if you’re watching on YouTube is to subscribe, like and share the episode, and click the bell icon to get notified of new episodes. Drop us a comment with your thoughts on today’s topic. If you’re listening to the podcast version, the best thing you can do is give us a five-star review on your podcasting platform, and share the episode along with your thoughts and your questions on your social media.
Peter
Ok, let’s talk about the first mistake: overplanning. There are dozens of cognitive biases that lead to the prevalence of this mistake, including optimism bias, hindsight bias, and the tendency to feel like if there are lots of details associated with a thing, that thing is more likely to be true. At the beginning of an initiative, everything seems possible. At the end of a project, we retrospect, notice the things we didn’t plan for, and resolve to “plan better next time.” And so we create ever more detailed plans, feel more certain that this time we got it right, and just often enough, we get lucky and things do go according to plan, and that reinforces our belief that our excellent planning caused us to succeed.
Richard
Our long-time listeners are probably familiar with Dave Snowden’s Cynefin framework. In Cynefin terms, this first mistake stems from treating our initiatives as if they were squarely in the Complicated domain, where thoughtful analysis by experts can show us all the answers. But the reality is that most things worth building have significant amounts of complexity. A lot of the data you’d need for thorough analysis doesn’t exist until you actually start solving the problem and getting real humans interacting with the solution. It emerges.
In many ways, the agile movement came into existence to try to address this challenge, and from our perspective, this is the key management breakthrough related to agile—the acknowledgement that our most important initiatives are complex and that an approach that assumes we can predict everything up front is bound to get us in trouble.
Peter
So that Agile value we quoted posits that responding to change is more important than following a plan. That is aligned with the advice in several of the quotes from the intro. But our experience is that some in the agile community took this as a license to largely ignore planning altogether. We swung the pendulum from problem one: we plan everything, to problem two: let’s just get started and figure it out as we go. Richard, have you ever seen that second approach, and have you ever seen it work?
Richard
I have definitely seen people take “we’re Agile” to mean “we don’t plan anymore.” And it usually leads to a lot of activity but not a lot of value.
There is one characteristic of software development, the context in which Agile emerged, that allows us to get away with that to a certain extent, something that’s not true of most industries, and that’s the low cost of iteration. Over the last few decades, it’s become increasingly fast and more inexpensive to iterate on software. So, if we get something wrong, the cost of change is rather low compared to, say, building a highway or even a house. If we discover something is wrong in those fields, we’re in trouble.
Peter
Right, in the software industry, we could get away with being a bit lazy in planning and still deliver something. And this probably reinforced that second mistake in the world of software.
Richard
Exactly. But it doesn’t mean it’s the right approach, even in software. I’ve noticed teams that take the “we’re agile so we just build” tend to experience painful surprises like discovering missing functionality or technical issues late in some kind of development effort.
In the industry, we’re in the midst of a change of perception here, I think. Too much “We don’t need to plan,” along with several other challenges with clunky agile delivery, have started to swing the pendulum back to more detailed up-front planning, or at least a desire for it. We’re just oscillating back and forth between the two mistakes, though.
Peter
But for years we’ve been practicing and teaching a third way. The third way is not as simple as “well, let’s do a little bit of planning.” That’s like a compromise approach, rather than a breakthrough. How much planning is enough? When should we stop planning and start executing? Everyone is likely to have different opinions.
Richard
For a long time, we just referred to our approach as “Agile Planning… as we teach it,” since agile planning is not really a standardized thing. It was simply what we’d seen work to break the conflict between too much planning and too little planning.
Our approach was first to explore a big idea at a high level to see if it was worth further investment. So you might do some customer research, craft a vision statement, model the business case, run some product assumption tests– That sort of thing.
Then, if something was worth pursuing further, we’d use our Feature Mining technique to find a first slice of that big idea to build with the goal of creating some value, reducing risk, and learning more in the process of building that first slice. In Cynefin terms, this was essentially designing and running a probe of the core complexity of that big idea.
Finally, once the core complexity was resolved and things had become more predictable, it made sense to start planning and forecasting a bit further out, using a backlog of features and user stories.
This reduced risk early in a way that we described in another recent episode as “earning green,”
Peter
Right– referring to the traditional project management technique of using stoplight colors for the status of a project. Green projects are on track, no major issues, yellow ones have some issues but the team thinks they have them under control, and red projects are when they discover that “they didn’t have them under control, we’re in trouble and we haven’t figured out how to solve them yet.” Then, most projects start green because we’ve done this detailed plan and we’re feeling optimistic. Then we encounter the complexity in the project, often late in the project, and the project flips to yellow or red. Our advice is to start every project red, since we objectively have the least information we’ll ever have about it, and through early execution focused on the most complex, risky aspects, we have to earn green over time.
Richard
In our minds, our planning approach was drawing a line between planning and execution somewhere around “do just enough planning to align and then get started.” So, minimal planning, with a quick move to execution, but making a point of executing the complex stuff first.
And for contexts with a low cost of iteration, like software, it made total sense to think about it that way. But some companies we worked with struggled with that early move into execution, especially those that were in a context where they had high costs of iteration.
Peter
Our thinking of where to draw that line changed a bit when we came across Bent Flyvberg’s fantastic book “How Big Things Get Done.” Flyvberg is a Danish economic geographer, which is the coolest job title ever, and he’s a project management expert. He teaches at Oxford. His book describes lessons from his work on what he calls mega projects, things like building a new light rail, or nuclear power plants, and other very large things like that. He spends the first half of the book recommending WAY more planning than what usually happens on almost any project. The way he put it was “think slow and then go fast. As we read, we thought “that may make sense for complicated domain projects.”
And then we got to the chapter that he calls Pixar Planning. Pixar’s focus on story telling is pretty legendary. But they were founded on a technical premise, the belief that computers were just getting good enough that you could animate an entire feature film in the computer with no reliance on traditional hand drawing. That first experiment became Toy Story.
And all these years later, as the graphics have improved, the computer power to render a modern Pixar film is still immense and costly. In other words, the cost of iteration is high. And so Pixar starts work on a new film by inviting the director to cobble together a rough cut of the movie including story boards, character sketches, early dialog often recorded by employees, and placeholders for missing content. The director then brings that to a weekly review meeting to get feedback. That process often goes on for multiple years. In agile terms, they’re doing early iteration on the final project. But none of it is “releasable” from a quality standpoint at Pixar. In Pixar’s culture, they’re still in what the film industry calls development, which is still planning, not production. They draw the line between planning and execution much further down the road than we would.
Richard
And Flyvberg cites other examples, like architect Frank Gehry doing hundreds of physical models of a building before going to construction drawings, working out the complexity. And that, in Flyvberg’s terms, is still planning.
We realized these techniques are completely aligned with what we’d taught and practiced in industries with higher iteration costs. The only difference was the label. When the cost of iteration during execution is high, we naturally spend more time in planning. But it’s critical to include a phase of active, hands-on planning to address the complexity, not just jump into analytical, predictive planning.
So now, when we’re talking with industry leaders where the cost of iteration is high—or even where there’s just a concern about falling into the “we’re agile, we don’t plan anything” trap—we simply share our usual approach and call this part “active planning.”
Active Planning breaks the conflict we encounter with the two common mistakes: assuming everything is plannable through analysis, and assuming that if the cost of iteration is low, you don’t need much planning.
Peter
No matter what you call it, the essential practice is the same. Start with the core complexity and test it with real things. Whether that’s an early iteration of software, a clay model of a building, a rough draft of a video, or a prototype of a medical device, when things are complex, we plan by doing. And then, as the order emerges, we can start analyzing and making more detailed plans for the rest of the execution.
Richard
If you found this information valuable, we’d love for you to share it with your colleagues and your network. And don’t forget to subscribe to our channel and hit the notification bell to stay updated on future episodes where we’ll continue to explore ways to humanize work and improve organizational effectiveness.
Peter
For those of you looking to implement these ideas in your organization, we invite you to visit humanizingwork.com and schedule a conversation with our team. We’re here to help you transform your planning processes and achieve better results wherever you need the help.
Thank you for listening, and we’ll see you in the next episode of the Humanizing Work Show!
I say, old man, quite the excellent episode.
Last updated