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 uncertainty.
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 our predictions.
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 our estimates.
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.
In managing this project, we might feel confident about our ability to deliver by the planned release date. But let’s imagine the facts :
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 common.
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 keep.
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 honest discussion.
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 professional?
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.
Summary
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.