Rewards to Improve Team Habits?

by Mark Levison on Jul 03, 2008 |

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.

Related Editorial

Cloud Identity Buyer’s Guide: Managing Identity in the Cloud

Infographic: Just How Big is the Nerd Economy

Five Key Practices to Agile ALM

Agile Maturity Model Applied to Building and Releasing Software

Agile workshops and training

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Focussing on the "We" and on root causes by Ilja Preuß Posted

Re: Focussing on the by Mark Levison Posted

Make it "We" by Will Read Posted

Re: Make it by Mark Levison Posted

Focussing on the "We" and on root causes by Ilja Preuß

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

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

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

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.