When a development team starts using an agile process one of the first questions asked is: "What is it important for us to know?" I believe there are many agile consultants in the world that take this simple question and start leading teams down the wrong path right from the start. Technical people (like the agile consultants I'm thinking of) tend to jump right to the technical things. They may say it is important to have a good understanding of the various new roles on the team. Or it is important to know how long your iterations will be. Or it is important to know various developer practices to become more productive. Or it is important to know ___ (fill in the blank with your favorite item). My feeling is that all of those things COULD be important, but none of them mean anything if a team does not know it's velocity per iteration!

If a team does not know its velocity, how will that team ever be able to know how much work to put into an iteration? If a team doesn't focus on determining its velocity, it is almost a 100% probability that the team will miss the scope of most iterations - usually be a lot! If that happens, what good has it been to go to an agile development process?

Scrum (as an example) can be used in a CMMI Level 3 environment because it is predictable and repeatable. But that only occurs if velocity is known. Can velocity change over time? Of course it can, and we hope it always increases, but we can't PLAN on it increasing, we have to SEE it increase, understand why, then adapt. We need to make our future plans based on what we know. Many people call this technique using yesterday's weather to predict the future. There are many blurbs on it, but Martin Fowler's description is probably easiest and gives the origin of the term as well. To use this technique, we need to know what "yesterday's weather" was, which means we need to calculate velocity!

Many people struggle with all the things they think they have to track in an agile project. Burn up charts, burn down charts, hours, story points, stories, tasks, etc, etc. To be most effective at managing agile projects, get to the root of it all - how much work can be done in each iteration. Whether you use shirt sizing, story points, planning poker, fibonacci numbers or something else doesn't matter, as long as you know you can get a certain amount of it done during each iteration. When a team can confidently say "We can get X units of work done in each iteration" and really mean it, the Product Champion, stakeholders, customers and everyone else involved with the product can suddenly have confidence that things will be successful. The team has made a commitment and they will be sticking to it - hooray! Now everyone outside of development can do their jobs with some sense of knowledge about what and how much will be delivered over time. Of course there will be changes, but at least everyone has a frame of reference to go from.

One reason to go to an agile process is to reduce risk. A major element of reducing risk can be accomplished by knowing the development velocity. Once that is known (and it may take a few iterations to get it honed), the risk of overcommitment is vastly reduced. No one likes to over-promise and under-deliver, but that is what will happen on a regular basis if a team doesn't know their velocity and modify things based on yesterday's weather.

Technorati Tags: Lean-Agile

tag with del.icio.us