The end of planning?

If you think about it there are only two fundamental approaches to solving a problem. Either you plan how to solve it first and then try to follow this plan or you just jump in and start solving the problem without planning at all. Between these two extremes one can create an infinite number of combinations of planning and capability. In this post I want to show a slightly different view of the relationship between agile and planning and how this relationship is evolving.

The waterfail process

In agile texts the waterfall process is the commonly vilified archetype of a completely planning based approach. In it’s most simplistic incarnation the initial plan is perfect and the rest is “just” execution. More realistic variants of waterfall allow for changes, but these have to be planned in detail and agreed upon in a change control committee before anyone is allowed to execute them. A planning mentality also permeates a waterfall organization. Managers believe that as long as the plans are good enough the developers do not need to be very skilled. When things go wrong, focus is on improving the plans, not enhancing the capabilities of employees.

Some people believe that agile is the opposite of waterfall but that is very misguided. Planning is an integral part of all major agile methods. Even the agile manifesto focuses on flexible plans, not on getting rid of them. I do not know of an official name for a completely unplanned approach to problem solving so I call it:

The Chuck Norris process

In the Chuck Norris approach to problem solving, nothing is planned and problems are solved as they arrive. Chuck Norris depends on a superhuman capability that allows him to solve any problem he is faced with. If five men with machine guns attack him we will intuitively see the correct order to kill them.

If you have developed software you have probably experienced something close to the Chuck Norris process while you worked on fixing bugs. It is that magical feeling when things really flow and you are able to fix bugs as fast as they appear.

There are software teams that approximate the Chuck Norris process in the way they develop software. These teams typically consist of extremely experienced developers that have been working on the same system for ages. They know the system so well that they can develop many features with minimal planning.

Finding the perfect mix

So the question you probably are asking yourself is: Which mix of planning and capability is the right one? Should I be putting more or less emphasis on planning?

Well, there is no perfect mix. Or to be more precise, the perfect mix of planning and capability depends on your context. To see this lets take two examples of real confrontations the Israeli military has been involved with. The reason I use the Israeli military as an example is that they are widely seen as one of the most effective fighting forces in the world.

The power of capability

Many people believe that military organizations are the perfect example of hierarchies. Orders flow from top to bottom and everyone does exactly as told. In fact, the best military organizations (such as Israel’s) do not work like this at all. Yes, there is a chain of command and orders flow down the chain, but these orders focus on objectives. An order could for example be: “take that village”. At every level people are trained to take independent decisions in order to achieve the goal. If a road is blocked, an armored vehicle will take an alternative route without asking for permission. This way of working allows the Israeli forces to be very flexible and quick to react to unexpected developments in the field. Planning has to a large degree been replaced by capabilities. These capabilities are the result of a very extensive and focused training program that all military personnel go through.

The power of planning

In 1981 the Israeli Air Force bombed a nuclear reactor near Baghdad. In order to reach the target the fighter jets involved had to fly over a large part of Saudi Arabia and Iraq. The planes were fitted with extra fuel tanks in order to be able to make the round trip. This operation would not have been possible without extensive and very detailed planning over the course of at least five years. Almost everything was planned up front and the margin for errors in these plans was probably extremely small. Yes, the pilots had no lack of capabilities but these were directed towards following the plan.

Getting to the right mix

Software development has been shifting gradually away from an extremely planning based mentality to a more and more capability based one. The most popular agile process – Scrum – contains many elements that emphasize capability over planning with the concept of self organizing teams being one of the most prominent. On the other hand, in standard Scrum everything must still be planned up front in sprint planning. These plans do have a shorter scope and are more lightweight than in a waterfall process but most Scrum implementations do not allow team members to just go ahead and solve problems. That risks breaking the sprint, which is seen as very bad.

For me, the growing interest in Kanban based approaches is a further step away from a planning mentality. In a typical Kanban implementation many tasks are still planned but the amount of planning is based on the task itself, not the process. Tasks can be performed with virtually no planning if the solution is evident.

Does this mean that Kanban is “better” than Scrum? Of course not! The amount of planning in Scrum is preferable in some contexts and a problem in others. It is also possible to adjust the amount of planning in Scrum to some degree according to your needs. My belief is that being truly agile is about having the ability to tailor how much planning you need depending on your context.

In a later post I will explore how different contexts influence how much focus you should place on planning versus capability.

Niklas Björnerstedt

Posted on 2012.11.07 at 22:33

Comments are off for this post.