Results tagged “Metrics”

Ever do the retrospective dance? You know the one, where at the end of the sprint everybody plays all the retrospective games: start-stop-continue, timeline, word-pong, or sprint-painting -- and then nothing in your team actually changes? Maybe somebody takes notes, there's an "action list", you create new stories, or whatever, but the next sprint there you are with the same items all over again?

That's a fun game, right?

Teams do this all the time. They're really good at going through the motions of doing a retrospective -- after all, everybody knows retrospectives are the most important part of agile -- but they suck wind when it comes to actually improving themselves.

Makes you wonder: are these teams really agile?

There are all sorts of tests out there to tell if a team is "really" agile -- the Nokia Test comes to mind as a popular example. Based on my experience, I have one simple rule for whether you're an agile team or not: you have to be constantly improving through the use of an efficient feedback cycle.

If you are constantly improving, you can start with nothing and end up with a hyperperforming team. It might take a while, but it'll happen. If you are not constantly improving, no matter how many of the rituals and behaviors you do, you're never going to amount to anything.

Which gets us back to the retrospective dance.

I teach a lot of project and program managers in my business. And I've been there, done that -- I've ran a lot of projects and programs. One of the things that fascinates me most is the difference between theory and practice.

In theory, you have this value structure from the organization -- what's important to it, what the plans are for next year, what fires need to be put out. In theory you simply define and prioritize these things, create and allocate a strategy, and end up with a list, matrix, GANTT chart, or something similar that gives you the next things to do. In theory, by having a value tree and using SWOT and a bunch of other stuff, like QFT, you end up with the next chunk of work for the next time frame. In theory it's even better than that, because by comparing your structure with your results, you can create metrics that show when you're not doing what you want to do.

In practice I have yet to see this work from top-to-bottom in anything but the minds of the creators. This doesn't mean I consider these things valueless -- far from it. A lightweight, cyclical system of work prioritization, allocation, and measurement is absolutely necessary for large organizations to survive.

But in practice, things get messy quickly.

In practice, you have multiple competing priorities that block one another yet each must be done first. In practice, you don't have enough time to put out the last fire before the next one pops up. In practice, department X wants you to do things one way while department Y requires an exactly opposite way. In practice, you have no support and you're on your own. In practice, the business can't make the decisions required of it in a timely fashion. In practice, Congresspeople ring up any time they like and it's a fire drill until they are made happy. In practice, you have no idea what the market will like and you're lucky to have some idea of how the next week is going to play out.

Practice is much different than theory.

It used to be the answer was simple -- blame the practitioners! And still see this from people from all corners of the development world. I had a TDD proponent tell me last month that the reason developers weren't adopting TDD was that they were lazy. A friend that creates process models for organizations confided that things would be a lot better "if management would just crack down on those knuckleheads"

I'm not saying that everybody is perfect, and sometimes "cracking down" or "bucking up" or whatever is exactly what's called for. Sometimes, of course, it's not. But what I AM saying is that a good set of measurements to take is the perceived problems the teams are having with getting their jobs done. Perhaps by looking at the things that are preventing the teams from getting what they want, you can get what you want too.

It's good for me. It's good for you. It's not the dawning of the Age of Aquarius, and we all don't have to start singing Kumbaya and wearing tie-dyed shirts , but it's at least a few steps forward in having a productive conversation about what to fix.

Sounds great but very nebulous, Daniel. What's it actually look like?

Lately there has been a lot of ink spilled over how to measure technology teams. Small startup teams are reaching the point where they want some kind of metrics, and big-company teams are using so many metrics that they desperately need to cut back to something that makes more sense.

Managers would also like to know what to do once they read metrics. Is more training required? Tougher management? Longer hours? Shorter hours? More people? Less people? We're nerds. We're really good at creating lots of charts, tables, and reports. What we're not so good at is using them for something useful.

I've been living in all of these worlds for a long time, and here are my rules for metrics:

The CrossFire chart allows teams to measure budgeted performance
against traditional agile metrics

Here's a little graph I picked up last week. I don't think anybody else has published this, so I'm calling it a "CrossFire". It was created by a team who had a lot of matrixed team members and wanted to track budgeted performance (the amount of time people reported in the official time-tracking system) with agile performance (iteration burn-down).

Turns out you can find out some very interesting things from these CrossFire graphs.