Yogi Berra was fond of saying “If you don’t know where you are going, you’ll end up someplace else.” What Yogi was getting at was that it’s a good idea to do a bit of thinking, a bit of planning, before you get started. In the previous blog, Planning: When Have you Done Enough? we explored the factors that affect how much planning we should do. The challenge is that the factors are qualitative in nature, requiring us to make a decision that is based on intuition.
In this blog we explore how to increase the chance that we get as close as we can to achieving the maximum value from our planning efforts. The following figure is organized into four planning quadrants, each one of which represents a target area for our planning efforts.
Figure – The four quadrants of planning efficiency.
Let’s explore each quadrant. In order from most desirable, to least desirable, they are:
Eisenhower said “Plans are worthless, but planning is everything.” There can be significant value in planning, but it is possible to go too far, to plan too much. Although more research is needed in this space, it appears that the value of planning follows the law of diminishing returns – there is significant value in doing some planning, but that value quickly reaches a maximum point. Determining that maximum point is a qualitative, “gut feel” decision based on a collection of factors such as the complexity and risk of the situation, the skills and experience of the people involved, and the uncertainty that you face. Surprisingly, the most efficient approach to planning is to aim for your plans to be slightly insufficient, to be close but in need of a bit more work when you discover that you need to work through a few more details. I hope this blog series has been food for thought.
In the previous blog we examined what the value of planning is, so that we can then determine how much planning we need to do. The answer to this question was “it depends,” and the implication was that we need to do just enough planning for the situation that we face and no more. In this blog we go deeper to explore what this depends on in practice.
We learned in the previous blog that our planning efforts should be sufficient, what we referred to as just barely good enough (JBGE) in Agile Modeling, for the situation that we face. The following figure depicts the contextual factors that we should consider, with the factors motivating us to do more planning on the left-hand side under the red arrow and the factors enabling us to do less planning on the right-hand side under the green arrow. These factors are mostly qualitative in nature, implying that it requires a judgement call on the part of the people involved with the planning effort to determine whether they’ve planned sufficiently. Let’s explore each of these factors in more detail.
Figure. The factors to determine whether you’ve planned sufficiently.
There are four factors that motivate us to increase the amount of planning we do:
There are six factors that enable us to reduce the amount of planning that we need to do:
To summarize, the answer to “when have we planned sufficiently?” is “it depends.” In this blog we explored several factors that motivate you to increase the amount of planning we need to do and several factors that enable us to reduce the amount of planning. In effect we went beyond the typical consultant answer of “it depends” to the more robust answer of “it depends on this.”
In the next blog in this 3-part series we explore how to be efficient in our planning efforts. I suspect the answer it won’t be what you’re expecting.
Winston Churchill once said “Plans are of little importance, but planning is essential.” What Churchill meant was that the value is in thinking something through, in planning it, before you do it. So this leads to some interesting questions: How much planning should we do? How can we get the most value out of our planning efforts? I wish I could tell you that there is solid research evidence to answer this question but sadly I haven’t been able to find any (if you know of any, I’d love to hear about it). Luckily though, we do have a lot of experience and observational evidence to fall back on.
From an accounting point of view we know that value is calculated as benefit minus cost. The implication is that all we need to do then is calculate the benefits of planning, and the costs of doing so, apply a bit of math and there you go. How hard could that be? As we know it’s very difficult to calculate the benefits because some are qualitative, requiring a bit of creativity to turn them into a monetary figure. The bigger challenge is that planning is just one activity of many that go into achieving a benefit making it difficult to tease out the planning portion of the benefit earned. Calculating the true costs of planning isn’t much easier when you start to consider the downstream implications of the work required to gather the inputs that go into the planning process. This is a particular problem in creative domains such as software development, more in this in future blogs. The implication is that in practice there isn’t an easy way to determine the actual value of planning, which explains the dearth of research evidence around this issue.
Because there are no hard and fast rules to determine the value of planning, practitioners rely on belief systems to guide their thinking. Figure 1 overviews two common belief systems, the traditional (sometimes inappropriately called “predictive”) belief system and the agile belief system. We’ve labelled the latter as undisciplined because we will distinguish this from a Disciplined Agile (DA) strategy later. The traditional belief system tells us that the more effort that you put into planning the more value that you will gain from doing so. This belief system tells you to think things through in detail before you do them. This increases value by avoiding mistakes in the future, thereby reducing costs. At the other extreme the (undisciplined) agile belief system tells us that there is very little value in planning, that you are better advised in focusing on being able to react to feedback. This enables you to deliver sooner and thereby earn the actual benefits sooner and longer, thereby increasing value. The obvious downside of course is that mistakes will be made, sometimes serious ones, thereby increasing both costs and risks.
Figure 1. What our belief systems tell us about the value of planning.
The methodologist in me tells me that extremes are generally a bad thing, that for most situations the answer lies somewhere in between. The easy answer would be to simply draw a dashed line in between the two curves in Figure 1, or get really fancy and introduce some sort of range between the two lines, but the easy answer is wrong. What we really need to do is look at what actually happens in practice, something that we did in the Agile Modeling (AM) community in the early 2000s.
In AM we needed to determine the value of modeling so as to provide coherent advice around when to model and to what extent to model. To make a long story short, we observed that the value of modeling followed the law of diminishing returns as you can see in Figure 2. A little bit of modeling offered a lot of value. So did a bit more, then a bit more, then a bit more. But very quickly we reach a point of diminishing returns, the total costs of modeling soon exceeds the total benefits of modeling – once a model is sufficient for the situation that you’re thinking through with it, you reach a point where any more modeling removes overall value. This point is what we called the just barely good enough (JBGE) point, although others prefer “sufficient” as a term. So why am I talking about the value of modeling? Because modeling and planning are slightly different flavors of the same thing: Thinking something through before you jumping into doing it.
Figure 2. The value of planning/modeling.
Many people, particularly those who follow a traditional “predictive” lifecycle approach, tend to be taken aback when they’re told the most effective plans are those that are just barely good enough. The problem is that they often interpret JBGE as insufficient, yet by definition that is clearly not the case. If your planning efforts haven’t been sufficient then you can still benefit from more planning, or to be accurate you can benefit from good planning at the right time. But, if your planning efforts have been sufficient, or more than sufficient, then more planning is only going to remove value. From a lean point of view over-planning is a waste.
To summarize, the DA belief system is that the value of planning and modeling follows the law of diminishing returns. There is significant anecdotal evidence that bears this out but as I indicated earlier the research evidence is sparse. I’ve actively prodded researchers along when I could for the past 15 years to get this evidence, but these efforts have always floundered when they discovered that this research is very difficult long-term work.
In the next blog in this 3-part series we explore how to determine when your planning efforts are sufficient. Following that we work through how to be efficient at planning.
In my blog Disciplined Agile Principle: Optimize Flow I wrote the following:
Measure what counts. When it comes to measurement, context counts. What are you hoping to improve? Quality? Time to market? Staff morale? Customer satisfaction? Combinations thereof? Every person, team, and organization has their own improvement priorities, and their own ways of working, so they will have their own set of measures that they gather to provide insight into how they’re doing and more importantly how to proceed. And these measures evolve over time as their situation and priorities evolve. The implication is that your measurement strategy must be flexible and fit for purpose, and it will vary across teams.
Based on that I received the following question:
Regarding number 7 above: Measure what counts. I think that's really important. How would you handle the need for some larger organizations to compare teams, directorates, divisions etc. with uniform metrics? Each effort is so different and will require different metrics.
This is a great question that deserves a fairly detailed answer, so I thought I'd capture it as a new blog posting. Here are my thoughts.
To summarize, it's a really bad idea to inflict a common set of metrics across teams. A far better strategy is to have common improvement objectives across teams and allow them to address those objectives, and to measure their effectiveness in doing so, as they believe to be the most appropriate for their situation.
One of the seven principles behind Disciplined Agile (DA) is Context Counts. Every person is unique, with their own set of skills, preferences for workstyle, career goals, and learning styles. Every team is unique not only because it is composed of unique people but also because it faces a unique situation. Your organization is also unique, even when there are other organizations that operate in the same marketplace that you do. For example, automobile manufacturers such as Ford, Audi, and Tesla all build the same category of product yet it isn’t much of a stretch to claim that they are very different companies. These observations – that people, teams, and organizations are all unique – leads us to a critical idea that your process and organization structure must be tailored for the situation that you currently face. In other words, context counts.
Figure 1 overviews the potential factors that you should consider regarding the context of the situation faced by your team. We’ve organized them into two categories:
Of course it’s never this straightforward. Selection factors will have an effect on your detailed WoW choices and scaling factors will also have an impact on your initial decisions. Our point is that in general the selection factors have a bigger impact on the initial choices than do the scaling factors and similarly the scaling factors have a bigger impact on your detailed tailoring decisions than do the selection factors.
Figure 1. Potential context factors (click to enlarge).
Context factors are interdependent. Figure 2 shows the major relationships between the context factors. For example, you can see that:
Figure 2. Relationships between context factors (click to enlarge).
TACTICAL AGILITY AT SCALE
Let’s explore the scaling factors a bit. As we mentioned earlier, the scaling factors tend to drive your detailed decisions around your way of working (WoW). For example, a team of eight people working in a common team room on a very complex domain problem in a life-critical regulatory situation will organize themselves differently, and will choose to follow different practices, than a team of fifty people spread out across a corporate campus on a complex problem in a non-regulatory situation. Although these two teams could be working for the same company they could choose to work in very different ways.
Figure 3 depicts the scaling factors as a radar chart, sometimes called a spider chart. There are several interesting implications:
Figure 3. Tactical scaling factors faced by teams.
ENTERPRISES REQUIRE ENTERPRISE-CLASS SOLUTIONS
The leading agile method Scrum provides solid guidance for delivering value in an agile manner but it is officially described by only a sixteen page guide. Disciplined Agile recognizes that enterprise complexities require far more guidance and thus provides a comprehensive reference framework for adapting your agile approach for your unique context in a straightforward manner. Being able to adapt your approach for your context with a variety of choices (such as those we provide via goal diagrams) rather than standardizing on one method or framework is a very good thing.
This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.