“Plans are of little importance, but planning is essential.” – Winston Churchill
Churchill famously lost his job as First Lord of the Admiralty as a result of the failed Gallipoli campaign during the first World War (despite it not really being his fault). He then oversaw the far more difficult and arguably more important effort of taking on the Axis Powers in the second World War. You might say he had plenty of experience, both good and bad, about plans and planning.
Whilst war is not a perfect analogy for product development, it is similar in that it is a complex environment, where the Cynefin Framework suggests that plans have limited value. In effect, what I believe Churchill is saying with this pithy sentence is that not all planning is equal. Which leads one to question: what kind of plans are value-adding and what is waste?
In the office this week, Paul Dolman-Darrall and DJ Rough were asking me whether I could think of circumstances where we don’t plan. Well, the aforementioned Cynefin framework would suggest that in a chaotic system an “Act > Sense > Respond” approach is more likely to succeed than one where you plan at any level of detail. In effect, it is better not to waste time planning your actions as there is little predictability between cause and effect.
Of course, that’s not true within complex systems, but we could generalise and say that the predictability gets worse the longer the time-frame between cause and effect. There are also effects that become more unpredictable when higher levels of coordination and collaboration is required. This would suggest a difference between planning at the strategic large-scale vs planning at the more tactical small-scale, which lead us to start exploring various analogies and comparisons.
For instance, the level of planning needed on the battlefield depends on the chosen strategy (blitzkrieg, trench warfare, maneuver warfare, guerilla warfare). We also looked at planning in sporting situations. Coaches and managers are often seen as responsible for strategy for the game or the season and the players themselves responsible for tactics at the individual level from moment to moment. In order to make use of a particular strategy (say a wider formation to better leverage your team’s strengths) requires collaboration, coordination and indeed discipline to make effective. We also talked a bit about how the internet and P2P networks operate without detailed planning.
So it seems that the level of complexity affects the value of planning. The more complex a system is, the less value a plan is likely to have. Because product development involves a lot of variability and many “known unknowns” this makes it inherently complex. More specifically, there are three things we know to be true about software: The customer doesn’t know what they want; the developer doesn’t know how to build it; and things change. On top of this there are the “unknown unknowns” that Nicholas Nassim Taleb wrote about in his book “The Black Swan”. With these as system conditions we can see that the value of planning is fairly limited. This is important because you can’t really make an effective plan for things you don’t know. You can make a plan to plan, but any more detail than that is likely to be waste.
So then, why might planning be “essential”, even with these conditions in complex environments? To help understand this I prefer to separate out two important aspects of planning. The delivery and the product.
Planning the delivery
Most of the plans we see in software development are about trying to work out how you’re going to do what needs to be done. We often find ourselves going to the proverbial nth degree of scheduling and identifying dependencies and constraints of the delivery. The questions this attempts to answer is usually: when am I going to get it, and how much is it going to cost. Unfortunately, our ability to predict these parameters are pretty useless. This is especially true when you haven’t even started delivering, when it’s almost entirely guess-work.
Despite the painful experiences we’ve had when it comes to planning the delivery of software, we still whip ourselves, trying to make it work. “Plan the work, work the plan!” is the refrain ringing in our ears. Perhaps if we try harder this time, spend longer, maybe it’ll work. It’s a necessary evil though: zero plan isn’t going to fly. The only trick we’ve discovered that works here is to restrict our plans to short horizons. Like 2-4 weeks.
But that’s not enough I hear you cry, and I’d agree. In my view, the more important thing to focus on is not about the delivery, or “how you’re going to do it” though – it’s about the product or desired outcome (the “what needs to be done”).
Planning the product
What does need to be done? Strangely (or not, as it’s basically human nature) the scope of a project is often the least questioned aspect. Whilst I’m not a huge fan of MMFs or MVPs (or any other “minimums”), they do encourage some thought about what the smallest increment of value might be.
Even better, consider a feature injection approach with a CD3 ordered dynamic priority list to order the features by. To complement this, sketch out how the product might evolve over time and consider how the pieces (or features) might need to fit together from the customer or end-user perspective. This sketch of how the product might evolve could suggest adjustments to the Cost of Delay of individual features. Often, this is either because of information value associated with testing assumptions about market risks, or technical wrong turns and dead-ends. In these cases having that information earlier is valuable to you so you don’t build the wrong thing, or build it the wrong way. A sketch of how the product might evolve should answer questions like: which features to start working on first to validate assumptions; which customers or users to target first; what is needed to make the product coherent; when might the product become a usable increment (as opposed to simply another iteration of unrealised value). None of these require time-frames. I’d go so far to say that attempting to put time-frames on it is a fools game.
So, when considering planning it can help to separate the planning of the delivery and the product – if you possibly can decouple these two aspects, even better. Like so much in software and innovation, the best route from here to there is something you discover along the way. So perhaps the best plan is one which plans the product as a series of short bursts. Act and react. Act and react. But make your plans about the product first, fast learning second – and the date when it will all be done, last.