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.