Agile Metrics & Agile Balanced Scorecard
Certainly within the agile circles I am working, there is a growing focus on agile metrics. This for me, is both a blessing and a curse.
The blessing stems from the lessons I've learnt from Six Sigma and Lean about measuring success and being able to demonstrate value. The curse is that invariably metrics becoming a big stick for executive management with little understanding or consideration for the context, environment or mitigation...
Only the number is remembered.
There is an inherent human instinct around numbers. Because they are a quantitative representation, they are often preceived as concrete, and are rapidly communicated.
The next time you state or hear a number in conversation, note how easily it is remembered and communicated.
Numerical values are finite, can be made readily available, easy to put into graphs and presentations... but don’t really tell anyone what’s going on. Numbers are a very small representation of a large amount of work and effort and information.
Lesson 1: Remove the Numbers
We value “Individuals and interactions over processes and tools."
The use of metrics within an agile environment should be seen much as Stories are...
A sign-post to have a conversation.
By removing the numbers on the scale you’ll probably start a conversation, that hopefully you can move to a discussion on trends, retrospective and improvement areas rather than focussing on a number and debating a single instance.
Lesson 2: Create Your Balanced Scorecard Around a Discussion
There are plenty of blogs on the web prescribing agile balanced scorecards, any of which, from what I can see, may be of use.
But before you go and grab a ready-made template... think first about why you're doing this.
The original balanced scorecard
http://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/55/Default.aspx
was about ensuring companies remained sustainable and executive boards maintained a balanced view of their company even when financial pressures would dominate their individual focus.
The original balanced scorecard focussed on 4 areas: the customer; the finances, processes (inc IT) and the people.
It's a simple concept of realising that in order to please customers you need to spend money, but not put yourself out of business pleasing customers.
You need good people, so don't under reward them otherwise you'll lose them.
Hire good people but ensure you have robust processes to help with consistency of service etc...
In other words... ensure you have a balanced business.
An Agile Balanced Scorecard is about ensuring your projects are balanced... And before figuring out which to use, first think about what your project cares about.
Burndown is often considered a key indicator, and with my current project was the only indicator being measured at the enterprise level. But what about technical debt? It's no good burning down huge amounts of product backlog if you are accumulating huge amounts of technical debt.
And if retrospectives and continuous improvement are essential to your project (I hope they are!) then capture a measurement of waste to demonstrate how much improvement is being achieved.
An Example of a Balanced Scorecard
There are a wealth of conversations you may wish to have with executives in order to get them to help you improve the delivery capability of your team. Examples might include: More money for environments to increase velocity; more business involvement to build more usable software; money for automation tools; specialist resources to improve your people.
The first area of my most recent balanced scorecard is about discussing the balance between rate of burndown and levels of quality and to know that the team is incrementally improving its velocity. So the scorecard includes burndowns and technical debt indicators.
The next area of my scorecard would be a discussion point for activities related to continuous improvement. So its important to ensure that the team is learning to improve and that retrospectives taking place, actions are being identified, and impediments are being removed.
Finally, I want to know how efficiently we’re doing all of this and measure our progress and this area I've called "Lean". I want to understand the trends for cycle time to market - from adding an item to backlog to delivery into production how long does it take.
I also want to know how much waste exists in the process and the type of waste so that I can initiate conversations for change in other areas of the business, which may increase my speed to market.
So my own Balanced Scorecard would consist of a dashboard of 4 areas:
1. Business Value Creation – product burndown
2. Technical Debt –non-adherence to definition of done, and code quality
3. Continuous Improvement – retrospectives, action plans, impediments raised and removed
4. Lean – Cycle time, types and amount of waste
Summary
The Agile Balanced Scorecard should be a "discussion sign-post".
With no numbers stated in them the discussion is about trends and progress towards the goals of the project or enterprise.
If you are adopting metrics or scorecards, think long and hard about who needs to see the metrics and what for...
Do not create them as reports for emailing upwards, create them around a meeting to discuss what needs to be done next.
The blessing stems from the lessons I've learnt from Six Sigma and Lean about measuring success and being able to demonstrate value. The curse is that invariably metrics becoming a big stick for executive management with little understanding or consideration for the context, environment or mitigation...
Only the number is remembered.
There is an inherent human instinct around numbers. Because they are a quantitative representation, they are often preceived as concrete, and are rapidly communicated.
The next time you state or hear a number in conversation, note how easily it is remembered and communicated.
Numerical values are finite, can be made readily available, easy to put into graphs and presentations... but don’t really tell anyone what’s going on. Numbers are a very small representation of a large amount of work and effort and information.
Lesson 1: Remove the Numbers
We value “Individuals and interactions over processes and tools."
The use of metrics within an agile environment should be seen much as Stories are...
A sign-post to have a conversation.
By removing the numbers on the scale you’ll probably start a conversation, that hopefully you can move to a discussion on trends, retrospective and improvement areas rather than focussing on a number and debating a single instance.
Lesson 2: Create Your Balanced Scorecard Around a Discussion
There are plenty of blogs on the web prescribing agile balanced scorecards, any of which, from what I can see, may be of use.
But before you go and grab a ready-made template... think first about why you're doing this.
The original balanced scorecard
http://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/55/Default.aspx
was about ensuring companies remained sustainable and executive boards maintained a balanced view of their company even when financial pressures would dominate their individual focus.
The original balanced scorecard focussed on 4 areas: the customer; the finances, processes (inc IT) and the people.
It's a simple concept of realising that in order to please customers you need to spend money, but not put yourself out of business pleasing customers.
You need good people, so don't under reward them otherwise you'll lose them.
Hire good people but ensure you have robust processes to help with consistency of service etc...
In other words... ensure you have a balanced business.
An Agile Balanced Scorecard is about ensuring your projects are balanced... And before figuring out which to use, first think about what your project cares about.
Burndown is often considered a key indicator, and with my current project was the only indicator being measured at the enterprise level. But what about technical debt? It's no good burning down huge amounts of product backlog if you are accumulating huge amounts of technical debt.
And if retrospectives and continuous improvement are essential to your project (I hope they are!) then capture a measurement of waste to demonstrate how much improvement is being achieved.
An Example of a Balanced Scorecard
There are a wealth of conversations you may wish to have with executives in order to get them to help you improve the delivery capability of your team. Examples might include: More money for environments to increase velocity; more business involvement to build more usable software; money for automation tools; specialist resources to improve your people.
The first area of my most recent balanced scorecard is about discussing the balance between rate of burndown and levels of quality and to know that the team is incrementally improving its velocity. So the scorecard includes burndowns and technical debt indicators.
The next area of my scorecard would be a discussion point for activities related to continuous improvement. So its important to ensure that the team is learning to improve and that retrospectives taking place, actions are being identified, and impediments are being removed.
Finally, I want to know how efficiently we’re doing all of this and measure our progress and this area I've called "Lean". I want to understand the trends for cycle time to market - from adding an item to backlog to delivery into production how long does it take.
I also want to know how much waste exists in the process and the type of waste so that I can initiate conversations for change in other areas of the business, which may increase my speed to market.
So my own Balanced Scorecard would consist of a dashboard of 4 areas:
1. Business Value Creation – product burndown
2. Technical Debt –non-adherence to definition of done, and code quality
3. Continuous Improvement – retrospectives, action plans, impediments raised and removed
4. Lean – Cycle time, types and amount of waste
Summary
The Agile Balanced Scorecard should be a "discussion sign-post".
With no numbers stated in them the discussion is about trends and progress towards the goals of the project or enterprise.
If you are adopting metrics or scorecards, think long and hard about who needs to see the metrics and what for...
Do not create them as reports for emailing upwards, create them around a meeting to discuss what needs to be done next.
Comments
And numbers are the abstract representation of any given situation.
Main focus is to change those red number for a greener ones through the Human Resource, but ¿How?, the answer to this question involves everybody inside an organization.
This is where "goals" or "team goals" gain importance in order to deploy Strategies to "Control" some part of the process to make them come up with green numbers.
I thinks the score card is something like an "Equalizer" that shows if the Business it's in tune, too loud or out of sync with the vision.
And it's every manager job to tune it correctly through the people with the right methods.
Well, that's how is see all this Scorecard thing.
Great info and great insight, by the way, stated so clearly that me, who I'm not an engineer could get it.