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