Upper management tracking
To the best of my abilities I'm attempting to fulfill the role of Agile Coach in an organisation with ~40 dev teams. With ~20 teams cut over to Agile, upper management are starting to realize that the metrics they had for the Waterfall guys, don't exist for the agile teams.
So they are trying to make all the teams commonalize on a single tracking tool (JIRA), so they can mine the data, and compare teams (!?), etc.
There are at least three problems with this:
- Some teams use Scrumwise. They trialled JIRA and disliked it. I think its _very_ unagile to force anyone to use particular tools.
- By implication management will be requiring the teams to have a common workflow, to make the data comparable.
- I'm not even sure what questions someone mining the data might want to answer.
Before I get myself fired by throwing my toys out of the pram, is this a remotely reasonable request? Does anyone have experience with this kind of problem, particularly those where there is a positive to be had.
The key measure they ought to care about is the frequent release of tested, integrated, and valuable increments. The evidence for this should always be immediately transparent and empirically proven, and should not require data mining.
This implies that no team should end a Sprint with a deficit for release, such as dependencies or undone work. Any technical debt which may have incurred thus far should be quantified for each product and shown not to be accruing.
In my opinion, when managers start comparing metrics of one team against another, nothing valuable will come of this, and managers will not learn much. Teams will start 'gaming' the metrics if they know they are being compared, it is just human nature. Naturally they will zoom in on velocity or just one metric. But just because a team's velocity goes up, is that a good sign? Maybe, maybe not. Perhaps code coverage and quality are headed in the wrong direction, because the team cuts corners to make their velocity numbers better. There are a lot of anti-patterns that will emerge when comparing teams.
Try to have a conversation with these leaders to understand what outcomes they expect from the Agile transformation, what they hope will be different 3 month, 6 months, 1 year from now, what are there concerns, etc. Then measure as Ian has suggested oh so well.
All the best!
Try to have a conversation with these leaders to understand what outcomes they expect from the Agile transformation, what they hope will be different 3 month, 6 months, 1 year from now, what are there concerns, etc.
I'll add to that: Try to find out what they hope to gain by mining that data and see if you (or better yet, them) can find better ways of achieving that goal.
When you say in an organisation do you mean you're the Agile Coach for the entire organisation? I've realized we're often hired not to coach an organisation, but to make efficient an IT team.
Suddenly your boss only cares about making his IT department look efficient. He has no interest in the organisation-wide impact of being agile. He thought being agile would make his team of Developers work hard, faster, and have better reports to show for it.