Better Guesstimating

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. So how could it be fair to ask an agile project manager and her team to estimate a Agile project managers face another challenge in traditionally managed organizations.  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.  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.

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. So how could it be fair to ask an agile project manager and her team to estimate a Agile project managers face another challenge in traditionally managed organizations.  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.  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.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment