How could it be fair to ask an agile project manager and her team to estimate an agile project in traditionally managed organization. Senior management often expects detailed and "accurate" estimates as early as during project initiation because at this point projects are funded and budgets controlled. For the agile project, this estimation exercise could easily turn into estimation paralysis.
When large enterprises experiment with agile process adoption, an agile project manager is often challenged by and compared to projects of existing systems. Often these are mission-critical applications, which have been patched, fixed, and improved over time, leading to a complexity and size of functionality, which could be overwhelming.
If you are in charge of replacing such a system using an agile approach or are in the beginning of new large enterprise-wide project, the bar could sit very high for project managers and the teams. But please remember, hardly any of these existing systems were initially planned and developed with such complexity in mind. They grew often over many years through bug-fixes, enhancement requests, and integration with other neighboring systems. In the same way the existing system evolved over years, so did the schedule and cost estimates.
Just to clarify, let's assume there are no user stories, use cases, features, or any other traditional requirement documents -- just a business case or an initial idea. To be able to attack this dilemma, we need to go to the root-cause of the problem and start asking ourselves "Why are we struggling with these complex estimates?" and be honest about "Why do we feel bad about admitting that it is so difficult?" But let's challenge the question itself "Are early estimates actually difficult?" complex system in an agile fashion if we can't do it with another method either? It's not.
Trust Your Gut
Psychological studies demonstrate that this process might not be as complicated as we think. This could help agile project managers with estimates and other complex decisions. Let's take a look at some examples outside of the IT industry to illustrate the idea of the findings.
Picture yourself buying a new home, which is in itself a very complex decision. We select houses according to our own pre-set parameters, for example price, size, or location. From these parameters we could derive a checklist of very detailed questions to support the final decision. In contrast, how many have had experienced the phenomena that you looked at a house for only a few minutes and you knew that this house would be "it."
You did not know why, but you just knew and all the collected benchmarks were thrown out of the window. Sometimes, the decision even compromises other parameters, for example the sales price. Bas Kast [1], a German psychologist, argues that the brain is only good for simple decisions and people are better off with their intuition for complex issues. Even better, everyone is equipped with such intuition. Kast applied the approach in very complex and often life-changing events such as partner selection, with stunning results. Using simply their intuition over logical decision processes, he realized that people who made impulse buy decisions for products were often happier customers than folks studying the products in-depth prior to the purchase. Good that we make only one percent of all decisions using the brain.
The issue with the complex decision process is that our brain is not very good at putting too many alternatives, options, and dependencies into perspective. The result is that we often trust our gut feeling over the brain, but struggle to explain it. For example, an agile project manager is being asked to develop an initial estimate for a large-scale project to get additional organizational buy-in. That does not mean that the agile project manager should throw out numbers ad hoc.
Even though, Malcolm Gladwell [2] coined the phrase "don't think, blink!" where he believes that spontaneity could lead to better decisions, others believe that even intuition needs some time to put a very complex situation into perspective, a situation we commonly describe as "I will need to sleep on it." This allows the decision maker to let the information sink in and get more comfortable with her own decision.
Experience Affects Intuition
The intuition comes from experience and puts the past into the context. In agile project management, we learn incrementally— sometimes the hard way— during a sprint retrospective. But it is exactly in these retrospectives where this context for future decisions is established. Instead of learning project by project, agile project managers learn increment by increment.
With this approach, we improve the context of our inner voice steadily and increase the quality of the estimates quicker than with traditional approaches. Sources of that context could be that too few resources were allocated to an iteration, easy features turned out to be more complicated than expected, or, of course, the price to develop a feature was beyond the initial estimate.
Yes, these were issues during the past iteration and might have caused tremendous trouble, but because of them we established more context, essential for future decisions. This is particularly important for agile newbie's. Think about it: requesting a price tag for a project, or even just a single iteration, from an inexperienced project manager seems silly, doesn't it? Even if the newbie had a complete breakdown of tasks laid out as a "master plan," someone's inner voice would be still heard during the estimation exercises.
We call these methods Expert or Wide-Band-Delphi [3], but they might be representations of a team member's inner voice. So even if we do not have these detailed plans, we could apply the same techniques.
So is our industry aiming for these scientific approaches only because we are part of broader engineering disciplines with a strong background in math and physics? What would be the most likely first question from senior management if you presented an estimate of five to seven million dollars for a new project?
"How did you come up with this number?" Answering "My intuition tells me that" might not be sufficient for your audience. These psychological studies indicate that we see feelings and emotions as dumb and therefore try to use a scientific approach to rationalize and prove our intuition. But, in reality, they seem to lead to better decisions.
From my own experience, I recently had a general contractor look at a job at my house. He entered the house and even without looking at some of the rooms, he threw out a price that I thought was very quick. Later, after the project was completed, I asked him how he came up with his estimate. He simply answered, "based on my experience, year built, and size of the house."
After I noted that he hadn't looked at all the details and even some of the rooms, he added "Well, there is always something you don't know until you open the walls." After project completion, it turned out he was dead-on. It was a successful project for both of us. I am sure, however, that his personal retrospective for my project will influence the next homeowner's estimate one way or the other.
Where Do We Go From Here?
I am aware of organizational constraints and the requests for "accurate" estimates. That approach seems to be grandfathered into many organizations. We can only challenge it, one step at a time. But perhaps next time you are being asked to estimate a project, listen first to your intuition and capture that estimate. Keep the "guesstimate" at least for your own records and compare the it to the actual outcome.
Consider guess-timating a range for example low, high, and most likely and try to narrow it as much as you feel comfortable. A range is a clear signal to everybody that it is really an estimate. Try a slowed-down version of the Wide-Band-Delphi method with every participant guesstimating on the project-level— slowed-down in the sense that team members can take more time to estimate with their intuition and perhaps even sleep over it. Explain that the exercise should not be rationalized and that no participant will be asked to justify his results. No other estimation method other than the gut-feeling is required. Then you can either compare the result with yours, or derive median values.
Once your project is completed, compare the actual results with the original guesstimate and document the differences. If you can demonstrate after, say, five projects that your method is getting better and better over time, you will have an easier time backing-up future estimates. But most important in these early project stages, you will get to an estimate quickly and move on.
[1] Bas Kast "Wie der Bauch beim Denken hilft - Die Kraft der Intuition"
[2] Malcolm Gladwell "Blink - The power of thinking without thinking"
[3] Wikipedia (09/27/07) - http://en.wikipedia.org/wiki/Wideband_delphi
About the Author
Jochen (Joe) Krebs, http://www.jochenkrebs.com, is a active member in the agile alliance and the agile project leadership network where he spearheads the local chapter in NYC. As a certified Scrum Master and co-author of the Rational Unified Process - Reference and Certification Guide, he publishes articles with a focus on project management and requirements engineering. In his current role, Joe is responsible for successful adoption of agile development practices in a large investment bank in New York City.
