At Monday’s retrospective, my answer to the question, “What should we do differently”, was to "have more fun". We have been cranking out releases for 85 iterations and the new year seemed like a good time to try something fresh. One of my testers came up with Bug Bucks.
Although it violates several agile practices, we’re going to give it a try. Here’s how it works:
- Each programmer earns Buck Bucks equal to the magnitude of Features they code (e.g., a Feature with a magnitude (AKA complexity) of 13 would earn the programmer 13 Bug Bucks).
- Any tester, BA, or other programmer who finds a bug in said Feature, gets to take away a Bug Buck from the programmer who coded it. The programmer only loses the Bug Buck if the team decides to fix it.
- Bugs found in production subtract a Bug Buck from each team member (all testers, BAs, and programmers).
- We have various denominations of Bug Bucks to make change, and team members will pin them to their cubes as they acquire them.
So what can one do with a Bug Buck? We’re still working on that but pending budget approval, we will let them be exchanged for gifts, or more likely, one minute of personal time off, which should work out to a free day off per quarter for ambitious players!
There are several problems we are aware of; such as, will this discourage collaboration? Um…yes.
But will it really? In the big picture? We've already been collaborating on the rules. Anyway, our current approach is not to over-engineer this game, but to try to have some fun. If our velocity changes for the worst, we’ll pull the plug... just have to wait and see.
I'll report back.
5 comments:
Subscribe to:
Post Comments (Atom)
RSS
Interesting idea.
I'm not sure about how well it'll motivate those writing the more difficult & complex designs which are more prone to errors.
Whilst the easier tasks get done rapidly and often with less bugs. Earning that programmer the equivalent of the complex task with less risk of losing points (possibly).
Perhaps the people with the easier tasks will have more chance of getting that day off?
I honestly don't know myself. What I do know though is that when competitions occur people have a tendency to cheat the system so to speak. Cherry picking the easy stuff, producing ideas / concepts that other have already suggested in the past & passing it off as new.
At the end of the day, you don't know until you try. So good luck & I hope you'll blog about how it went & peoples perceptions of it at a later date.
Thanks for the feedback, Darren.
Ah, but that's the beauty of the magnitudes. As long as we're assigning magnitudes correctly, the simple Features may only earn the programmer 3 Bug Bucks, while the complex Features may earn the programmer 13. Should balance out, right?
One of our fears was that the magnitudes may get inflated during "poker planning" for this reason. That would be bad.
This is an interesting idea. I'm guessing that it would work best on team that is already gelled and who enjoy a little friendly rivalry. Please keep us posted on how it goes - I'm always looking for interesting ways to spur on our testing team.
I've got a couple of questions and a suggestion:
1. Are there any ways that testers can lose the Bug Bucks?
2. Is there any worry that features by developers have no bucks left will receive less testing?
and
A. Perhaps consider some sort of team reward of bucks for a release done well: post-release/customer reported bugs could be a metric, as could releasing ontime/onbudget.
Long, long ago it was a team in Motorola where the managers decided to "pay real money" for bugs. The idea was in Dilbert within days!
I jumped in and in short time I could easily determine which feature was the weakest (and not only because of the developers working on it or because its complexity). I went for the weakest feature out of the ones I new the most. I was close to make a fortune! (In Dilbert one character was saying: "I will write myself a new minivan!".)
They stop in time! (the managers and Dilbert's characters)
Money (real or faked) do motivate people (even testers and developers) but the results of their (this way motivated) activities may not be what we want. I don't say is not fun, I say it can be more fun and less software quality. Play, but be careful!
Hi Eric,
I was wondering if your team went on with that game and how it turned out. Would you update us?
Btw, great blog, your posts are usually inspiring and thought provoking. Keep up the great work!