Agile MVP (Most Valuable Player/Programmer)

Question

Recently I've been involved in an agile project (using scrum) where management came up with the idea that the team would nominate a developer 'MVP' as well as a QA 'MVP' at the end of each sprint, voted on by the team. The MVP then gets a small monetary reward and free lunch as well as a trophy to display on his desk. We've had two sprints so far with this reward system in place.

The good I see from this is the following:

• More bugs have been fixed (which is what upper management wants to see, a number change in the direction they want)
• The MVP from each 'team' gets recognized and gets a self esteem boost (or is it an ego boost?)

I've noticed a few what I would consider bad sides to doing such a thing (at least from a developer standpoint):

• There are a few developers who are so concerned with the number that the quality of bug fixes has gone down. Fixes in one area are causing regressions in another.
• There are a few developers who are cherry picking 'easier/quicker' bugs to boost their bug count. Could be good of bad here I guess.
• Higher priority (which a lot of the time correlates to 'harder/longer to fix') defects actually become lower priority.
• Blocking defects are not addressed in a timely manner, as usually they take longer and require more coordination with QA.
• The team aspect within the Dev team has been lost. The team aspect of Dev and QA working together as one hasn't improved either, but hasn't really changed too much from before.
• Work beyond bug fixes, or working towards THAT number, isn't easily recognizable/tracked.

I do believe that each of the 'bad' above can be addressed to some degree, depending on how the team handles each.

My question is, then, has anyone successfully pulled anything like this off, where you recognize an MVP per sprint? If so, what do you think contributed to that success?

Answer 1

Agile emphasizes team effort, not the effort of individuals. So no, this approach is clearly not agile.

Rather than encourage team collaboration, this encourages each team members to focus on his own result. It can even lead to members avoiding helping each other (or worse), which in the long run will stop the team from getting better.

I suggest rewarding the team as a whole if they did a good job.

Answer 2

I think it's a good example of -bad- gamification being applied. The problem is that your programmers potentially had intrinsic motivation in solving problems and winning though challenges (finding and fixing hard bugs) AND, since you've implemented Scrum, in working as a TEAM. In other words, they potentially wanted to do a good job.

Now, at least for some of them, this intrinsic motivation or part of it has been replaced with extrinsinc motivation consisting in titles ("MVP of the week") and rewards (monetary amount, and free lunch), which are game mechanics often part of a gamified process.

Gamification can be applied successfully at work but you have to be very careful in leveraging intrinsic/extrinsic motivation. Extrinsic motivation has to power to fuel self-determination in order for the motivation to become intrinsic. However what happened here is the reverse, programmers are "gaming the game" in order to win.

What you could do to fix this is to ask the management to change the rules a bit:

• give points matching the difficulty and priority of the tickets. Make it so that it is much more interesting, points-wise, to fix a hard to find/reproduce bug.
• give points for solving problems cooperatively (again, the TEAM). This is where you could get more programmers to interact with the QA. Give points for a problem being solved cooperatively by a programmer AND a QA for example.
• give different titles, one for the most points, and one for the most tickets. This should satisfy the competitive instincts of the programmers.
• possibily establish a friendly competition between the Dev and the QA by summing up points of every member of a team

Reducing the possibility of regression bugs appearing however is another problem. You could for example apply negative points, but I'm sure it's not a good idea since it would be a form of punishment. What would be better perhaps is to automatically start a sprint with a few points if no regression bug has been detected in the past week. If regression bugs have been detected, the programmer starts with 0.

Also, in "gamification" there is "game". And the fundamental aspect of a game is that you play/participate voluntarily. In the context of work, it may be imposed by the management which is the case here, but normally no one should be forced into this.

To conclude, this MVP thing is not necessarily a bad idea, but the approach could be changed a little bit to make business (solving important bugs) come first, and emphasize teamwork rather than individuals.

Answer 3

Some sort of group recognition of the efforts of a team member can be a valuable motivator, but in this case it sounds like it's being misapplied. You state that the MVP is chosen by vote, but there's a lot of mentions of numbers of bugs fixed per sprint. It sounds like your time has a funny definition of MVP - I would assume that the person who deserves the title of "most valuable" is the person who added most value to the software in that sprint. If a team member is picking out bugs that can be fixed quickly, blasting through them as fast as possible, and causing regression bugs and other problems in their wake, then they're not adding value, they're creating more work for whoever has to follow them around identifying and fixing those problems.

My suggestion would be to try to start a proper discussion the next time your team has one of these votes. Don't just make it a show of hands; talk it through first. If someone seems to be gaining votes based on the sheer number of "fixes" they've made, point out (tactfully) where those fixes caused regressions, and suggest that perhaps the person who fixed those regressions should be nominated for cleaning up other people's mess. If someone spent the whole sprint slaving away on one nasty issue, point that out to the team, highlighting the fact that although this person's fix count is one, they've single-handedly solved a major problem with your software - a problem that was so nasty that nobody else wanted to touch it.

Picking out easy fixes and doing them in a rushed or haphazard manner isn't valuable, so developers who just do that probably shouldn't qualify as MVP candidates. When selecting the new MVP, forget all about the team and the people on it, and look at the software. Pick out the single most important change in that software since the last time. I mean single here; "not as many tiny bugs" is not a major change. Has a particularly glaring bug been fixed? Has a great new feature been added? Once you've identified what this one big change is, ask who was responsible for it. One of those people is probably your actual MVP. If "not as many tiny bugs" is the only difference, then and only then is bug count a valid measure of MVP - and even then, I'd look at ratio of bugs fixed to regression bugs caused. Every bug someone causes deducts at least 1 from their count. In fact, I'd say more than 1, because a bad fix will cause an unknown bug that you then have to find, which is worse than a known bug that's been found already. A known bug takes developer effort to fix; an unknown bug takes QA effort to find, and developer effort to fix, and then there's the risk that QA will miss it.

In theory, if developers realise that the way to the prize is to fix fewer, bigger problems, they'll aim for the tough ones, the complex ones, the blocking defects. This will require them to band together sometimes, either because there aren't enough meaty problems to go around, or because the problem is tricky enough to require more sets of eyes. Perhaps suggest that in cases like this, the award could be shared if it's not immediately clear which of a set of people did more work towards fixing a bug - and remember, work done != lines of code written. The developers will probably know that, but you said management is involved, and management don't always understand that point.

And hey, if all else fails, forget the MVP program. Talk to your fellow developers outside of the scrums, and point out the negative impact that the MVP awards are having on the software. See if you can get them to ignore it, or not make it such a big deal. Leave the trophy in a drawer, spend the cash prize on a round of drinks for the team after work, use the free lunch to get something you can share, like a bunch of cupcakes. Agile is a team system; highlighting individual performance risks pitting the team against each other. United you stand, divided you ship bug-filled software, after the deadline, over-budget.

Answer 4

This is a classic example of how a specific practice (public recognition as MVP) can have a significant yet indirect impact in how your team behaves. This goes beyond incentives, motivations, and rewards and actually touches on ideas in environmental/behavioral psychology and decision architecture. Cool stuff.

The question is -- how can you design a process so that your team just seems to do all the right things naturally, without having to put in place rigid policies or forcing people to do something?

I've written about using affordances (in the tradition of Donald Norman's Design of Everyday Things) for processes as a mechanism for designing a process that works for your team. The basic idea is that the practices in a process directly influence a person's behavior. As such, problems arise when the affordances in your process are not fully aligned with your team's values.

I've run several workshops on this topic and this particular issue comes up as an example in groups from time to time. Applying the theory of affordances to the case you shared in your question might look something like this.....

Assume your team values consistency, predictability, and high quality code.

You've got a laundry list of negative behaviors that you have observed and they all seem to stem from using defect metrics to pick a team MVP. For example, teammates seem to naturally want to haphazardly pick and fix bugs, negatively impacting all three of your values. (I'm assuming that there was a problem before too, and this is what led to the MVP idea).

Rather than having a single MVP based on defect metrics, we will try to change team behavior by making some small, but significant changes.

• Let anyone give a "team kudo" to any (and all, not just one) individuals who demonstrably embrace your team values. This will promote predictability be democratizing the team value system through examples. (We actually do this on our team..)
• Start pair programming (or assign "bug buddies") for all bug fixing. This will promote quality by discouraging hasty or half-assed programming decisions and encourage consistency because buddies will temper erratic behavior. (This idea is commonly suggested during the workshops, seems intuitive..)

And these are just some examples to demonstrate the approach and get you started...

What's great about this approach is that you are actively designing your process changes and have justifiable reasons for the process changes you make. Just like in object or UI design, you can even measure outcomes to understand if things are working or not.

Answer 5

One of the easiest adjustments to make to ensure something like an MVP program works is to reward team members for being the most valuable to the team's success, not being the hardest worker.

We've done this successfully by recognizing people who didn't even work on bugs, or features, but did something awesome that made everybody on the team succeed better. For example, we had one developer who took on the task of mentoring a bunch of new members to the team so they could learn the architecture and how we worked. Our velocity jumped up because we had these new recruits able to deliver results quickly and efficiently, even though individually that one developer's velocity went down because he was spending more time on helping the rest of the team.

Reward teamwork, and the team will notice that it's the TEAM that matters, not their own personal success.