It's difficult to predict the future despite the techniques we use to try to do just that. The
reality is that planning out even a simple software development project is a challenge.
There are many different variables to take into account, and therefore, an equal number
of reasons for things to go wrong—sometimes horribly wrong. When it comes to
delivering software against upfront predictions, we often don't get it right. This is well
documented . Yet our tendency to plan this way 1 seems deeply ingrained.
Here are five common mistakes we make, and some ideas to consider that will make
planning more valuable.
1. We underestimate the complexity of software development.
Software development often gets compared to building construction. That seems like a
fair comparison at first sight because software developers “build” things. Unfortunately,
software development work varies fundamentally from traditional construction. When
using similar planning techniques, expect many challenges.
In his book, The Black Swan, Nassim Nicholas Taleb describes two different
worlds, Mediocristan and Extremistan, each representing two different kinds of
To demonstrate the difference, Taleb suggests the following thought experiment.
Round up a thousand people randomly selected from the general population and have
them lie down head to toe to form a giant line.
Assume that the average height of the given population is 5 feet 6 inches, so the line
would be approximately 5,500 feet. If we needed to estimate how many people we
could accommodate in an 11,000 foot space, we could probably come up with a pretty
reasonable estimate (i.e., about 2,000 people).
What would happen if you rounded up another 1,000 people. This time however, you
include the world’s tallest man (Sultan Kösen, 8 ft 3 in)? In this scenario, we’d only be
able to accommodate 1,999 people. There's no significant impact on our original
estimate as the result of including one sample of the absolute worse case scenario in
Now try the same experiment, but use a different measure.
Round up 1,000 people randomly selected from the general population and record the
net worth of their families. Assume that the average net worth of a family in the United
States is $110,000. So for our sample group, it would total $110,000,000. Next, estimate
the size of vault we’d need to store the net worth of 2,000 people. We could figure out
the size required for 1,000 people, double it, and we’d probably be pretty secure with
Now round up another 1,000 people, but this time, include Bill Gates in your sample.
What happens to your prediction? We originally predicted needing a vault that would
hold $220,000,000 and now we need one to hold $77,500,000,000. How much of a
difference did one unfortunate sample make?
How is this relevant to software development?
If you’ve had any experience developing software, you have probably come across a
problem that you just couldn’t solve. Perhaps it's a bug that just refused to be fixed.
Maybe it's a technical problem that you just could not solve given the tools you had on
hand. An original estimate wasn't just a little off, but off by more then just a factor of
10%, or 20%, or 500%. That’s the world of software development. That’s Extremistan
(the second thought experiment), where one event or element can have a huge impact.
Most building construction projects live in the world of Mediocristan (the first thought
experiment), where individual deviations are balanced out in the whole. Repeat the
same thought experiment with 1,000 randomly selected office towers and lay them end
to end. Now throw the world’s tallest building, the Burj Khalifa, into your second sample.
Is the end result more like the net worth example, or people’s height.
So, how do you avoid mistaking Extremistan for Mediocristan? By thoroughly
understanding the type of work that you’re planning. If the effort to complete the work for
one items has the potential of being vastly different from other items, use appropriate
planning techniques. The empirical planning techniques used in Scrum are more
appropriate for projects that live in Extremistan.
2. We don’t plan for the truly unexpected.
Dealing with complex work requires a different type of risk management. Typical project
planning uses buffers to account for the unexpected. The underlying hope is that all
unknowns will average out, and that lost time in one area will be picked up by time
made up in another area. But, complex work doesn’t always allow for that.
Examine the following diagram.
In managing this project, we might feel confident about our ability to deliver by the
planned release date. But let’s imagine the facts behind the diagram are the following:
A. You’re a turkey
B. The progress you're tracking is your weight
C. No one told you about Thanksgiving, which is the date on the graph marked by the
red squiggly line. What happens to turkeys on Thanksgiving?
Now how do you feel?
Nassim Nicholas Taleb’s uses this metaphor in The Black Swan, to illustrate the impact
of unexpected events. The turkey in our diagram has no concept of Thanksgiving and
no amount of buffering the estimates will help. Typical planning isn’t equipped to
deal with such large-impact, unknown events. In software development, they are
So, how do you to avoid this mistake? The Scrum framework prescribes creating
potentially shippable increments of software at regular intervals. You mitigate risk by
shipping early and often, not by buffering and counting on the law of averages to help
you out. If the unexpected happens, there is an opportunity to still take advantage of
what’s been built.
3. We make commitments to our stakeholders that we can’t
So if we know that software development is complex and risky, why don’t we
acknowledge that with our stakeholders? Why do we make commitments that we’re
unable to keep? The answer that I hear consistently is that business leaders demand
some certainty. They need to set budgets; they need to make sure that dependent
activities are planned; they want a deadline and they want all of the desired features.
But are set-in-stone commitments required?
Most business professionals understand risk. They also understand that in business,
you often need to take a risk to achieve a return or profit. Often, the level of risk has a
direct relationship to the potential return. Most businesses would love a guaranteed
return on their investments, but they know that the profit on those types of investments
is so low that it's often not worth the effort to invest in them. If it’s a sure thing, then why
isn’t everyone already doing it?
If your business stakeholders already understand that relationship between risk and
reward, why wouldn't software development follow the same rules? Each new release
has an element of reward. Good projects go through an exercise to calculate their ROI.
If the return for a project is significant, then stakeholders must expect some level of risk.
So have that conversation with your stakeholders and explain that they may not get all
of what they asked for by the date they’re planning. That’s the risk inherent in software
development. That’s not to say that you can’t mitigate the risk, but you need to have that
If stakeholders want commitments, then make commitments that you know are possible
to meet. Commit to collaborate. Commit to following your process. Commit to quality.
Commit to continuously inspect and adapt. Commit to transparency.
Talk to the stakeholders about the relationship between risk and reward and explain that
the building of new software follows those same principles. Discuss what risk mitigation
strategies you’re going to employ and only commit to what is within your control.
4. We lead our stakeholders to think some work is free.
When we promise our stakeholders a set of features by a certain date, with a certain
budget, the mindset of those stakeholders is that those features have been bought and
paid for. As a planner, you’ve committed to delivering them. The risk is that your
stakeholders might start thinking of those items as having no further cost. They’ve
already paid for them, so from their perspective, they’re free. From their point of view,
they only have to worry about the cost of change. In Dan Ariely book, Predictably
Irrational, he describes the interesting change in behavior that free presents:
“Most transactions have an upside and a downside, but when something is FREE! we
forget the downside."
If your stakeholders understand that every feature isn’t guaranteed until it’s done, they
will be more involved in making choices and tradeoffs. They’ll insist that a high value
feature gets completed before other less important items. They’ll be less willing to
allocate effort to items that are lower in priority.
To avoid this mistake, continually remind your stakeholders that there is no guarantee
that any item in the plan will be delivered, until it’s actually delivered. Throughout the
project, work with your stakeholders to set priorities. Scrum’s Sprint Review gives your
stakeholders regular opportunities to inspect the progress, discuss the remaining work
and set priorities.
5. We don’t behave professionally.
Imagine you’re planning to have eye surgery. Your surgeon knows that historically with
this surgery, there is a 10% chance that there will be complications and that instead of
your eyesight being corrected you will lose all vision in that eye. The surgeon decides
not to share this fact with you, because he decides that if you knew this, he’d lose your
business. Imagine you undergo the surgery and unexpectedly lose your eyesight? You
then you find out that the surgeon knew about the risk and didn’t tell you. The surgeon
would experience serious consequences. This certainly isn’t the behavior we expect
from a professional.
Would it be any better if the surgeon told you of the risk, but then told you, “Don’t worry,
I’m such a good surgeon that I guarantee that won’t happen”. Is that any more
This scenario is played out routinely during software development projects. We lie to our
stakeholders. Our intention behind lying may be bad (to get them to sign a contract) or
good (to minimize their discomfort) or we may only be lying to ourselves. The result is
still the same. It is unprofessional.
To avoid this mistake, be honest, even if it’s not easy. That will allow the stakeholders to
correctly assess the risks and plan for them. A Scrum professional uses and promotes
Scrum’s empirical foundation to help stakeholders deal with risks.
It’s difficult to predict the future. When planning the complex work of software
development, we make many common mistakes that have historically resulted in low
success rates. Using the Scrum framework prevents these mistakes.