Sometimes teams have trouble starting new habits: writing unit tests, fix compiler warnings, not breaking the build. How do we help the team change these habits? Clint Shank designed a game to help people transition.
Now Erik Ramfelt has written a "The Continuous Integration Game plugin" for Hudson. The premise is that sometimes developers need a push to do the right thing:
I've had problems in the past with people breaking the build. To help, I've used techniques like the rotating Build Nazi and the put a dollar in the broken build jar, but these are all negative focused. How about something that rewards developers that don't break the build? How about rewarding developers for following the best practice of breaking their work into smaller chunks and checking in early and often?
After reading Darin Cummins article "The Development Game" (Agile Development Conference 2004), Clint came up with the idea for a game were developers are rewarded for doing good things with the build and punished for doing bad.
As implemented by Eric your karma is calculated with the following rules:
The rules of the game are:
- -10 points for breaking a build
- 0 points for breaking a build that already was broken
- +1 points for doing a build with no failures (unstable builds gives no points)
- -1 points for each new test failures
- +1 points for each new test that passes
Rules that depend on other plugins:
- PMD Plugin. Adding/removing a HIGH priority warning = -5/+5. Adding/removing a MEDIUM priority warning = -3/+3. Adding/removing a LOW priority warning = -1/+1.
- Task Scanner Plugin. Adding/removing a HIGH priority task = -5/+5. Adding/removing a MEDIUM priority task = -3/+3. Adding/removing a LOW priority task = -1/+1
- Warnings Plugin. Adding/removing a compiler warning = -1/+1.
- ...
As Clint warns you do have be on the lookout for cheaters (perhaps doing trivial and pointless checkins every hour) and reset the points every so often to given everyone a chance to win eventually.
When this was discussed on Scrum Development several concerns were raised. Graeme Matthew points out that if the rewards are too big developers might be focused on doing things to improve their score and not deliver value to the customer. Ilja Preuss suggested:
Another thing to keep in mind is that extrinsic motivation typically is in violent conflict with intrinsic motivation. That is, if your team already is well intrinsically motivated, you might well may things worse by adding extrinsic motivation.
Finally Pete Deemer said:
It seems to me like a complex framework of individual incentives would inadvertently cultivate "I" thinking to he detriment of "we" (team) thinking (the latter being one of the "quiet accelerators" in scrum); it would invite optimization at the micro level that is sub-optimal at the macro level; and it would generate a lot of ceremony and mental activity around things other than the the doing of the work in service of the customer.
Community comments
Focussing on the "We" and on root causes
by Ilja Preuß,
Re: Focussing on the
by Mark Levison,
Make it "We"
by Will Read,
Re: Make it
by Mark Levison,
Focussing on the "We" and on root causes
by Ilja Preuß,
Your message is awaiting moderation. Thank you for participating in the discussion.
Our team too had trouble with broken builds. Our solution was to implement a "Stop the Line" approach, though. That is, every time the build breaks, the whole team gathers to analyze the problem and find both a solution for the current problem as well as for the root cause.
This approach seems to be very effective, mostly - so it seems to me - because it doesn't assume the prevalent reason for problems to be that people are just lazy or undisciplined. Since we have started using Stop the Line, we have implemented a wide range of solutions, from the reduction of redundant information in the build system, over changing some conventions regarding our use of SVN, to implementing an Eclipse plugin to make it easier to run all relevant tests before checkin.
Another nice side effect is that it strengthens the collaboration in the team, instead of setting up an atmosphere of competition.
Re: Focussing on the
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
Ilja as usual an elegant solution. I was conflicted when I wrote this piece. On the one hand I like games and how they can make an annoying thing fun on the other I don't like how the competitive aspect can damage the team dynamic.
Make it "We"
by Will Read,
Your message is awaiting moderation. Thank you for participating in the discussion.
What if you make the point accumulation to be on a team basis? If someone breaks the build, the team loses 10 points. If someone makes a successful build, the team benefits. Then set a goal for the month/sprint/whatever of X points. If the goal is met, then the team gets something good, and the team sets a higher goal for the next iteration. If the goal is not met, lower the goal to something more obtainable, and progress from there (similar to using velocity)
Re: Make it
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
Will it sounds like an interesting idea. I think the key thing here would be you have to get the team to agree that they want to do it. Also you have to set both the metrics and the reward very very carefully. Set this up wrong and the focus won't be on delivering value for the customer. Instead it will be on gaming the metric.
Do you want to try this out and report back in a few iterations? Seriously.