Agile principles: feedback – part 2

Some time ago our project received a new large-screen TV set. With my colleague and friend, László Tarcsányi, we thought it’d be a good means of providing feedback. We also thought it would be great if it was used for showing the current status of our most used project tracks. By status, of course, I mean: build has been ok for a while, broken for a while, currently building etc.

Fortunately, we use Hudson as continuous integration system, which has a very good support for plugins. It didn’t take us long time to find this plugin, called Radiator View (check it out here: http://wiki.hudson-ci.org/display/HUDSON/Radiator+View+Plugin). It can be configured to show one or more tracks at a time, to show/hide stable views, show/hide possible build breakers (people who checked in source code since the last green build). It looks like this:

 Broken builds are always shown in the upper part of the screen, in red. In order to be easily noticeable, these red builds cover the most part of the screen.

The idea behind the plugin seems to be working. Broken builds get caught much faster. We had an e-mail based build-status reporting system, but unfortunately that was not efficient. E-mails can be easily missed, the TV on the wall can not (unless you’re walking with your eyes closed). Another problem with the e-mail based solution was that it was sending messages to only that person who broke the build (or to one team, at most). In these situations there might not be enough capacity to fix the build. However, a projected red build is frustrating to all of us. The broken build can be fixed by any person with sveral minutes of spare time.

The TV is also showing the status of our nightly builds. The nice server monitoring application has been created by László Tarcsányi and Kornél Schmeiszer. You can immediately tell how many test cases failed, how many went well and how many test cases were run alltogether (See the screenshot). It looks really nice and can be understood in seconds.

We also project a red-green-refactor picture, in order to keep in mind what’s the right behavior when implementing new functionalities.
Advertisements

Author: tamasgyorfi

Senior software engineer, certified enterprise architect and certified Scrum master. Feel free to connect on Twitter: @tamasgyorfi

3 thoughts on “Agile principles: feedback – part 2”

    1. I think people are getting used to it. I’ve heard them surprisedly say “Oh no, build’s broken”. But fortunately we already have several people who actually fix it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s