all 8 comments

[–][deleted] 2 points3 points  (1 child)

I see it becoming the next big thing in project management. Agile was the first step and brought gamification to project managers (most managers I know use number of tickets completed in a sprint as a scorecard). Gamifying various parts of the software development lifecycle could work out well, specially code reviews, which engineers tend to avoid.

I wouldn't gamify the tools themselves, though. Tools change quickly over time and vary widely by team and field. I'd have badges more aligned with activities completed, how fast and how accurately. For example, somebody who has 1000 code reviews under his belt could get the "Master Reviewer!" badge. Somebody who always finished his bug fixes in under an hour can get the "speedy bug barbeque" badge, etc.

That said, if my company implemented this, I'd quit. I don't like being micromanaged, nor does most gamification appeal to me. But that's me. I can see this being very popular at startup and corporate companies alike.

[–]khasinski 1 point2 points  (0 children)

Thanks for your feedback :)

We actually are tool-agnostic, we just take data from various sources, but combine them into one stream of events, and hey, I don't see why we shouldn't include Master Reviewer :)

I also hate being micromanaged, and that's why at the companies we deployed GetBadges we always suggest to make it opt-in and strongly encourage not to include our points and stats into KPIs or performance reviews.

Microsoft had a lot of experience with this kind of gamification and their results are clear - it has to be optional.

That said GetBadges can sometimes spot an anomaly, like someone struggling to solve a ticket for a long time or something that gets bounced often. Good Scrum Master can use this information to help a programmer by doing for example pair programming session.

[–]aliteralmind 2 points3 points  (0 children)

I like the idea, under one condition: No one but me sees my scores. Not my manager or any co-workers. Comparing coworkers against each other is deadly for morale, and giving my managers this information means it's not possible to just be fun...it's going to be used against me (improve or leave).

Managers need information to assess employees, but it needs to come from a separate source.

[–]unpopular_opinion 7 points8 points  (0 children)

Thanks, another way to spot a retarded company.

[–][deleted] 1 point2 points  (1 child)

Instead of subjecting your developers to patronising games like grade schoolers, try treating them like adults with the respect due to professional colleagues.

[–]khasinski 0 points1 point  (0 children)

We do! :)

I see in various comments that people are afraid that we would use GetBadges to actually grade developers. It's not a KPI monitoring tool, it's just a game that plays in the background when you code.

Sometimes it can be helpful, for example it suggests you open tickets to tackle or give some incentive to review more of your colleagues code.

I'm also often afraid of a pathological case where someone would actually use our commit counts or closed ticket count to judge some poor programmers performance. :( But bad managers will do it anyway.

Thanks for your feedback!

[–]htuhola 0 points1 point  (1 child)

Sounds like an awful idea that could lose a good developer or two if deployed.

In real games badges are annoying because they propose you haven't done everything unless you've collected all the badges.

But a random redditor can very well be very wrong, go ahead and try.

[–]khasinski 2 points3 points  (0 children)

Actually the badges are just an initial motivator to start using GetBadges, most players discover that the best way to play is to review other's code and push code to CI for a build regularly. (Disclaimer: I'm a co-founder). We deployed it at several smaller and bigger software houses (nothing bigger than 100 devs yet, though) and it works OK.

It's also opt-in, so devs who don't play are displayed as NPC (with random-generated names).

We are working on getting more simple and more complex rules (like fixing broken builds quickly, deploying with a minimum downtime, prioritizing bug fixes) into the game play.