alacrity in action
| Tags: ,

release cow courtesy of Rachel Davies

When software development teams start with the practice of Continuous Integration (CI) coordinating check-ins and keeping the build clean can be a challenge. Some habits like making sure all unit tests pass locally, project builds correctly, and all relevant files are included, are not yet established. Introducing a simple build token is often helpful. This is how Rachel and Liz describe it in their “Agile Coaching” book:

For this [CI] to work, developers need to avoid treading on one another’s toes by attempting to integrate changes at the same time. Lots of teams use a build token, which can be any object that makes it obvious to the rest of the team that there’s an integration in progress. Teams have a bit of fun with this, which helps establish the CI process as a team ritual. We’ve seen teams use a rubber chicken, a moo cow, funny hats, and even a “Sword of Integration” made from index cards.

by energizer (Energized Work)

Mature and experienced teams usually no longer need to use a token yet they often choose to keep it or adopt its use. At Energized Work, for example, we use a broken build token. If a pair breaks the build, they pick from a selection of fancy hats to let the team know who is currently working to fix the problem. It is important as a broken build can impede others’ progress. (It is also in line with the stop the line Lean approach.)

Using a build token, however, can also have some unintended consequences if dysfunctions obscure its intention.

Invisible token

The token only works if it is visible to the whole team. If the team is distribution across the office there are probably other priorities that need attention other than synchronising the use of source-code repository. For distributed teams on-line tools may be helpful but co-location is usually better.

Controlled token

Remember the (now ancient, I guess) token ring network topology? The build token should be able to travel around the team like a token in the token ring network. No one should permanently claim its ownership. This can be particularly problematic if the owner happens to be the most senior developer or a manager trying to control the token. Rather than helping to establish a common ritual and improve collaboration it becomes yet another whip for the team. With process becoming formalised and controlled, people begin to avoid it. The most likely outcome – integration frequency drops and one of the main benefits of CI is undermined. There is also the negative effects on morale when people feel treated like children who must ask mum every time they want to watch TV.

Forced token

A build token is a tool to help with a concrete problem. Just because it worked for one team (in a specific set of circumstances and at a given time) does not mean it will be useful for everyone. Making it a company-wide policy is another case when it may backfire. Some teams will be more experienced and will have established robust communication paths, they don’t necessarily need a token (it can slow them down). Others will only share a code repository without a build server, they don’t need it (yet). Above all, however, it is a tool for the team and it is the team who should reach a consensus on using the tool if it is to work to their benefit. Even, if a practice is generally helpful but have been forced upon you, there will simply be no desire to tap into its full potential.

Embarrassing token

This is probably a minor problem and only relevant for immature teams. Yet if you notice someone in the team is less keen on holding on to the token they may be embarrassed by it. While intended to be funny or cute the choice of the token must meet everyone’s approval.

Token of shame

For the practice similar to that of the failed build token there is another aspect to consider. If the level of trust is not high enough, especially for new people who join the team after it has been formed and bonded, holding a token that clearly indicates who broke the build can be discomforting. It might be fine generally but sometimes there is a fine line and crossing it will put people off. A practice of pair programming helps greatly in those circumstances as there is always someone else in the same situation.

Have fun with your build token and use it wisely.


  1. Pingback: Tweets that mention Marcin Floryan » Build token --

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.