Agile CMMI: KPIs for Agile Teams

The following example shows the net change in the volume of the different sort of logic artifacts undergoing change in our May 2007 sprint. In this case, we have a steady increase over time in the java, xml, and other sorts of things that make up the project:

When we begin to visualize volume changes, we become better tuned to process capabilities. How many developers does it take to review 12,000 net new LOC? Given prior defect density and the "law of large numbers", what can we expect in terms of new bugs found and not found in this new code? How many developers and which skills will it take to maintain institutional memory of this code for future maintenance efforts?

3.3 - Quality of Work Product
The essence of development governance is to assess the compliance of the work product against engineering standards. If you don't have standards, you have no basis for a quality program. If you have standards and no compliance assessment, you can't know where you stand with your quality program. The work product quality KPI opens the window into the process so that you can achieve real development governance.

Most teams have standards, and they usually include coding guidelines, compatibility with language vendor guidelines and industry standards, and keeping a handle on code complexity. Here's the trend in the injection of complexity in our May 2007 sprint:

The graph shows the average complexity and range bars (min and max) for Java code changed each week. The team standard was to contain complexity to 10 or lower; we can see that the team complied with that standard, never exceeding 6. In other sprints, an uptick in complexity prompted peer review, enhanced unit testing to ensure coverage for the new execution paths, and even rework to re-express the logic in clearer, more maintainable terms.

 4.0 - Tools and Automation
Change management tools can offer a platform for deriving the KPIs described above. Your ability to visualize capabilities is predicated on tool capabilities. The examples given here are all based on IBM Rational ClearCase UCM. Other examples of change management well suited both for Agile teams and deriving KPIs include AccuRev, Perforce, Subversion, and Rational Team Concert / Jazz.

Automation helps you get traction with KPIs by delivering timely reports without adding administrative burden to the team. Vendors like SourceIQ offer solutions that integrate with your existing change management infrastructure to automate the derivation and syndication of KPIs.

As you seek to apply KPIs, consider your process capabilities, engineering standards, and tooling together. You'll find a treasure trove of KPIs ready to be explored, baselined and shared. This empowers teams to achieve superior results and demonstrable compliance, even in a virtual bullpen. Transparency helps management and customers to understand the value of Agile in meeting their requirements. 

[i] "Agile Development: Lessons Learned from the First Scrum", Dr. Jeff Sutherland

[ii] "Lean Development Governance Whitepaper", Scott Ambler and Per Kroll

[iii] All examples given are based on SourceIQ Enterprise Server analysis of a production IBM Rational ClearCase UCM environment. Where appropriate, names have been altered to protect privacy.