If you are new to Agile and would like to know the metrics to use in your projects, here are some tips
1. Don't try to invent new metrics as soon as you move to Agile, instead use some of the existing CMM and other matrices and use it within an iteration.
For ex: In typical non-Agile companies the metrics commonly used include,
- Total number of defects,
- new change requests,
- resolved defects,
- total major,minor defects, etc.
- Total number of new defects found in each iteration
- New features added to backlog in each iteration
- New tasks discovered in each iteration
- Number of resolved defects in iteration, etc
3. It is also important to display the up to date metrics in a visible area in an Agile development environment.
4. There should be some action associated with the numbers captured as part of metrics,whether it is good or bad. If the numbers are as per the target/plan, then one should create actions to increase the bar. If the numbers are not good, then one should take actions to reach the bar.
5. Metrics can drive the behavior of the team. It is very important to choose the right metrics.
Recently I heard from some one that a management of a start up company imposed a metric to measure the productivity of individuals based on the number of times a developer checks the code into the repository. This metric obviously resulted the behavioral change in developers, as they were more worried about how frequently they check the code in to meet the target rather than any other deliverable.
Here are couple of good websites with information on Metrics in Agile environment
5 comments:
I don't think a behavioural change is avoidable when moving to an Agile methodology. In essence you actually are initiating an intentional behavioural change.
Managing the team members during such a migration from waterfall to Agile would is an integral part of such a change.
When you make the change to the project style, the team members suddenly have to work in a different fashion, such as iterations. This will definitely affect people meeting deliverables and in general how the proceed with their tasks.
Regards,
David
http://www.jacksguides.com
The choice of metric should be determined by what you are trying to measure: metrics should not be collected for their own sake. The top three reasons (according to a forester report commissioned by Borland) for collecting metrics are:
- Process improvement
- Communicating with the business
- Time/scope trade-offs
In some some of the more popular Agile practices the need to collect these sorts of metrics can decrease and be replaced with people. For example instead of monitoring defects I've worked in an agile environment where the customer would sit down and write acceptance tests for the system before the features were coded. This is a system where inputs and outputs could be described in a tabular fashion using Fit or similar. Regression testing then is automatic and the introduction of defects is immediately obvious as builds (whether continuous or smoke-test) would fail.
Metrics for reasons of process improvement can mainly be concentrated on code level: code coverage, number of tests, OO type metrics, complexity metrics. These can now be built into some development environments to warn the developer when the code is not good. This instant feedback fits well with the agile culture.
Monitoring the success of the project can largely be done through burndown and as you say managing the backlog. Have you come accross moutain-goats alternative view of the burndown chart? http://www.mountaingoatsoftware.com/alt-releaseburndown
This rolls some of your agile metrics into a single chart.
The best way to introduce productivity is to move to a pair-programming environment. I worked in an environment where there was a pairing area where you sat together and coded all day. I know some companies that adopt this in the city that don't give the developers an email address or anything like that as they will be coding all day (in pairs).
My cousin recommended this blog and she was totally right keep up the fantastic work!
Agile Software Development
NICE POST
great article.
Post a Comment