Agile Estimation
On 2nd August 1947 Star Dust, an Avro Lancastrian airliner of British South American Airways departed Buenos Aires, Argentina en route to Santiago, Chile. The flight crew was highly experienced RAF veterans, with hundreds of flying hours in both war and commercial planes.
The aircraft was less than two years old, and was based on the highly reliable Avro Lancaster night bomber of WWII fame. At about 5:41pm the captain made his last radio transmission (in Morse code) reporting arrival in Santiago in four minutes time. The plane never arrived, and, although presumed lost, remained undiscovered for over 50 years.
The cause of the crash was not fully understood at the time. In 1947, navigation was done mainly by dead reckoning: calculating the aircraft's position from its heading and speed and time, with corrections derived from reported winds and observation of ground features. During the final flight leg of Star Dust's flight, heavy clouds made ground visibility impossible. It is likely that in the absence of ground fixes a large navigational error was made if the aircraft encountered what we now know as the jet-stream — the high-altitude winds that can sometimes blow at high speed in directions different from those of winds observed at ground level.
At the time, although the jet stream was known, its actions were not widely understood. The Lancastrian was one of the very few airliners of the time capable of flying that high. If the airliner, which had just crossed the Andes at 7,315 meters (24,000 feet), had encountered the bottom of the polar jet-stream zone, which in this area normally blows from the west and south-west, the crew may have been misled into thinking that they were passing through cloud on the final steep descent into Santiago when they actually were many miles to the east-north-east, over the Tupungato glacier. It was in the glacier that the remains of the plane were discovered in 1998.
By the year 2000 about 10% of the wreckage had been discovered as the glacier melted.
The plight of the Star Dust was not due to pilot error as much as it was due to a fault in the accepted method of navigation at the time, compounded by the lack of visibility of the terrain. The crew relied on a flight plan that did not take into account any variation in the ground speed of the aircraft, which was significantly lower than the airspeed due to the impact of the jet-stream. Their plan, although well thought out and executed perfectly, was flawed by a factor outside of their control. More critically, they had no way of observing the impact of this problem due to their lack of visibility.
Does this problem sound familiar to you? It should! Software project management often places too much trust in the dead-reckoning approach. We have traditionally spent a great deal of time (and pain!) developing an elaborate schedule that may extend over a year or more, with little regard for anything that may go wrong along the way. We then execute the plan and rely on status reports that we have to take in good faith, and have no way of verifying. How many times have we heard that the design is 95% complete and all that remains is to write the code? We then discover that the basic architecture is flawed, we have to invest in additional hardware and the supplier of a critical component just went out of business. Our project is about to fly into a glacier!
Developing long range plans and estimates only works well in a predictive environment. If we know exactly how to control all the variables and their impact on the production schedule, then we can use predictive planning techniques. Ford knows how long it takes to build a new F150 truck because it has a long history of building F150 trucks. It knows exactly how fast the production line runs and knows when the annual plant shutdown is. It is all predictable. Software development is not predictable, yet we insist on applying management techniques based on predictable assumptions.
So, let’s be agile. Let’s not bother with all those complicated plans, schedules, estimates etc. We don’t need no processes around here! Let’s just write as much code as we can and we’ll get back to you when it’s done. Wow! Where did that come from? Who ever said that being agile means that we don’t plan and estimate?
True agile teams are constantly planning and replanning. They have to; they have highly visible deadlines to meet every few weeks. What we do know is that planning is difficult and imprecise. We have known that since 1981 when Barry Boehm published the first version of the cone of uncertainty. The cone is a visual representation of what we all know; the more we know about a project the more accurate we can estimate the cost and schedule. This does not mean that we have to write all the requirements first to accurately know everything about the project. Writing detailed requirements will only give us what we think, not what we know.
So, why bother planning at all if the outcome is so uncertain? It is better to be roughly right, than precisely wrong. There are a number of reasons, but probably the most important, especially at the outset of a project is to support the decision making process. Even a rough estimate, say ±75% accurate, can tell us if a project is worth undertaking from an ROI perspective. Be careful though. A fully detailed plan of every activity will produce no more accuracy than, say a Wide Band Delphi exercise, and the investment will be a great deal higher. Not to mention the fact that by the end of the first week of the project the detailed plan will be inaccurate and hence worthless.
“No plan survives contact with the enemy.” Probably the second most important reason to plan is to ensure that everyone is working together as a team. Just like the team of sled dogs, it is critical that everyone is going in the same direction at the same speed. But here again, the long range plan offers little value over a simple list of tasks to be accomplished in, say, the next two or three weeks. By focusing on the near term goals, the team will pull together to meet a published milestone.
Producing an estimate to develop a specific unit of functionality in a short time period can usually be accomplished with great accuracy, typically ±10%. Well within the ability of the team to catch up with a little overtime. The more detailed task and task owner list can be produced in a relatively short time and displayed on a wall for all to see. As tasks are completed they are checked off and progress is highly visible to all. A detailed plan of the tasks the team is currently working on is extremely valuable.
Lastly, planning is essential to gain stakeholder trust. Delivering a promised feature to a customer on a specified date demonstrates the capability of the team, and increases the confidence that the project will be completed on schedule. Conventional planning, however, tends to focus on activities rather than features. Customers are rarely interested in the completion of activities; they want to see demonstrable results. Establishing an iteration goal of "Make Reservation" is not only demonstrable, it also produces something of value to the customer.
A simple long range plan to complete the entire project would therefore look like a series of demonstrable results; a list of product features prioritized by the customer and delivered on a regular schedule. Some judgment by the team would ensure that the effort required for each demonstration was roughly the same, and that there is some accounting for holidays and vacations. Conclusion Agile teams do estimate and plan their projects. In fact, they do it far more diligently than conventional teams, and the results are far more useful.
Software estimation is imprecise, and no matter how much time and effort is spent, it will not become any better. Accept the imprecision and adapt the process to make best use of the data that is available. For more information please read Agile Estimating and Planning by Mike Cohn.
These pages contain various thoughts and ramblings that travel through my brain cells from time to time. Most are the result of a conversation with a client, a problem with a project or just something that occurred to me while I had nothing better to do.
The content is free for you to do as you wish. If you publish excerpts please reference me and this web site. You never know, I may get more clients that way.
If you disagree with anything I have said, please contact me. If you don't like it, then consider what you paid to read it.