« What am I? A Salad?| Main | Great Presidents That Suck »

CrossFire Charts: Measuring Agile in Matrixed Environments

| | Comments (0)
A CrossFire Chart which shows team performance against budget
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.

From top-left to bottom right is a red line that represents budgeted hours remaining in the sprint. It's mostly a straight-line, since most of the time in matrixed environments you have the same number of team members a certain percentage of the time each day. (A matrixed environment means that instead of working 100% on one project, you work on four projects 25% of the time each. Yes, it's a dumb idea, but that's a story for a different day)

From lower left to upper right is a blue line that represents ideal budgeted hours used. This is just the inverse of the red line. It represents what your budgeted burn would be if you burned hours at the rate you are predicting.

Both of these lines together create a big "X" -- hence the name "Cross-Fire" for the graph.

Starting in the left in the middle we have a purple line that represents the traditional burn-down for the project. It is the estimated remaining hours as estimated each day by the team. If it goes up, that means that the total estimated remaining hours increased -- things look a lot more complicated than they did before. If it goes down, it means the team feels like it is closer to the goal.

The light-blue line represents ideal burn down. Ideally, you'd work an hour and your estimated time remaining would decrease by an hour -- if you were able to make exact estimates of each task. But that never happens. In the real world, your estimate of how much time you have varies quite a bit over the iteration. It's good to compare ideal burn down with actual burn down. Read some agile books on how to use this.

Finally, moving from lower-left to upper-right, the green line represents the accumulation of the actual amount of hours billed to the project each day. Once again, ideally the green line and the blue line would be the same -- you would charge the number of hours you were matrixed to the team each day. But in the real world, you end up working more hours on another project one day, and then more on this project today.

If the purple line crosses the red line, which it does about half-way through this graph, you're estimating more hours is left on the project than you have budgeted. That's a flag for a discussion. Sometimes you can make it up, sometimes you can't.

Likewise if the green line goes above the blue line, you're burning hours faster than you have budgeted -- you're going to run out of money. That's also a flag.

The graph also has a series of "X"s, each of which tell an interesting story.

Where the green line crosses the purple line you've actually spent about as much time as you estimate you have left in the iteration -- you're half-way there. The farther this "X" is from the actual center of the graph, the further out-of-whack your burn is.

I'll leave it as an exercise to the reader to find the meaning in the other Xs in the graph. There's a lot here -- perhaps enough for a book chapter one day.

One of the interesting things this team found was that there was this "wedge" that existed in each of their iteration CrossFire graphs. The wedge is formed by the green line and the purple line. (you can just open the image in a separate window if you'd like to see the graph larger)

The team was on a 3-week sprint cycle, and for the first week or more, the actual burned hours (green line) would increase like clockwork while the estimated remaining hours (purple line) didn't do much. That means that people were spending time charging to the project, but their estimates of the time remaining to finish their work didn't change.

You don't have to have the estimated work remaining decrease each day -- that would be nice, but in the real world sometimes things look a lot more complex today than they did yesterday. What you can't have happen is no activity at all. If, over several iterations, you see people billing and the estimated time remaining unchanged people are billing time to the project and not actually working on any of the stories.

In this case, the Scrum Master made a case to the team and the PM that the iteration length should be changed from 3 weeks to 2 weeks. Nobody was doing much work in the first week anyway. The team, however, didn't agree! They felt that by going to 2 week sprints it would be tougher for them to work. I'll leave it to the reader to draw their own conclusions about the team.

Many times in matrixed environments people get into a pattern of putting off work until the last possible moment. If you have 4 projects you are working on, usually one of them is "on fire" at any one time -- they are running hard to meet an approaching deadline. You can use this as a way to schedule your workload. Simply wait until the last possible minute and then the project that is on fire "trumps" all of the other projects. That way, you're always working on important, critical stuff that's on a tight deadline. You also have a good excuse for not going to boring meetings and such on other projects -- hey, you're needed somewhere else.

So when teams switch to agile, they want 5 or 6 week sprints. The longer the better. Why? Because it fits into the old matrixed way of working. What Project Managers are seeing, however, is that in the first 30-60% of the sprint people are actually doing very little work on a project -- even though they are billing like clockwork!

The CrossFire graph helps teams determine where this waste is occuring, among other things.

Have you used a graph like this on any of your projects? If so, I'd love to hear about it.

Leave a comment

Comment Policy: I really, really, really enjoy comments, but if all you have to offer is general platitudes like how happy you are to have found my site and what a wonderful place it is, I will delete your comment and report your comment as spam. Please try to either tell me I am wrong, sympathize with my point, expand on what I'm saying, or offer your own experiences or opinions. If you just want a link your best bet is to just ask for one. Probably won't work, but at least be honest about it. No name-calling and please keep the profanity as low as possible. If your grandma can't read it or you wouldn't say it in person, don't write it here. Thanks.

About this Entry

This page contains a single entry by DanielBMarkham published on April 1, 2009 1:42 PM.

What am I? A Salad? was the previous entry in this blog.

Great Presidents That Suck is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Share Bookmark this on Delicious

Information you might find handy
(other sites I have worked on)

Recently I created a list of books that hackers recommend to each other -- what are the books super hackers use to help guide them form their own startups and make millions? hn-books might be a site you'd like to check out.
On the low-end of the spectrum, I realized that a lot of people have problems logging into Facebook, of all things. So I created a micro-site to help folks learn how to log-in correctly, and to share various funny pictures and such that folks might like to share with their friends. It's called (appropriately enough) facebook login help