On Planning

[Ravindar Gujral]

Let me start this article with a story I heard listening to a presentation by Ricardo Semler: Gary Kasparov, the chess grandmaster, played a computer nicknamed “Deep Thought” sometime in the 1980’s and he won. Deep Thought could think many moves ahead, whereas Kasparov could only think 4-5 moves ahead. So it was concluded that to beat Kasparov, a more powerful computer had to be built that could think many more moves ahead. That’s exactly what IBM did creating “Deep Blue”. Guess what happened: Deep Blue lost. This race went on and on until 1997 when Deep(er) Blue was built. This new enhanced computer could think millions of moves ahead and had all the Grand Master games in its memory. Deep(er) Blue finally defeated Kasparov in a six game match with a score of three draws, two wins and one loss.

The simple question to ask is “Why did something that could plan so far ahead in so much detail lose to someone that could only plan 4-5 moves ahead, even if it was 1 game (and 3 draws)?” Maybe it’s intuition that the machine lacked. This matters, but I think a better question is “If planning in that much detail and that far ahead did not make Deep Blue win resoundingly, what makes us think that planning ahead in detail will give us the winning formula with all the variability we have?” Thought provoking, isn’t it?

Shorter cycle is the solution: I will not go into details as to why short term planning and delivering on those plans is better. I am not saying you don’t need to know what you are trying to achieve (in case of Kasparov, winning a chess match), but the details? I am not sure. Briefly, what does shorter cycle do? A shorter delivery cycle:

• teaches teams to focus on delivery of things that are really important to the customer

• teaches removal of waste

• teaches that one requires a team truly working together

• requires teams of cathedral builders and not just stonecutters

• gives you flexibility and agility

• provides the ability to adapt/change as we learn more details

Another reason for shorter cycle is because, to be honest, you can only predict accurately for a short timeframe with the limited set of changing variables that a short timeframe has. The number of variables that affect delivery over a long term is more than anyone can possibly fathom. And more often than not, your plan will be wrong. We all know this. So why waste the time creating a long-term detailed plan? So here are some questions to ask to see if we are getting the benefits that shorter cycles are supposed to deliver:

• Do teams feel that planning every detail on a long-term basis is essential?

• Do teams really focus and ensure their delivered software is what the customer really wants?

• Does the delivered software run in the customer’s environment every month?

• Are teams building software that will be used immediately in the customer’s business? If not, has the team stopped to ask why?

I guess building software on shorter cycle is important, but to truly change and gain speed, more needs to be done. There must be a change in how we view and think of everything we do. Change so that we do everything in shorter cycle with a rough idea of where we would like to be at the end. Shorter cycles can be assessed and we can make adjustments. We might think we have a complex communication challenge and that detailed planning is required. But maybe the solution is to simplify the challenge.

Maybe we need to go beyond software to help us start thinking in shorter cycle. Maybe we should focus on shorter review cycles for everyone. We know market forces are always changing the financial markets. So should we plan in more details? Instead of budgets that plan for a year, maybe we need shorter budget cycle. We have proven that planning a year of budget in advance is not accurate; if they were, we wouldn’t have final month drives at the end of the fiscal year to manage costs and reach financial targets.

So maybe we need to bring a shorter plan and shorter cycles in everything we do with a view to the longer term goals we want to achieve

[Ravindar Gujral]

Keith, I like your conclusion. This is what I was trying to say that one should form a regular short term delivery schedule and then be ready to absorb change instead of making year long plans.

I guess I was also saying was that to help you do this you have to change the supporting structure for your employees. So to properly facilitate short term planning an organization should make all other aspects of its working short term, for example: instead of yearly employee review, do it based on your delivery schedule; instead of yearly budgets do shorter cycle budgets.

Obviously you can't short change the vision that you want to achieve, so keep that big vision alive, but reach it using small increments.

I do like your conclusions.

[Keith Kendall]

This analogy tells me two things:

1. The incremental benefit of pushing out the planning horizon rapidly diminshes.
2. Kasparov brought something to the game that the software didn't. And that something was nearly greater than the value asymptotically approached by pushing out the planning horizon to, essentially, infinity.

I think that in the analogy you're equating extensive planning with reduced feedback. That was not the case in the chess matches. Each player benefitted from exactly the same feedback cycle (1 move of their opponent) and exactly the same planning cycle (also 1 move of their opponent, at which point they could replan).

In my opinion, what Kasparov might have brought to the game was a better ability to anticipate his opponent's moves and, therefore, a better ability to avoid the local optimization pitfall. If I correctly recall the story, that's what eventually resulted in Kasparov's defeat. They programmed in an analysis of his entire playing history so that the software could better anticipate his moves and weight it's exhaustive planning analysis accordingly. Essentially, they customized the software...not to play better but to beat a single player.

What does this tell us that might be of use to Agile/Lean practitioners? Maybe that once you've found that optimal feedback cycle, knowing the terrain (i.e. your client, the marketplace, etc.) well enough to anticipate their needs and the changes they'll request is more important than extensive planning.