Cruise Control health meter

I use Cruise Control. It’s my automated build weapon of choice. Why? For no other reason that it was the first one that I got my hands on. I (mostly) understand it, trust it and know its quirks and foibles.

It also has a neat feature – it shows project metrics. These are shown as pie and scatter charts displaying successful and unsuccessful builds. Both of these provide useful indicators about the health of a given project.

Taking the scatter chart first. This is a calendar with day on the X axis, and time on the Y axis. A dot is placed on a calendar every time there is a build – red for fail, blue for success. From this you can get a feel for the following:

• How many checkins are being done per day
• How successful they are
• How long a build stays broken
• Whether the Team is staying unusually late or coming in at weekends

All of these are useful indicators as to how things are going in general. I look for regular checkins during standard working hours and fast recovery from breakage – and I encourage the Team to investigate if this pattern is broken. All fairly straightforward and uncontroversial in the agile world.

The pie chart does something similar – it shows the proportion of broken to successful builds in isolation. Not necessarily as useful as the calendar scatter, or is it?

I have noticed an interesting trend with the pie chart in Cruise Control. At the moment it is nothing more than a gut feel or rule of thumb based on the observation of several teams, and I certainly have no data to back this up….but successful, dynamic teams appear to break somewhere between 15% and 25% of builds.

Shock! Horror! Agile teams break the build!

Well, yes. Breaking stuff unexpectedly is how you learn and improve. It is also the motivation to fix structure and design. So the point I am making is: Yes, teams should expect to break the build once in a while and question if they are not. It would seem that somewhere around 20% is the sweet spot where the Team is behaving optimally. Much more than this and something is going seriously wrong. Less than this and there is either not enough refactoring pressure on the design or the design is almost perfect (I know which of these I would suspect initially).