As the VP of Business Development and Marketing for Net Objectives, I get calls nearly every day from hard-working people that are having significant problems with their agile process. Many of them have just started a new project using an agile process, but there are others that have been agile for a while and are finally admitting that they are having issues. I am a good listener, so I always ask them to explain to me what they see as the problems they are having. For a while it amazed me how consistent the tales of woe could be, but one day it hit me, and it all made sense after that! Almost all of the struggles our potential clients were having were being caused by a very small number of root causes. Today I wanted to write about just one of them.

The one I want to write about is agile estimation and analysis. With Big Up-Front Design (BUFD) the analysis and estimation has to be done when there is very little knowledge about the way things will eventually turn out. In fact, we are forced to create estimates at the point in the project when we have the least knowledge, and we are estimating things that are generally very large. That combination can be deadly. Think about it - we can almost always estimate to a high degree of accuracy the things that are very small. Once things get large, so does our error. Compound that with lack of knowledge and our error increases even more. Why does anyone think this is a good method?

Net Objectives has put together a course called Agile Estimation and Analysis for Developers and Product Owners which addresses the issues teams WILL have when they switch to using an agile process of any sort. Estimation and analysis in an agile environment is almost completely different when compared to the BUFD method. The things being estimated need to be broken down more fully (ie, analyzed differently). They need to end up with stories that can fit into an iteration which is generally measured as a few weeks, rather than the months used in larger projects. And they need to know how to determine when to re-size or re-analyze a story (as described in this blog post by Alan Shalloway). In other words, an agile team member needs to forget what they know, and learn completely new techniques and models when they go to an agile process from BUFD.

Maybe I'm the last one to get this, but when I recognized this root cause, I could see all kinds of problems that were related to it. In fact, many of the problems I heard potential customers talk about were things that would seem to have a completely different root cause! When someone tells me the team has trouble meeting the commitments they make for an iteration, then it is obvious that this particular root cause is at least part of the problem. However, there are times when it is not so obvious. For example, when I hear someone say "we almost always have stories that take more than one iteration" or "we just don't feel like we are getting enough done in each iteration even though we're meeting our commitments" or "our velocity is not consistent from iteration to iteration" I always go straight to estimation and analysis as the root cause. There are plenty of other things I hear that also go to this root cause, but I won't bore you with a logn list. Maybe some of you have things that you recognized had estimation and analysis as a root cause. If you do, please leave a comment so we can all see other areas affected.

If you are interested in learning more about our courses that can help agile teams, please go to our training web page and click on lean, agile, or scrum (or other areas that might interest you). Our resources page also has a lot of great material, and even more material if you register first.

Technorati Tags: Lean-Agile

tag with del.icio.us