Big Visible Charts

People Need to Know

One of the XP values is Communication. There are many ways of communicating within the team, and with people outside the team. We generally prefer conversation for most purposes, but when it comes to trends, history, or sensitive subjects, a good approach can be what we in XP call a Big Visible Chart, or what Alistair Cockburn (Agile Software Development) calls an Information Radiator. A simple chart on the wall can bring important information to the attention of the team, the customer, and everyone else who passes through the area. The chart can provide important information, even politically sensitive information, without getting personalities involved or hurting feelings.

On the Wall

Charts on the wall are many times more effective than charts on a web site or in a fancy slide show. A web site doesn’t push information at us; we have to go look. A slide show always comes with a meeting and a lecture. A wall chart is there when we are, in our face, always visible. Bigger is better. An 8-1/2 by 11 chart doesn’t cut it. You have to walk up to it to see what it’s saying. A chart drawn on a sheet of flip-chart paper, on the other hand, can be seen from across the room. It draws the eye, pulls you over to take a closer look.

Casual is Better

There are some really fun charting facilities in Microsoft Excel^®, or in Visio^®, or any number of excellent programs. You can while away many hours creating very professional charts, even automated charts. Well, consider simpler alternatives. Get a tablet of flip chart paper with a sticky back and a light grid, and try drawing your chart with whiteboard markers. You can update it in seconds every day, and if the chart needs to be a bit different, rip it up and draw a new one. You’ll save time, have more fun, and the charts will be more personal and less mechanical. This article’s samples are all drawn by hand to emphasize that casual is better – and to show you that you can surely do better than I can at drawing useful pictures, so don’t hold back.

What Should We Chart?

Chart what you care about, what you worry about, what you want other people to know. Most every XP practice offers material for charts. Problems, especially recurring ones, are worth charting. And don’t forget to chart good things, like stories implemented, defects repaired. Or bad things, like the number of days since the boss last brought in pizza or donuts.

Here are a few specific charts that I’ve seen used, and a few suggestions for what I’d like to see.

Customer Acceptance Tests

We would like to know how many tests we have, and whether they are all working. Consider a simple chart, showing for each time period (day, week, or iteration) how many customer acceptance tests exist. Color in green the number that are working, and in red the number that are not. The chart below shows what you might see on a project with an orderly progression of more and more tests running:

If the red is slowly squeezing out the top and looks like it will all be gone by the time the product ships, you will get the sense that things are going OK. If the chart shows some other pattern, you might become concerned:

Whoa! Something has gone wrong here! A huge block of tests has suddenly started failing, and it looks like they aren’t being fixed. Some test improvement is happening, but that appears to be tracking test growth. Better ask the team for more detail.

I emphasize ask the team. I’m not suggesting having them draw a more comprehensive or detailed chart, though I do have a different kind of chart to suggest below. I’m suggesting that this simple chart is enough to tell the customer or manager or next-level manager that it is time for a conversation about test results. Based on that conversation, you’ll direct the team’s activities to producing more information – or more likely, to fixing that bug!

Here’s the real power of a chart. It goes along peacefully, minding its own business, tracking events. Then, when a pattern of events looks bad, the chart shows it, and triggers people to come together and solve the problem.

</strong>If there seems to be a pattern of repeated customer acceptance test failures, it can be of value to create a display of the status of each test on each day. Color a test’s daily cell green if the test passes on that day, and red if it fails. Look for patterns in the color changes.

Note, however, that while I have seen this chart used and the team liked it, it may well provide too much detail to be actually useful. It’s an example of a kind of chart overkill that can occur. Such charts take time to produce, yet may not provide much value. Try charts like these but use judgment in the light of experience: fiddle with them, keep the ones that help, ditch the others.

Velocity Charts

It’s probably always good to track velocity, in terms of number of stories or story points. It can also be of value to show how your velocity is being spent, in terms of defect fixes or changes to previous stories.

One “classical” chart from Scrum is the burndown chart:

One issue with the burndown chart is that it doesn’t do a very good job of dealing with changes in the number of stories. One simple alternative is the burn UP chart. Here’s an example of a chart showing an increase in the number of stories, and an adjustment, therefore, in the anticipated ship date.

I like this chart. It’s simple, it shows clearly that changes in requirements are impacting the release date, and makes it clear that the decision about what to do to make the date lies in the hands of the requirements-givers. It’s a really nice example of a simple chart with powerful impact, and yet without much in the way of confrontation.

Defects

Defects, I suspect, are always bad. If a story has to be scheduled for a fix, there’s a problem. Most commonly, the Customer Acceptance Test was inadequate, or even missing. The result is that the story was done incorrectly, when it could have been done correctly, and new work is displaced for rework.

Story changes can be bad or good. It’s good when the customer learns, but too many changes might suggest that they’re being fickle or that they’d benefit from a little more thought.

Good or bad, however, defect fixes and story changes do consume time that might possibly be better spent. If you’re suspecting that there’s a problem, try a chart to see what happens.

The chart above shows new work “above the line” and defect and changes below the line. It shows very vividly the effect that changes and defects are having on new production. After I drew that one, I became concerned that it might be too pointed – it might be seen as too personal or to be pointing too strongly to someone or something. So I drew the one below, with the same information but without the above and below the line effect:

Same information, just a little difference in presentation. As I view the two charts, even a while after creating them, the second one seems to me to be a little bit less biased, a little more objective. It’s not making as much of a value judgment about the kinds of stories. (Of course, the color choices still imply a bit of value judgment.) When you create a chart, recognize that it is a powerful and public display. As such, a chart is politically very powerful and needs to be used with judgment.

I don’t really have any judgment to offer you – I just know you’ll do better if you use it.

Team Process

When a team is interested in improving its process, a few charts can be useful. You might find it valuable to track hours spent pair programming, or the number of integrations per day. You might want to display a chart about team code ownership – perhaps the number of different programmers or pairs who have edited a given class or module.

Another interesting chart can display the team’s goals and performance against goals on a number of the practices at once.

A judicious arrangement of the arms of a radar chart can give a chart a distinctive shape for various arrangements of practices: consider putting related practices for the customer, the programmers, the team, and so on, in the same sector of the chart. Then if, say, your team practices are low, the chart will look flat on that side, and if things are in balance, the chart will look fairly round. You should probably create your own chart based on your team’s desired pattern of practices, but for one interesting example, see Bill Wake’s article on the subject.

Other Possibilities

There are many charts that you might try, and different teams benefit from different ones. This is another reason to keep them casual and publicly posted. It offers the freedom to chart something new, and the freedom to get rid of useless charts rather than institutionalize them. Here are some starting ideas:

• Is time being wasted on the project? We've seen the feature / change / defect chart above. What other kinds of chart could you draw that call attention to how time is being spent, without threatening anyone, and without biasing the result to whatever you believe the time problem is? Meetings? Delays waiting for information? Handoffs? What's bugging you, and what effect is it having.
• Are builds breaking, or moving further apart? What kind of chart would show vividly what's happening?

Most everything you do needs communicating. Some of the things you do need communicating to everyone, and often words and reports don’t make the point. What picture can you draw that will make your point? It’s up to you.

Discussion and Commentary

(Hmm, maybe I need to enable comments on the pages. If you think they’d get used, drop me a note.)

Anyway, there was a fair amount of discussion on the Yahoo extremeprogramming group following the initial release of this article. Jeff Grigg commented:

I suspect that part of the "psychology" of Big Visible Charts is that when "Manager A" notices them, it's not that what's on the chart is likely to inform or motivate him very much. But he may start thinking about what would happen if "Manager Y," one or more levels above him, happens to wonder through the room and ask, "What's all this red stuff on this chart?" The answer, "Each red card on that wall is an interruption -- someone made us stop working on this project and rush off to do something else." might make Manager Y say, "That's outrageous! No wonder this project is late and over budget. I'm going to go talk to someone about that."

No doubt that’s part of the force of charts. In general, I guess they’re an element like advertising. They show up for everyone, affect everyone in different ways. Be alert for unexpected effects with your charts – especially negative effects. It’s probably best to start with examples that are too subtle, as a chart that hurts someone’s feelings or gets someone in trouble isn’t good for the team. On the other hand, sometimes you do have to drop a bomb, and in some groups, where you can’t be confrontive, it might be possible to get a message across without causing stress.

There was also a lot of discussion about my suggestion of starting with hand-made charts: Edmund Schweppe asked whether I think hand made is inherently better, and I allowed as how I’d not go quite that far. I would recommend to most outfits that they start that way. It kind of makes the chart something that anyone can do, not just someone with sufficient clout to get a pretty one made.

Plus, I think Big is a key word in Big Visible Chart, and so the letter-sized ones we can do with Excel and ordinary printers just don’t cut it from that angle.

Edmund pointed out that it might be more efficient to do them automatically (though I have my doubts about that), and that you can more easily put machine-generated pictures on a web site. That’s true. However, I believe that charts on the wall are “in your face”, and I think most folks agreed that on the web is a secondary place to put them, not the primary.

Adrian Howard said:

Whiteboards, post-it notes and index cards are the most cost effective ways I have to make BVCs. That's why I love 'em to death. I think production time is the wrong thing to emphasize. Manual and automatic are not *that* far apart. If BVCs are just seen a technology / cost / time issue I think their best points are being missed. Five minutes lost making a hardcopy isn't worth arguing about. Losing a hugely effective interactive communication medium is. That said, having the daily hardcopy on the wall is better than having it emailed to you every day. And having it emailed to you every day is better than having it on a web page you have to go visit. And having it on a web page all the time is better than having the project manager make a power-point presentation of progress once a month.... and so on...

Bill Wake said:

I don't know if the case is a lock, but there are things the hand-drawn ones have going for them that might make them inherently better:

• They acquire hand-written annotations that would be tedious to move forward
• * There's an equal-participation aspect to having a chart anyone can write on
• The hand-drawn nature reinforces their ephemerality - they're for the team now. (I don't want a misguided manager thinking they should get a monthly report on the # of integrations.)
• Hand-drawn charts are unique; I think they draw more attention than computer-printed charts.
• You can learn things by seeing which charts DO get updated; the automatic approach might hide some of this.

Doug Schwartz said:

We managed to inherit one of those big DesignJet printers from a failed Internet start-up that the corporation bought. [One] project manager has gotten in the habit of periodically printing some of the BVCs for the project she's on. They look gorgeous! And... I hate them! To me, they're sterile, and much less believable than the hand-written ones, with new scribbles layered on each day to show progress. Maybe it's just me, but the hand-written ones made with different color markers, with multiple people's handwriting, with the big "CODED" written on top of the card name by the programmers, with "DONE" layered on top of that when the customer and tester agree, have much more visceral impact when I walk in the room. They show works in progress, while the fancy printed ones just look like advertisements to me. It's probably the cynic in me, but I don't trust advertisements. Therefore, for me, it's somehow *inherently* better to do them manually.

Glen Alleman reminded us that XP didn’t invent charts (though as far as I know no one had claimed that) and pointed out that culture may impact whether charts should be hand-drawn or not.

From our experience there is no good reason not to have machine built charts, they come for free from the PVCS, UT, and Earned Value tracking systems. What seems to be missing form many-a a XP discussion is a context in which a reason might exist. If the culture of development is built around crayon drawn charts then fine, but of the culture is an engineering and design shop where CAD style charts are the "norm," then a machine generated BVC is also fine.

No doubt the important thing is to get the information out there radiating. I favor casual charts for the reasons mentioned here, and because I see them as less of a hurdle for most teams. If you have to get permission to use the big plotter, then manual is definitely the way to go!

Finally, Marty Andrews pointed to his site www.bigvisiblecharts.com, where he’s building a collection of charts. Visit him and send your charts to him, or to me.

The Bottom Line

Don’t forget Big Visible Charts. They’re a good way to call the team’s attention to things they need to be aware of. If a chart isn’t working, get rid of it or change it. If there’s something needing attention, and nothing else works, try a chart.

In fact, try the chart first, save parking lot therapy for later!