As IT professionals, we understand the importance of an agile, iterative development process. However, it is usually very difficult for most clients to understand this approach to project management. Most clients are typically used to a waterfall approach to software development.
What is Waterfall Project Management?
Waterfall project management is a process whereby a long wishlist of features are created up front. The wish list is sent off to a development team to estimate the time and cost to build all of the features. A project plan is mapped out based on those estimates, the features are locked into place, the design work occurs, then development, then testing. This approach is commonly used in other sectors, and therefore seems like a logical thing to do.
In short: waterfall is a plan-driven approach that fixes scope and estimates time and cost. Scope, time and cost are what is known as the iron triangle in project management. It is called an "iron triangle" because one side of the triangle cannot be changed without impacting the other sides. If you add more scope, you need to add more time and money, in other words.
Because scope is locked in the triangle, waterfall project management resists changes to the plan. Because it is plan-driven, and because change in scope is inevitable in a discovery process, the risk of failure increases as the project progresses. Features will inevitably change, and estimates will always be off.
What is Agile Project Management?
Agile project management, on the other hand, accepts that scope is often not truly known at the onset of a project and will change. Clients typically have a rough idea of what the final product should be like, but haven't really thought about it in the exact kind of detail that is needed to program a computer to bring their vision to life.
Agile project management embraces change. Rather than fixing scope and estimating time and cost, the iron triangle is flipped upside down. The client's budget is used as the primary lock on the triangle. Budget and time are locked down, and the scope is adjusted to stay within the constraints of budget and time.
In an agile project, the most important features that deliver the most value are worked on first. In doing so, the risk declines as the project progresses.
So What Does This Have To Do with Football?
Alright, pregame is completed. Let's talk about The Big Game. It sure is a super one, but for legal reasons, you'll have to just read between the lines here to know what game I'm talking about. ;)
One of the biggest struggles clients have in understanding an agile approach comes with estimation. If we are experts in developing software, then why can't we estimate? Why is it so hard to estimate software development, even for experts?
At the beginning of the project, the developers typically know the least about the business domain and the business, and the client typically knows the least about how software is constructed. The client falsely assumes that the majority of the work is in writing the code, when the actual bulk of the work is figuring out what exactly to write. The first is much easier to estimate than the latter, and that is the reason estimating for software development is so challenging.
When you estimate against uncertainty, you have a higher probability of being wrong. According to the Cone of Uncertainty principle, the estimate can be wrong by as much as 400%!. As the project progresses, uncertainty decreases, and estimates become more accurate.
So, back to The Big Game...
To explain why it's difficult to estimate, even in a discipline you've worked with for decades, we can use a football analogy. Of course, you have to be talking to a football fan for this to make sense, but feel free to sub in baseball, basketball, soccer, golf, lawn darts, etc.
If you've watched football most of your life, you can consider yourself a bit of an expert. However, there is a lot of uncertainty surrounding a football season. Who will be injured? What will the schedule look like? Who will be drafted? Who has trained and improved during the offseason? Teams will shift their strategies to keep their opponents (and fans) guessing.
Therefore, at the beginning of the football season, it's difficult to answer this question: "Who will be in The Big Game this year?" Sports analysts, Vegas oddsmakers, and armchair quarterbacks around the globe will argue their opinions, but it's pretty rare that someone will estimate it precisely. These are just estimates, estimates that are centered around a lot of uncertainty.
Now, fast forward to the end of the season. As the playoffs roll out, you can get a better idea of who will go to The Big Game -- you've now had a whole season to see how the teams play in various scenarios, which players are healthy, which strategies are prevailing, etc. Even then, it's difficult to predict who will play in The Big Game, but you have a much higher probability of accuracy at the start of the playoffs than you did at the start of the season.
Lastly, The Big Game itself. You've had the whole season to watch two teams make it to the coveted showdown. Perhaps it's the season's best offensive team squaring off against the best defensive team. But, still, there is much uncertainty. Ask yourself: what will the final score of The Big Game be? Even with all of the expertise gained from the season, it's still hard to predict.
This is the big point -- estimates are not the same as guarantees. No one can guarantee the final score of The Big Game. To assume one can and to bet the farm on it, well, that's just silly. However, what you can do is give a pretty good range of what the outcome might be. When developers say "we can't estimate at all", that's too far to the other extreme. What they really are pleading for, though, is to not be held to a Big Game score prediction that they know they have no chance of being exactly right on. We know with pretty good certainty, for example, that the score will likely not be 150-130, but we can’t say with certainty it will be 37-24.
This is the primary difference between accuracy and precision.
As experts, we can give an accurate estimate in the face of uncertainty, but we can't give a precise estimate. By analyzing previous Big Game scores, it's probably not likely that either team will score more than 50 points. It's also very probable that one of the teams will score at least 3 points. Therefore, we can accurately say that the score will likely be somewhere between 3 and 50 points for each team. That’s a big range, but that’s because there is a lot of uncertainty. The bigger the range in the estimate, the more uncertainty is involved. As uncertainty increases, the more important it becomes to use adaptive planning (agile) instead of predictive planning (waterfall).
After the first quarter, though, we'll be able to better guess the score. If it's 17-10 at halftime, then we can say we'll know the score will be at least that, and will probably not more than double, so it's not as risky to say it would probably not be more than a 35-10 final score. Likewise, by the third quarter, the uncertainty decreases even further, and by the fourth quarter, we are pretty certain about the final outcome. By the two-minute warning, unless the score is close, we can feel really confident in our estimate and have a good feeling about who will win the game.
With agile development, the feature list is constantly analyzed, reprioritized and adjusted just-in-time, so as to deliver the most amount of value without going over budget, because we know that change is inevitable, and that uncertainty will naturally occur. By the time you are in the 3rd quarter of an agile project, you have valuable working software that is much closer to your actual needs than what you would have gambled with by betting all of your chips in the 1st quarter using a waterfall approach when uncertainty is at its peak.
So, what are your estimates for The Big Game? :) Feel free to leave your predictions below, and then hone them as you get deeper into the game and your uncertainty decreases.