When dealing with complex agile transformations in large enterprises, use bottom-up implementation and top-down intent. Mike introduced this…
Information radiators are commonly used in operations to display the status of servers, network segments, and transaction traffic. Here’s an example of a server status display (the product shown is nPulse; there are many others):
The purpose of an information radiator may not be apparent to software development teams that have not used lightweight, collaborative methods in the past. When we introduce such methods, many novice teams conflate the notion of an information radiator with that of a project management tool. They assume that maintaining information radiators in their team workspaces represents “duplicate effort” on top of keeping information up to date in their Application Lifecycle Management (ALM) tool. In fact, the two types of tools have quite different purposes.
What’s a radiator?
A thing that “radiates” emits output continuously. To receive that output, one only need be exposed to the radiator. The sun is an example of a radiator. It emits heat, light, neutrinos, and assorted charged particles.
Here is an unretouched photograph of the sun (courtesy of NASA):
The key characteristic of an information radiator is that one need not “sign in” or “be authorized” or “search for information.” One need only be exposed to it.
What’s it good for?
The value of information radiators is obvious in the context of operations support. The sooner people notice something is going awry, the sooner they can take corrective or preventive action. If they had to stop what they were doing, sign into a system, and search for status information about the network or servers, many problems would go unnoticed until they had become serious.
In the context of traditional software development methods, the value may be less obvious. Progress is fairly slow, and status doesn’t change frequently. In organizations that use traditional methods, development teams spend most of their time waiting for each other to perform small tasks.
When a team starts to use lightweight methods, they begin to deliver incrementally in much shorter cycles. In that environment, things change frequently and require immediate action. If they had to stop what they were doing, sign into a system, and search for status information about the status of the work, many problems would go unnoticed until they had become serious.
Development teams use a couple of different types of information radiators. One type gives everyone in the team room an at-a-glance view of the status of all in-flight work. Anyone can see what’s going on, what’s blocked, how much work is in progress in each state, and considerably more. They don’t have to stop what they’re doing and sign into a system to find that information.
Here’s an example:
The second type of information radiator used by development teams is an electronic display of the current build status. Teams using these methods commit code changes frequently throughout the day, and the commits trigger an automated build and test processes. The teams need feedback from these runs so they can fix any problems without delay.
Here’s a photo of an information radiator that uses four monitors to display the build status for a variety of builds:
The other key characteristic of information radiators is that they do not maintain historical information. They display point-in-time information only. Once the point in time has passed, the information is gone.
Information about blockers, WIP, team member availability, and build status must be easy to see without the need for a context switch so that people can take appropriate action without delay.
Development teams need a good deal of information that doesn’t require immediate action, as well. This can include documentation of UX requirements, UI branding, legal requirements, architectural standards, APIs, data layouts, test environments, lists of reference data such as codes and contact information, and supporting details of functional requirements. It may also include a history of work that has been completed and archived.
Information of that kind is best housed in a system that supports querying and searching. It need not “radiate” in the team workspace. It is in the nature of reference information. In fact, when teams try to “radiate” all information relevant to their project, the result tends to be cluttered and hard to read. This defeats the purpose of information radiators.
Another reality for many teams is that all team members are not collocated. Distributed or dispersed teams need a practical way to share information about WIP, blockers, and other information. In these cases, an electronic information radiator may be necessary. Although tactile tools are generally more effective inside a team room, when teams are not collocated an electronic version of a “card wall” is a reasonable second-best solution.
Most ALMs offer a view of planned work and work in progress that looks like “cards.” Using a smart board, team members in all locations can move card images around on the screen so that everyone can see status at a glance.
In addition to the information needs of the development team, the surrounding organization needs information about the general status of programs or larger initiatives and the performance of the various development teams. ALMs provide this sort of functionality.
What’s the problem?
The problem is that novice teams don’t seem to understand the difference between those two use cases. They assume they can use their ALM for the immediate, at-a-glance type of information.
A common anti-pattern that emerges from this idea is to print out “story cards” from the ALM and post them on the wall. These “story cards” are so detailed, and contain so much small print, that they cannot provide an at-a-glance view of status from across the room. This defeats the purpose of the informatio radiator.
What’s a vault?
An ALM is not an information radiator, because users must be authorized to access the tool, then they must sign in to use it, and then they must query and/or search for the information they need. An ALM is an information vault.
Here is a picture of an ALM:
It’s appropriate to maintain certain kinds of information in a vault, but it is in no way equivalent to an information radiator.