With Agile and Continuous Integration becoming popular, a significant number of development teams are using information radiators – mostly focussed on showing the latest build status. Information radiators are a very powerful way to aid communication and subtly adjust a team’s behaviour and attitude. The catch however is that it can be quite hard to control how you subtly adjust the team’s attitude because the pressure to change is so subtle.

Probably the best example of information radiators working against the team is displaying build status when the build almost always fails. Since the screen is continuously red it quickly desensitises the team and actually encourages them to ignore test failures – exactly the opposite to the desired behaviour.

The key to making information radiators work is to think long and hard about everything that is and isn’t displayed there in great detail – positioning, font size, colour, groupings and relations all impact the information that is being radiated. For example, if the aim is to encourage the team to quickly notice and fix test failures and tests that fail are marked in red, then it’s vital that any information on that radiator which is red is something the team should treat as top priority to fix. If it’s not the same priority as a broken test then put it on a different radiator or make it a different colour.

If you’re suffering with a lot of intermittent test failures, focus on the number of failures rather than just showing a red screen constantly. Displaying the number of failures in a font size that increases with the number of failing tests can add a useful distinction. As the intermittency is reduced, increase the rate that the font size ramps up – that way a “bad” test run stays roughly the same font size.

Another common mistake is to boldly display failures for nightly runs all day long. Information that only changes once a day shouldn’t be permanently on a radiator – use email, IM or other methods to keep people informed of the status. Another option is to bundle up a group of things that are concerning when they fail but can’t be fixed quickly for whatever reason and group them together on one display. That way they are separated from the “fix this now” type of things like unit tests and are less likely to desensitise the team.

Finally, make sure you carefully chose the type of visualisation. Red/green works well for things that are absolute – either passing or failing, but it can’t show trends. Graphs can be powerful to show trends over type but aren’t as good at highlighting wether or not the current value is in a range. For showing ranges or magnitude, consider using gauges etc. There are plenty of other types of visualisations that are useful in different situations so make sure the one you pick is suitable for the type of data you’re visualising.

With a little bit of careful thought and planning, combined with ongoing tweaking and improvement information radiators can dramatically improve the effectiveness of your team and push them towards the right kind of habits. Used correctly, they are one of the most important tools in software development.