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 , 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