What to measure when measuring the agility of a team?

Door Patrick Verheij

So far, many articles have been written about the topic of measuring for agility. And still I believe we need a few more of them. So I’ll give it a shot too.\r\n\r\nFor me, the agility of a team is mostly about these four things:\r\n

    \r\n

  1. Delivering something that actually works frequently.
  2. \r\n

  3. Delivering something that someone needs (or craves) and actually brings value to that person.
  4. \r\n

  5. Ensuring a healthy and sustainable environment while doing the two things above.
  6. \r\n

  7. Improving the way you do the three things above all the time.
  8. \r\n

\r\nSo…these are the things to measure then, right?\r\n\r\nRight. But only if we use the measurement to actually improve these things. We don’t measure for data, we measure for improvement, don’t we?\r\n\r\nIn terms of measuring “something that actually works frequently”, we could just look at the tangible output the team produces every now and then. If we strictly follow the Manifesto for Agile Software Development, that would be “working software”. And by “working” we actually mean “usable in one way or the other”.\r\n\r\nIf you are not in software development business and still like to be agile, then we could look at the product or service that you deliver and see if it works. Frequently of course.\r\n\r\nThen we need to measure the actual value of the software, product or service that is delivered. We could do that by giving it to someone who asks for it or (if it’s an innovation) some lucky peasant we believe could benefit from it. And then we simply ask for feedback while we watch the person’s face to see if a smile emerges (I credit Niels Malotaux for that one).\r\n\r\nNow we know that ruthless production can be damaging to the environment in the long run. We know many organizations who are now crippled by years of pragmatic software development. Technical debt all over the place! So we also need to measure if any damage is being done to the environment.\r\n\r\nAnd that’s the difficult one to measure.\r\n\r\nNot because it’s hard (even though it is), but mostly because…the organization is already damaged by years and years of management that could not keep the organizational “system” in shape properly.  The organization the trying-to-be-agile team works in is chock-full of inefficiencies in structure and processes. And all that it is slowing us down big time. Especially if we are in an organization that isn’t very much agile minded and where managers keep on managing like they always did.\r\n\r\nBut…we need to do it nonetheless. Teams do it by surfacing, acknowledging, analyzing and then raising impediments. We then measure if these impediments are solved and how many other impediments they either solve or newly create.\r\n\r\nIt’s a tough one, really. It takes plenty of time and heaps of patience. Do we have what it takes to plough through?\r\n\r\nWe must, because otherwise we will never be truly agile as a company nor as a team. And that’s why we need to measure the actual improvements we make to the way we do our work. First of all we measure whether we try anything new at all. We merely count the number of experiments we run on the process while doing them. We then measure if these experiments lead to improvements.\r\n\r\nOf course any seasoned agilist knows that measuring impediments and measuring improvement experiments go hand in hand. Experiments can be the results of teams dealing with impediments. Experiment can also be the result of teams that are seeking to improve their way of working even more. Sometimes the “impediment” doesn’t have to be that apparent or even negative.\r\n\r\nSo in the end, we merely measure two things:\r\n

    \r\n

  1. The team’s working output and the value it brings to specific people.
  2. \r\n

  3. Improvements and disappearing impediments.
  4. \r\n

\r\nWe can measure more if we want. We could measure MTTR (Mean Time To Resolve) our impediments if we need that. Possibly because solving impediments is not yet trivial in the organization we work for. Or we could measure velocity if we are a team that wants to become better at planning and more predictable. But that’s secondary to measuring value. You knew that of course ;-)\r\n\r\nCustomer happiness is a metric we use when measuring value. We could also measure the team’s happiness. But that’s a dangerous one because…how happy is a team that is ploughing through a field of impediment mud in an ignorant organization? Team happiness doesn’t say a lot. We should instead look at the slope of increased team happiness of course: we are doing well if a teams gains more fun creating value and solving impediments.\r\n\r\nWe don’t measure incidents (bugs), MTTR incidents, technical debt, and that kind of stuff. We may, temporarily, to solve process deficiencies. We then haul in the Six Sigma Black Belts to improve bits and pieces. But real craftsmen (and women) rather focus on avoiding incidents or solving them before they go live by proper testing. Technical debt is avoided by applying effective QA practices.\r\n\r\nAnd that’s how we measure for a team’s agility.\r\n\r\nOf course I know I may be off on this. A bit or a mile. You probably also have a story on measuring agility. I just hope my story makes some hearts and some teams tick.\r\n\r\nLet me know if it does.

Patrick Verheij

06 59 443 447

Andere posts

Klik hier