Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Continuous integration Build Status  Continuous integration Build Status   Testing Introduction   Testing Introduction

We continue with the theme as we address the use of lava lamps for continuous integration build status notification. We pick on lava lamps though other obscure mechanisms have been used also. These devices gained the somewhat esoteric title of eXtreme Feedback Devices or XFDs. Yes, the industry gave these a three Letter Acronym too. We certainly remember the devices generating a lot of discussion and excitement around 2004 to 2006. It should have stayed there, but it did not. It grew. Oh how it grew.

Basically, a device (a physical visible device) is connected by say a serial connector to the continuous integration server. On your continuous integration server you are running some form of continuous integration software such as cruisecontrol.net or some other software. When you commit your source code into a new build, the build status is updated often in a small database table. The device is programmed, or some software or firmware periodically polls, to enquire on the build status and generate an output as a result. The output in this instance was a switch to trigger lava lamps. The lava lamps used on agile projects came in pairs: red and green. The red lava lamp, when triggered, would indicate that the build has failed while the green lava lamp would indicate success.

We have seen or have heard of other devices such as multi-colour LED scrolling signs with tailored messages that announce success or failure displaying various comments including various levels of humour. You Tube videos of multicoloured glowing, throbbing, spherical orbs exist showing a kaleidoscope of colour when a build is successful along with hand built Pyramids connected via USB interface again glowing green for good and red for bad. You see what happened; the genie has exited the bottle. But as in all good tales, it gets worse.



An XFD we can barely believe ever saw the light of day were a pair of combined humidifiers. These humidifiers, allegedly, had a facility to effectively aerate any large room with clean fresh air whilst at the same time scenting the air with suitable aromas from fragrant essences duly added to the humidifier. do not get too far ahead of the story and let us continue. One humidifier was triggered to gradually infuse the development room with a sweet, tangy fresh perfume when continuous integration was successful.

This friendly bouquet, we understand, would permeate the room and the corridor if the door was left open to spread this welcoming odour across the floor of the office block thus announcing the build and integration success to the wider project team and the rest of the organisation. A simple and laudable declaration you would deduce until you consider the olfactory assault that was unleashed following an unsuccessful integration.

Obviously, every now and again the integrations would not work as well as they did before. An old piece of code might be left in by mistake; a change to a new table might be missed and not incorporated or a link to a component recently archived is left uncommented. It is an easy thing to do, regularly performed and often so easy to fix that you are probably already re-running your integration before anyone has had any chance to even see the error. However, that was not the case with the humidifier.

The simplest of integration failure would, of course, trigger the XFD. This time though, the sweet pleasant welcoming perfumes the teams had got so accustomed to were swiftly and disappointingly carried away to be almost immediately replaced with the rancid, choking, putrid stench (we are reliably informed) from what accurately compared with the rotting contents of the long since abandoned underground lavatory system of Hades himself.

Before you ask, we understand the smell was delivered from various pooled liquids in glass vials suitably sourced from a local comedy and joke warehouse. What made matters worse and you can only gasp in amazement how this nasal catastrophe could be made any worse, was that the office doors would invariably be left open or ajar.

So, as the team always wished to announce build integration statuses to the project team members by the swift and reliable mechanisms of the office corridor, the odour would make its thick wallowing laboured journey across the floor of the office block picking out every corner to uncover every last occupied office table and chair. No room was left un-odoured.

So, consider the situation. After the first roll of successful integrations the sweet perfume of success is acceptable and welcome. However, even the slightest error in a morning would overtake the atmosphere with a rank sickening odour that lingers and remains hovering about the nostrils of your project personnel until well after lunchtime, defying a plethora of successful integrations and the agreeable odours they seek to provide.

There is absolutely no problem in having fun on the project. It is massively important to have fun, enjoy your work and to enjoy your precious time on planet Earth. That is not the issue. The issue is that you will appraise how well the devices will go down in the location in which you work. Our work invariably takes us to customers offices and premises. We have seen other agile companies bring along such devices, unannounced. We refer to the lava lamps, not the humidifiers. This endeavour has had differing levels of success.

One such occurrence was in a very large investment bank. It comprised an experienced and forward thinking business team, an advanced IT development team and a results driven yet progressive management team. It was not a staid old-fashioned environment by any means. However, they elected to run their first SCRUM project and selected an agile delivery partner to delivery the project. The agile delivery partner was allocated their own dedicated office space to setup and get the first project underway.

The wall charts and boards and laptops arrived first. Some servers followed and a couple of IT staff established the development and integration environments. This of course included a cardboard box containing two new lava lamps. They were duly wired up over the weekend ready for the developers to start Monday morning. The first time the lava lamps appeared in their colourful glory, all hell broke loose.

The agile delivery partner was accused of being frivolous and of wasting time and valuable money. The agile delivery partner was challenged and requested to provide justification for introducing such an outlandish way of reporting. They could not of course. It was just a fun thing and it was cool. It was something their developers did.

The customer did not share the enthusiasm for the product and the management were not a little worried that the impression of a fun, hip, cool, frivolous project was not the immediate impression they wanted to put across or wanted their expensive agile delivery partner to convey either. This was further compounded because this was the first project of this type. The features and style of this project would be used as a basis for future agile projects and this was a feature that was immediately causing friction. It got worse.

Threats of legal action, accusations of contravention of electrical installation regulations, infringements of health and safety rules, risks of injury from broken glass or unspecified viscous materials tarnishing office tables, wasteful use of company electricity as well as unsatisfactory and unsolicited environmental impacts were all subjects that elicited serious debate we understand.

We were asked to intervene. The lava lamps were immediately unplugged and removed. But this was not the end of the topic. Throughout the project, when everything else was working fine, if an error ever occurred which was in any way associated with an integration (which is obviously very often) the subject of the dreaded lava lamps would surface once again casting yet more derision on the agile delivery partner. Sometimes a poor decision just sticks fast.

This example illustrates the point well. You need to be certain that the landscape will greet animated or expressive activities. Finally, you need to make sure it will accommodate such devices especially if your developers rely on them and expect them to be there at the start.

Now we have dealt with some lively and frivolous practices, we move onto some practices that are the total opposite. The opposite words for lively and frivolous are serious and grim. These are not appropriate words though and we prefer overwhelming and thorough to describe the following hugely, massively, enormously, tremendously important practices.

Buffer



 Continuous integration Build Status     Continuous integration Build Status   Testing Introduction    Testing Introduction



Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z


#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
eXtreme Feedback Devices XFD






   


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
   
Topic: 318  Page: 270/444  Progress: 60.8%
 About    |    Author 
Follow @BigAgileToolkit


This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL (http://www.bigagiletoolkit.com/) and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.