Editorial Note: I originally wrote this post for the NDepend blog. Check out the original post here, at the site. While you’re there, check out NDepend — it’s my go-to tool for the codebase assessments that I do as part of my consulting practice.
If you hang around agile circles long enough, you’re quite likely to hear the terms “big, visible chart” and “information radiator.” I think both of these loosely originate from the general management concept that, to demonstrably improve something, you must first measure and track it. A “big, visible chart” is information that an individual or team displays in, well, big and visible fashion. An information radiator is more or less the same concept (I’m sure it’s possible for someone who is an 8th degree agile black belt to sharp-shoot this, but I think you’d be hard pressed to argue that this isn’t the gist).
Big, Visible Information Radiators
As perhaps the most ubiquitous example imaginable, consider the factory sign that proudly displays, “____ days since the last accident,” where, hopefully, the blank contains a large number. A sign like this is far from a feel-good vanity metric; it actually alters behavior. Imagine a factory where lots of accidents happen. Line managers can call meetings and harp on the importance of safety, but probably to limited effect. After all, the prospect of a floor incident is abstract, particularly for someone to whom it hasn’t ever happened.
But if you start putting a number on it, the concept becomes less abstract. “Currently we have an incident every day, but we want to try to make it happen only once per month, and we’re going to keep track.” Now, each incident means that the entire factory fails each and every day, and it does so visibly. Incidents go from “someone else’s problem that you hear about anecdotally from time to time” to “the thing that’s making us fail visibly.” And then you’ll find that doing nothing but making the number very visible will serve actually to alter behavior — people will be more careful so as not to be responsible for tanking the team’s metrics.
In the world of agile, the earliest and most common bit of information to see was the team’s card wall: which features were in progress, which were being tested, which were complete, and who was working on what. This served double duty of creating public visibility/accountability and providing an answer to the project manager’s “whatcha doin?” without interruptions or mind-numbing status meetings. But times and technologies progressed, resulting in other information being visible to the team at all times.
These days, it’s common to see a big television or monitor located near a team and displaying the status of the team’s code on the build machine. Jenkins is a tool very commonly used to do this, and it will show you projects with red for failing and green for all good. If you want to get creative, you can use home automation tech to have red or green lamps turn on and off. For the team, this is a way of exposing broken builds as a deficiency and incenting team members to keep it in a consistently passing state.
Read More
