Posts Tagged ‘Agile Proficiency’
Why Spend a Whole Morning on Technical Debt?
In a little over a month Jim Highsmith and I will deliver our joint seminar on technical debt in the Cutter Summit. Here are eight characteristics of the technical debt metric that make it clear why you should spend 3.5 precious hours on the topic:
- The technical debt metric shifts the emphasis in software development from proficiency in the software process to the output of the process.
- It changes the playing fields from qualitative assessment to quantitative measurement of the quality of the software.
- It is an effective antidote to the relentless function/feature pressure.
- It can be used with any software method, not “just” Agile.
- It is applicable to any amount of code.
- It can be applied at any point in time in the software life-cycle.
- These six characteristics of the technical debt metric enable effective governance of the software process.
- The above characteristics of the technical debt metric enable effective governance of the software product portfolio.
The eight characteristics in the aggregate amount to technical debt metric as a ‘universal source of truth.’ It is a meaningful metric at any level of your organization and for any department in it. Moreover, it is applicable to any business process that is not yet taking software quality into account.
Jim and I look forward to meeting you at the summit and interacting with you in the technical debt seminar!
Use the Agile Triangle Instead of the Balanced Scorecard
As the name implies, the Balanced Scorecard strives to strike a balance between various performance measures. When Financial, Customer, Business Processes and Learning and Growth measures are presented together, as in Figure 1 below, the Balanced Scorecard allows managers to view the company from several perspectives at once.
Figure 1 – The Balanced Scorecard (source: Trump University)
Likewise, the Agile Triangle depicted in Figure 2, presents in a single “dashboard” the three dimensions critical to Agile performance measurement – Value, Quality and Constraints. Just as in the Balanced Scorecard, it is easy to see imbalances between the three, to respond to them and to restore balance. For example, the tendency to produce more and more lines of code is held in check through the quality metrics.
Figure 2 – The Agile Triangle (based on Figure 1-3 in Jim Highsmith‘s Agile Project Management: Creating Innovative Products.)
My recommendation to clients who do Agile as a strategic initiative is to drop the Balanced Scorecard and use the Agile Triangle instead. There is precious little, if any, to be gained by using the two in parallel. As a matter of fact, one could easily interfere with the other.
The Learning and Growth dimension of the Balanced Scorecard, which does not explicitly show in the Agile Triangle, is, of course, important. As part of an Agile initiative I would expect Agile proficiency to be closely observed. However, I would not include it explicitly in a system based on the Agile Triangle. Agile proficiency is not and end to itself. If the outputs and outcomes we measure through the Agile Triangle are unsatisfactory over a prolonged period of time, a close examination of the way Agile is practiced is called for.
The Agile Executive 