© Alistair Cockburn
Coined around 2000 while standing in a Thoughtworks office looking at all the paper on the walls around me, “information radiator” refers to a publicly posted display that shows people walking by what is going on. Information radiators are best when they are big, very easy to see (e.g. not online, generally), and change often enough to be worth revisiting.
Here’s the description from the
Crystal Clear book (discussion: Re: Crystal Clear book), 2004.
An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions.
A good information radiator
- Is large and easily visible to the casual, interested observer
- Is understood at a glance
- Changes periodically, so that it is worth visiting
- Is easily kept up to date
Typically, it is on paper, posted in the team room or in the hallway. In a few exceptional circumstances, it is on a Web page that people refer to frequently. Unusual examples of information radiators include a (real!) traffic light, a colored orb, and a computer monitor hung outside a cubicle’s partition in the hallway.
Todd Little of Landmark Graphics made the interesting observation that information radiators generally serve to inform people outside the project team. The people on the project team generally know the information posted, because of their close communications with each other. It is the people outside the team who want or need to know that information in order to make their own decisions, and otherwise would interrupt the team to get that information, or would simply guess at it (often incorrectly).
Information radiators can be used on any project, large or small. A small team can use them very conveniently to maintain information that they otherwise would have to maintain on the computer (which is both slower and less visible).
Information radiators are typically used to show status information, such as:
- The current iteration’s work set (use cases or stories)
- The current work assignments
- The number of tests written (or passed)
- The number of use cases (or stories) delivered
- The status of key servers (up, down, in maintenance)
- The core of the domain model
- The results of the last reflection workshop
Online files and Web page generally do not make good information radiators, because an information radiator needs to be visible without significant effort on the part of the viewer. I have, of course, run into exceptions with this rule. One was the team performing Continuous Integration with CruiseControl, a dedicated server running a build-and-test script, and posting the test results to a Web page. The programmers tended to leave that Web page visible at all times on their screens, so they could respond to failing integration tests immediately. The other exception was the monitor hung over a cubicle wall into the hallway (see Figure 3-5), displaying current run time measurements of the system in use.
Freeman-Benson and Borning wrote an experience report on a methodology they call YP (Freeman-Benson 2003). They report on the effect of using a real traffic light:
Actually there are several: one in the hallway of our laboratory, two more in developer offices, and one virtual traffic light on the web. We use four color combinations:
- green when the build and all the tests have succeeded,
- yellow when the build and tests are in progress,
- yellow and green together when the build has passed the point where it is likely to fail (in practice, this means that all the tests have passed and that the final installer and distribution are being produced), and
- red if any part of the build or tests has failed.
The traffic light is a powerful symbol of the current state of the software. The web version at www.urbansim.org/fireman makes the status visible to anyone else who might be interested (including you, Gentle Reader, if you wish), and in particular for our customers, although in a less compelling way than the physical device.
The first author has used the traffic light as part of applying YP in four other development projects as well. Interestingly, only one team in addition to ours is still using the light—the other teams disconnected their lights because they didn’t like them being red all the time. Rather than fixing the underlying problem (that their system was sufficiently unstable that their regression tests would not pass reliably), they chose to “eliminate the messenger.” Only one of the teams acknowledged this decision explicitly.
In conversations with other team leads and software managers, we learned that a number of them had tried “failure indicators” such as sirens, flashing lights, red lights, and so forth, and that each had cancelled the experiment after a few days. Apparently the use of negative reinforcement (a red light) without the corresponding positive reinforcement (a green light) was too damaging to morale. Our experience with the traffic light is quite the opposite: everyone who joins a YP team immediately reports a sense of comfort at the large (8–12”) green light glowing its message of “all is well with the build.” Or on the rare occasions when the software has failed the nightly build tests, as the staff arrives in the morning, in the winter’s gloom, with the lab hallway illuminated by the red glow of the traffic light, it’s clear that a) something has gone wrong, and b) it should get fixed as soon as possible.
Project status, as
Earned-value and burn charts (discussion: Re: Earned-value and burn charts), make particularly good information radiators.
Visit Category:Information radiator to see the list of photos and examples.
There are many examples on the web. A search will turn up lots. Here are a few:
Sample:
I’ve always considered the Information Radiators one of the key elements in enhancing team communication and transparency on its own working status.
-by Fabio Armani on 6/14/2011 at 9:54 AM
Information radiators are an important and maybe even a must for every (IT) company.
We build our own radiator on top of Jira, Confluence, Nagios, Jenkins, Google Calendar and it also shows us some Tweets.
Google: “building an information radiator part i introduction”
-by Avisi on 3/22/2012 at 6:26 AM