Blue Flower

Many teams and companies have found information radiators useful. These are displays that show information and statistics, such as burndown charts, open issues, top backlog stories, or days till product release. They are located in well-trafficked areas, so rather than having to look up the information, people can almost absorb it by osmosis as they walk by. And seeing the information each time they walk by makes it more likely that they will notice important changes.

Most of the information radiators reported in the literature have been projects done by single teams, or a few teams in small companies. When you try to scale it up to a company with a lot of teams, it becomes trickier: although each team needs displays customized to the team, each team should not have to come up with their own solution, taking up time that would be better spent on product development. And standardizing hardware makes support easier, as well as keeping individual teams from getting too extravagant. (The 55-inch commercial display used by panic.com's information radiator is tempting, but at over $3000, is a bit hard on the budget.)

What is needed is a standard way to set up information radiators that is not overly expensive, and does not take a lot of time to do. Here is a proposal for such a scheme.

A lot of companies have spare laptops and monitors, either because of upgrades or, in today's lagging economy, reductions in force. The monitors are frequently in the 21-inch range which, while not as impressive as a 55-inch display, will do the job if placed on a counter or bookcase. The laptops do not need to be particularly powerful; they just need to be able to run a web browser. They can be running Windows, Linux, FreeBSD Unix, or Mac OSX; it doesn't matter.

Some companies may be nervous that laptops that sit out day and night running the information displays might be stolen after hours. If this is a concern, or if you do not have a surplus of laptops, Android-powered set-top boxes, which cost less than $100, could be used instead. (You will probably have to clear this with your local IT department, as many have rules about attaching non-standard equipment to their networks.)

Once you have the laptop and monitor set up, you just need a start-up script that brings up the browser, which has its home page set to a special URL for information radiators, perhaps something like radiator.example.com. Spare laptops could be set up this way in advance, so when someone needs an information radiator, you just hand them the laptop and a monitor, and they find an Ethernet connection and plug it in. This relieves the IT department of the burden of setting up the information radiator.

The special URL points to a web server that supplies the pages for the displays. The server checks the IP address of the requester against a list of known IP addresses. If it does not recognize the IP address, it returns a page that displays the IP address, as well as who to contact to register the IP address. (It is assumed that the IP address will be static, since the information radiator is not moving around. If this is not the case, the registrar could, with a bit more effort, add its MAC address to the DHCP server to ensure that it remains the same.)

When someone registers an information radiator, they indicate the team they are with and what reports they want. Most teams will want the same sort of reports, using data extracted from the sprint-tracking or issue-tracking system and customized for their team. The server will return web pages for the various reports. Each page will include a META REFRESH tag that will cause the page to refresh every 15 seconds, and a different page will be displayed each time, cycling through the reports registered for that IP address. The company can also insert additional pages, like the days till product launch, or the date of the company picnic.

Although the pages are refreshing every 15 seconds, the reports will not actually be generated that often. Since the server knows what reports the various information radiators want for each team, it can pre-generate the reports at reasonable intervals and cache them. For example, if sprint hours are burned down in the daily standup, there is no need to generate the burndown report more than a few times a day (to accommodate teams with morning or afternoon standup schedules). On the other hand, a report of outstanding issues should probably be generated much more often.

If teams want to create their own reports, they can be contributed to the server, as long as they are parameterized, so that other teams can use them.

This approach lets teams get the benefits of information radiators without a lot of expense or setup time, imposes some standardization without being onerous, and lets teams easily share custom reports with other teams that might find them useful.

If the volume of new information radiator requests becomes high enough, a web-based GUI could be developed, to let teams register their information radiators and select which reports they would like. Chances are, though, that doing so would be more work than just having someone manually register them.