Metrics in Agile development

Metrics seems to be the part and parcel of any software development project. In typical waterfall development projects, different types of pre-defined metrics would be used across various projects even though each project is different. However when a team migrates to Agile methodology it becomes bit complicated. They get confused about the metrics to choose. This is because as such Agile methods are not prescriptive and freedom is given to the team to invent the ones which adds value to project. This instant freedom makes the team to come up with more questions than answers.

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.

Convert them into Agile by using them in iterations. For ex:

• 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

2. Above discussed point could be used as a starting point, however going forward it is critical to identify some of the pain points in the project and create metrics around them. Pain points can be identified by looking at what the customers/stakeholders are unhappy about most of the time.

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

• Appropriate Agile Measurement
• Principles of Agile Metrics
• AgileMetrics.com
  

Article published on Project Perfect

Project perfect team recently published my article on pros and cons of open office space on their blog. You can find the article here

Open plan offices Vs Cubicle culture

Recently I witnessed a good deal of discussion about the "best" way to arrange seats in software companies to improve productivity, reduce cost, etc.

Even though many Agilists can give a blank cheque in support of "open plan offices", we should be careful about implementing them without careful consideration. I have worked both in open plan and in cubicle offices. Each style has its own pros and cons.   

My personal opinion is, seat arrangements should be "context dependent".  One of the contexts I suggest to look at is the "type" of work. If the work involves more communication and interaction, then it is better to arrange that particular team in open space. However if the work involves solo, less communication/interaction work, then cubicle or closed room kind of design is recommended.

The office space could have separate designs within the same company while accommodating people with various work types. The R&D team ,specifically the researchers could be made to sit in cubicles to concentrate on individual researches. However the development team which need to communicate more often can be made to sit in an open space environment. 

If the development team is made to sit in open space plan, then I strongly suggest applying "Caves and Commons" type.  My personal experience is that, in the absence of "commons" people tend to receive and make phone calls all over the place distracting the people around them. 

Even though I have been discussing about the infrastructure setup for Software development teams, it aids my belief that Agile methods should not be implemented in isolation trying to think only from the software process point of view, however the process should be applied by including various parties in a software company, like infrastructure, HR, finance, etc.  The process should be applied end to end.  

Local sub optimization won' t improve productivity !!

Another dimension to this discussion is, many a times we discuss about  improving the "productivity" of the teams through various soft skills training, usage of expensive collaboration tools. However  many companies over look the office space design. If the office space is dimly lit, crowded with ventilation issues, then no matter of what tools, techniques and process we use, it won't make much difference.