Archive for April, 2009


When employing an agile methodology it is important to measure those key activities that deliver value and promote the right behavior. An Agile methodology can be measured with key measurement types such as productivity, quality, timeliness and utilization. As long as the measures demonstrate why and how an Agile method can affect the projects success and business value. 

 

Do not fall into traditional metrics that promote the wrong behavior or do not align with the project. For example, lines of code per developer week or per iteration or function points developed. This type of measure could promote code bloat as visibility is shed on generating lots of code or generating a lot of effort. Plus the more effort or lines of code in the product, the more there is to maintain. What is really needed is a measure to determine if the functionality was completed. A measure such as features completed versus features remaining. This measure will help determine how much business value was delivered to the customer, if the feature is not complete then there was no value delivered to the customer. The measures should drive the right behavior.

 

I recently had a conversation with an ex-colleague that now runs a project management organization. We discussed the challenges of measuring an agile methodology such as scrum. This organization just implemented scrum about a year ago. The organization had no baseline to compare against their scrum process. So it was difficult for the organization to determine exactly how much value their scrum process added compared to their old development process. This was a management decision not to spend the time or resources to baseline and normalize their old development process to compare to the new one.  

 

Instead the resources were spent on measuring their new scrum process. The organization measured everything they could. At the end of the day they were left looking at a bunch of numbers. Most of their metrics were still traditional metrics promoting the wrong behavior. They did not focus on what was important. Six months later the organization conducted the same exercise but focusing on what was important. What was important to this particular team was velocity. In scrum that is, the number of story points per sprint. This was important because the owner of the project needs this information to make release related decisions.

 

Measure what’s important and delivers value.