Project management methodologies involve some kind of estimates on the content of the project (i.e. scope) and effort/duration (i.e. schedule). Simple techniques like WBS (work breakdown structure) with Gantt Charts or more complex techniques like PERT (Program Evaluation and Review Technique) involve estimating the content and ultimately the duration or effort of each of the items of the content.
In project management, this is done in the project time management (PMBOK), and with the aim to “cost” (determine cost) and schedule the project.
At first blush questions such as: How much does it cost? and How long does it take? sound reasonable. Even common sense, right?
The other side of the mirror
There’s something they don’t teach you in project management school. It has to do with buses and planes. Let me explain. Assume you are flying from Munich to Helsinki (hi! from the plane). You look at the schedule of the plain (8:25 lift off, 11:50 landing). You do some mental calculations and accept a podcast recording at 13:00. 1h10 minutes sounds like a good buffer (pay attention to this word) since it only takes you 20 min to drive home from the airport.
So, our little project is now 3:25 long with 2 main tasks (flying, driving) and 1 buffer that sounds reasonable as it is about 30% of the overall project duration. You’ve learned in project management school that a contingency (aka buffer) of 20% is normal and acceptable, so you say yes to your podcast recording.
Let’s break it down
I’m paying for my time. Every minute that I use for something other than work costs me in either an opportunity I don’t take (opportunity cost) or lost revenues from my consulting work.
When I look at this project with my business eyes, suddenly 30% buffer does not sound that good anymore! However, I’ve studied processes (thank you Toyota and Lean community) long enough to know that you need to absorb variability (i.e. things going pear-shaped) and a buffer is an easy enough technique to implement (too easy maybe?).
So I look the other way and continue my project.
The surprise that always happens, but no one expects
I get to the airport on time. Have my breakfast, go to the gate and sit down to wait for the plane.
As I see people getting out of the airplane I get worried. We’re supposed to board now and the plane isn’t even empty from the previous flight? Oho! This spells trouble.
I wait and wait. The plane eventually leaves with 30 min delay (out of a 2:30 flight!), and I start stressing about not making it to my recording session.
What just happened? The most natural thing happened: flights are “all or nothing” options in our personal life projects. They either leave on time or don’t (some even get canceled! Hello Ryanair!). But most importantly for our own personal lives: flights never leave AHEAD OF SCHEDULE! Yep. This simple statement has huge consequences in our lives and our project management approach.
The plane that is always late
It is true that in some cases flights might occasionally arrive ahead of schedule, but usually, that happens when you need to wait for a connection that is late anyway, so the being early benefit gets washed out by the normal variability we expect in flight schedules.
The same thing happens in projects. Tasks or User Stories rarely get started ahead of time, and even if they would start ahead of time, it is likely that they take longer than expected (the average project is 60% late).
So, no matter how much you spend (time, money or both) on estimating the duration and/or effort for a particular User Story or project, it is likely that you will be late. Very likely.
Why being late matters and how to avoid it
How do we avoid this phenomenon of being late? There’s a very simple solution for this problem, but before we dig deeper into that let’s review why being late is critical for us.
In projects, one task or User Story being late is usually not the problem. The problems come from having multiple dependent items that affect each other. This dependency chain usually causes spiraling delays. For example: when one person in the team that needs to contribute to multiple User Stories – delaying many User Stories because of one single previous delay. Another example: the Operations team being late with a different project and keeping your whole team waiting, which in turn keeps the rest of the project waiting.
The key insight is this: spiraling delays are normal in projects. They are entirely predictable (as in we know they will happen), but also entirely unpredictable (as in we don’t know which delays will spiral out of control). So we must prepare for them.
How to prepare for spiraling delays
How we prepare for spiraling delays can make the difference between a slight delay and HUGE delay in our project. The usual way to prepare for delays is (you guessed it) buffers! We add padding to the User Stories or tasks to avoid overall (project-level) delays when an item is late. The project management community will often call this a “contingency” (sounds better than a buffer, especially in the IT industry).
But there’s another way to prepare for delays. One that is a core principle of #NoEstimates: Always be ready to stop the project and deliver value, at any time.
If we are able to release at any time (say, tomorrow!), we can never be late unless we decide to do so!
How to always be ready to release: don’t buffer time, buffer value
In my little real-life example above here’s how I’ve tackled the problem: I fly a lot. Way too much. So much that the hostesses already know me on a first name basis. So I know very well that I CAN NOT trust flights will be on time. I never plan for failure, therefore I always have a plan B for a late flight. Some plan B aspects are easy: changeable tickets, etc. Other aspects are trickier.
Some weeks I need to get home on time to take care of the kids, but if the flight is late I don’t. So I have a network of people around me that will help me when needed.
Other times, like today, I have a recording session for the podcast that I want to make on time, but may not. So I always have a few episodes of the Scrum Master Toolbox Podcast in the queue in case I miss a recording session. And this is a key insight: I traded a time buffer (costs me money) for a content buffer (the queue of episodes), which does not cost me money but still provides me the flexibility of missing a flight or getting delayed without catastrophic consequences, like missing a week of shows on the Scrum Master Toolbox Podcast.
Rethink your buffers
In software, we have the opportunity to do this too! We don’t need to add a time buffer to a project, we can instead, add a scope buffer. Here’s a concrete example: instead of planning to release a whole project “on time” (right! ;), plan to release ahead of schedule, several times ahead of schedule. In other words, if you have to release the product for the Xmas market, why not have 2 to 3 releases ahead of Xmas. For example, you may want to release new versions of the product in September, October and November ahead of the Xmas release at the start of December. If you miss the December release, it’s OK! You still have the September through November releases that you can promote. Sure, you will miss some content, but the most important content is in the earlier releases anyway because it is a higher priority! Right?
Continuous delivery a natively Agile BUSINESS practice
Continuous Delivery is a natively Agile BUSINESS practice. It is not just a technical practice. CD is about delivering value to the market in short periods of time, so that if your flight (or Xmas release) is late, you still have something your customers can benefit from!
Here’s the short version of this argument: don’t take risks you can’t survive (plan to release on time and then fail). Don’t buy into the idea that planning and estimating can help you release on time. There’s a 60% chance that you will be late if you use those methods. Instead, replace planning with continuous planning and estimating with continuous delivery. And Boom! You’ll never be late again!
How are you making sure you will never, ever again miss an important deadline? Share it with us here or on twitter under the #NoEstimatesNoDelays hashtag.
Although this is some old post of you, I came to it through a Tweet today.
It’s a brilliant summary of your No Estimates approach, and the “buffer value not time” motto should be in our office walls.
But I’d like to add an idea: I always say software development estimations are like weather or finances: all of them are part of the mathematical Chaos Theory where there are thousands of variables and any of them can change drastically the results.
Both weather and finance predictions are only accurate in a very short time,… we in software development should think in the same way when giving our estimations (if we have to)…
E.g. Weather rarely give predictions over a week.
Good points Ernesto. If you write a post on that topic, let me know and I’ll link to it!