Sure, you are running continuous integration with loads of tests, at least every night. But what if a build or test fails? How long does it take your team to get back into ready-to-release mode?

Enter the red and green lights. Red goes on when a build or test fails. Red gets the boss out if his office. Red is bad. Green is good.

Hot lava and rocket launchers

A great addition is to use that hippie-style lava lamp - if your energy bill can take it. If it goes on, the coders need to implement a fix, get it into version control, and let the CI build and test it before the lava gets all hot and bubbly. There is even a lava lamp Jenkins plugin that includes all necessary circuitry.

Some even go all out and install rocket launchers that use “git blame” to shoot rockets at the poor schmuck that checked in the bad code until he or she fixes it. You can download the “eXtreme Feedback” Jenkins plugin to win your own coding battles.

Now here is a twist:

Why not install that same red and green light at your customer or partner?

Total transparency and commitment in true agile style. The customer knows you’re not ready to deliver the code when the light is red.

Yesterday’s weather

The lamp or rocket launcher has one big missing feature though. If the light is green, how do you know it’s not turning red on you the moment you want to release? The only way to get faith in quality is by looking at the past. Has the light been green for more than 5 consecutive days? Yesterday’s weather is always a good indicator for today’s.

Enter the hotboard or “wallboard” or “information radiator”. Hang a big TV on the wall in the hall so every employee, partner, investor, or customer immediately knows the status of your product.

What’s on a typical hotboard?

• Current build and test status. Traffic lights to instantly know where you’re at.
• Test pass/fail trends over the last iteration. Do developers add tests? Are they consistently passing? Do also add “skipped” tests to keep everyone honest.
• Quality trends such as a metric on code coverage and static analysis results. Some magic number to see if quality increases or not.
• Performance and memory consumption trends. Don’t forget these as a new feature can easily break the performance of your product without anybody finding out for weeks. The general adage is to catch these bugs as early as possible.
• A big timer counting down the days to the next milestone. Just to create some urgency.
• Organizational stuff such as the next company meetup. Or highly important: the real-time status of the coffee machine.

Atlassian has some great hotboard examples with all these elements from their Ultimate Wallboard Contest in 2010.

Implementing your hotboard

Many tools offer some hotboard functionality, such as the bug tracker (e.g. Jira), continuous integration (CI) environment (e.g. Jenkins), or static analysis tool (e.g. Coverity). The problem is that non of these do well in integrating all the tools you need. Bug trackers, CI, code coverage, static analysis, performance measurements or the coffee machine.

So let’s look at other technologies out there. The basics still rule: HTML5, jQuery, CSS3 for the visualization, and something custom to get the data. Python, Java, Apache Wicket, etc. Look at these beauties:

• the hotboard by Topicus
• this Panic board
• this amazing hotboard that includes red and green led backlighting to fight hotboard fatigue. Oh and it also checks if there are enough coffee beans left. See how Avisi built their Walle-d board.

To get started quickly, have a look at these hotboard frameworks:

• Avisi commercialized their Walle-d technology into the Dash wallboard framework.
• Atlasboard is a pretty neat (and open source) framework with default widgets for Atlassian’s products, but you can roll your own too.
• Dashing is a Sinatra-based framework to gather data and visualize it dashboard style and get up and running in no time. Look at this Dashing hotboard example.
• There are many more visualization frameworks to create dashboards (a dashboard typically being a subset of a full-fledged hotboard), see this list of 20 dashboard frameworks.

Fighting hotboard fatigue

Hotboard fatigue a.k.a wallboard blindness is a less-known disease that occurs in professional development teams that have a great hotboard but over time get so used to it that nobody looks at the board anymore.

A very simple remedy that fits nicely in agile is to assign a “watch”. Every morning before the daily stand-up, one developer checks the status of the hotboard and digs a bit deeper in the red flags, if any. She or he then reports the status at the stand-up and remains responsible for these issues to be removed as soon as possible by the team. Often that means the watch assigns developers to issues already during the stand up. This system also does magic if you run a more extensive test suite nightly and need someone to check the results the next morning.

The watch has this responsibility for a full development iteration. Then it rotates. This ensures every developer not only gets a clear quality focus, but also learns to help out the watch as much as possible. Just to make sure that when their time comes, the job will be easy.

How do you keep your development honest? Please share your hotboard best practices!