Doing Team Metrics Right

Posted by in Featured, Reference, Tools |

It seems common knowledge that measuring teams and presenting data is an Agile dysfunction. I disagree. But can see and have participated in abusive metric relationships in the past. I think we need to discuss better ways of achieving an evidence based Agile approach; without those participating feeling (or being) abused.

Here are my top five list of traits that make metric dashboards useful –

  1. Measure competing things – its relatively easy to game a single metric, so its important to measure the impact of moving one metric by showing the others. Help teams target moving one metric and observe any negative impacts on others.
  2. Make informed and smart trades – trading something the team is better than other teams in similar circumstance for something they desire to improve. Help teams identify what metric category they could trade (be less good) to raise another metric (become better).
  3. Trends not numbers are important – observing unintended drifting over time of metric averages. Its about understanding something has changed, not how good or bad. Help teams react earlier to often slow moving regression in a metric or two. Less effort in correction the earlier it is detected.
  4. Look for global or local trends – Comparing trends across teams is key to spotting system level opportunities (every team is impacted) versus single team opportunities. Help teams target improving things they can do without fighting a system level factors they are unlikely to solve.
  5. No team will be good at everything – If a team is adversely trending on one metric, point out they are above average on another. Pick competing metrics so that no team will be great or terrible at all of them. There will always be a mix.

This list borrows heavily from the work of Larry Maccherone who correctly observed that a balanced blend of metric types gives the most information for identifying trends and improvement opportunities. His advice is to measure at least one thing from four broad areas –

  1. How much
  2. How well
  3. How responsive
  4. How repeatable or reliably

An implementation of this was recently made available in spreadsheet form. Driven from work item Start date, Completed date and Type, the spreadsheet builds a dashboard page in Excel. The choice of the four metrics was somewhat from experience, and there are plenty of alternative that might fit your context better. The advice stands though, pick a metric from the four areas.

To help roll out the dashboard, we have created a single page cheat-sheet to educate the teams on what each metric means and what to expect if that metric is overdriven. The goal is to stable in all four, not excessively good at any one.

Download the spreadsheet by clicking here

Download the cheatsheet documentation here

As always, love feedback and stories as to how this spreadsheet has worked in the real world. We want to improve it over time.

Read More

Is Agile Anti-Science? Not yet, but trending that way.

Posted by in Featured |

There are many engagements where I work alongside very smart people. From leading coaches and trainers in the Agile world, to smart teams committed to delivering quality products that solve customer problems. In the trenches there is a constant feel of improvement and curiosity for doing better tomorrow what ailed us today. And a constant enquiring mind as to “why?”

I don’t see the same vigor in Agile conferences. I see a narrowing of ideas presented. I see risk adverse programs that cater to a simplistic mass message. 

This is a similar predicament that technical journals in other fields have faced for years. A huge bias exists for publishing experiment results where an outcome was positive and expected, with rare publication of studies that failed to show expected results (ironically, often more or at least equal learning in failures). The pressure to cater for readers need to see articles from luminary known personalities versus taking a risk on currently unknown often polarizes work in the “old way.” Not to mention the commercial pressure of advertising and sponsorship concerns that shouldn’t influence editorial, but survival to offer anything is dependent on making sure they get value for money and continue support.

The dumbing down process starts silently. Commercial frameworks stifle innovation and polarize messages. Add certification, and you accelerate that stifling of new ideas freely emerging. This is a sure fire way to extinction.

To avoid this plague, here are a few suggestions for balancing a conference program –

  1. Blind submission process – hard to do in reality, but most academic programs are build absent of the authors name or affiliation. The topic is discussed at length. Not, we can’t knock them back.
  2. Conferences should publish in advance the allocation of subjects they want covered. This is crudely done at some conferences by having tracks, but even within a track they should say the percentage of topic allocation they want. E.g. 20% ideas for managing dependencies, 20% ideas for creating safety in teams.
  3. The abstract should be brief during the submission process and then upon acceptance constructed into what the track chair and program desires in collaboration with the speaker (just like an editor in journals and book publishers commonly do)
  4. For abstracts that are important but from a first time speaker, pair the science expert with a luminary speaker and have them co-present or work together. TED talks have shown that given coaching ANYONE PASSIONATE about a topic can make a compelling talk.
  5. At the start of the conference, each track chair should present 10 minutes about the program they have assembled, and help the attendees understand why they should attend each talk. Often, the abstracts are too abstract for people to bother reading, and important sessions don’t get attended because people don’t know what they are about. A good topic title wins out over good content every time.

These are just a few ideas. I want to keep the Agile community vibrant and on a quest for learning. I think Agile conferences are a leading indicator of how new ideas might be lost, and want to avoid that. Not every conference is bad, but some are.




Read More