This could work for small teams, where there is great mutual respect, and a cultivated atmosphere of learning and collaboration. However, in my experience, bot

This could work for small teams, where there is great mutual respect, and a cultivated atmosphere of learning and collaboration. However, in my experience, both for software development and quality assurance (which shouldn't be separated, but generally are...), this state is not generally the case. As such, metrics tracking and acknowledgement always seem like a good idea - but never are. Inevitably productivity will seem to skyrocket for the early trial period of awards (or any metrics-based system), until the ass-kissers and numbers-experts figure out how to game the system. Then you have people over-documenting bugs, using multiple VCS commits to "fix" minor text updates (because "they occur in different areas of the code", or something equally ridiculous), and similarly wasting time and efforts just to unlock an achievement. Once this starts occurring, the same people always carry the same prize (badge, whatever), and work ethic and motivation reverts to a state that is probably less satisfying for the team than it was prior to the achievement-based system. Also, your code maintenance and issue trackers are riddled with pointless records, making troubleshooting, reporting (other than for your achievements), and code reverts require a painstaking effort. If you have a team that collaborates well enough to keep something like this from having detrimental effects - don't waste your time. Your team is already more productive than most.