BI-Beacon was initially known as CILAMP; short for Continuous Integration Lamp. The problem that CI status indicators (or “build lamps”) solve is one of developer coordination and cooperation.

When several code changes happen concurrently on each developer machine, and those changes are checked in to a shared code server, it is in the whole teams’ interest that the state of the joint code base is still OK:

• The system should always compile without errors
• All automatic tests (unit, integration, system) should still be passing
• Generating artifacts (installers, packages, app bundles) should still work

How BI-Beacon is utilized in a CI/CD scenario

Using triggers or polling of the build servers current state together with BI-Beacon – a live indication of the current or previous build can be visualized in a physical arena where all devs can see, for instance in the center of the room.

A slow yellow pulse means the build server is currently building; the result is not yet available.

Green color indicates that the the system built without errors – all tests passed. Everyone can update their local sources (or fork master) without worry, and it’s also an excellent time to check in your changes.

Red means something failed; either with a compile error or some test didn’t pass. Now is not a good time to update your local source.

Effect

Having a build indicator available makes the team collaborate more efficiently, and avoids conflicts where developers are annoyed with each other’s bad commits; in fact, this is such a common need that throughout the years development teams have often spent their time and energy on coming up with their own homegrown solutions, as in the left image below.

Of course your ninja-devs could probably come up with their own solution to this problem, however travelling that road is rocky and may come at a high cost:

• Developer time is expensive, and building even “homegrown hacks” is non-trivial
• Homegrown solutions tend to fail after some time, causing either service outage or high maintenance cost
• The developer that initially built the solution may switch workplace, again causing a service outage

A BI-Beacon client was launching a new service, which customers could sign-up for on their web site.

Whenever a sign-up occurred, a database was updated. Once a week, a report was generated on how many sign-ups the company had the previous week. However, this method suffered from two issues:

• PDF presentations during Monday meetings are not super exciting 🙂
• The relatively long period between registrations and the status reporting made it hard for the staff to see the correlation to their work

How BI-Beacon is used to celebrate sign-ups

By positioning a BI-Beacon centrally at the office, at a vantage point visible for most people, everyone could see in real-time when a new sign-up happened.

Results

Since sign-ups became visible in real-time, it caused daily celebration at the office, with increased awareness as a result. This in turn sparked ideas on how to get more sign-ups naturally and playfully. For instance, coworkers started sharing the sign-up page on social media to attract new people.

The integration was as simple as adding an SQL trigger to the relevant database table in the service.

One BI-Beacon customer was trying to get higher software quality by introducing code-reviews in the development team. However, they struggled in this process change, even though developers agreed it was a good practice to do code reviews. A couple of observations stood out when identifying the business issues at hand:

• Code reviews were lagging behind schedule, causing delays in delivery for the rest of the organization and customers
• Code reviewing was seen as something dull and boring, and less productive than “actual coding”

How BI-Beacon was used to embrace code reviews

By positioning a BI-Beacon by the coffee machine, just outside the developer room, everyone that went for a coffee got a clear indication of the state of code reviews.

This is what the colors indicated:

Yellow meant there is some code to review.

Purple pulsing slowly meant some code had been waiting for review for more than four days. Get on with it already!

Green color meant all code reviews are done – hurray!

Results

By showing clearly the value of code reviews – no one missed the glowing light indicator by the coffee machine! – it was suddenly a lot easier to get code reviews happening. Developers also expressed that it was more fun to do code reviews, as it turned into a kind of game at the office, but also that it was clear that the whole organization valued code reviews and the increased quality it brings to software development.

The integration was done by regularly running a Python script that checked the state of issues being worked on by the development team.

One BI-Beacon customer had an innovative idea on how to increase throughput in internal support and operations. The issues were two-fold.

• Low awareness of new tickets coming into internal support ticket system
• A lot of human related disturbances, stressful and inefficient for everyone involved and often reducing operations efficiency unnecessarily

How they use BI-Beacon

By integrating a BI-Beacon physically at the office, close to operations, both problems were reduced. This is how they did it:

Purple color means there are unassigned high priority (system is down, or other critical issues) tickets in the support system, who will be the first to respond?

Green color means all tickets in the support system is assigned to a co-worker, and none of them are high priority . Things are under control and no immediate action is required!

Red pulsing color means there is a priority one ticket being worked on (or unassigned), so please do not disturb us, we are working as hard as we can!

Results

By showing the support system state in this accessible way, they reduced the human disturbances of support, and engaged support personnel in assigning tickets as soon as they are in. In this way they sort of gamified the daily experience of working in support and operations, making business more efficient for everyone.

From a technical standpoint, the integration/coding effort was minimal, and done using a database query and a script polling the support system database every minute.