We have recently started with “Developer of the month” across scrum teams. We announce name of the top performer along with each monthly celebration.
What could be the potential down side of doing it as Scrum encourages team performance.
There isn't anything inherently wrong with the idea, but there are some places that you may find problematic. This isn't really a scrum problem, but Scrum can exacerbate the problems.
Some problems include:
What am I measuring? Any measurement will tell people that you value that thing over others, but is that the message you want to send? Things like collaboration, mentoring, architectural maintainability, and quality are notoriously difficult to measure, so metrics almost always favor short-changing these areas.
Who am I measuring? Scrum encourages teams to succeed or fail together and often times calls for multiple people to swarm on work. How do you measure this work separately? Will you be separating work that should be together just to gain a measurement?
How do you measure value and learning? Scrum puts a lot of emphasis on driving out risk through learning and creating value. Even if you were to measure on the team level, how will you compare the amount one team learned against another? In short, what is performance?
That is not to say that nothing like this can work. I worked in one department where the teams nominated an MVP each month and in the course of the month, there was usually someone who stood out as having really pulled more than their weight.
It's also important to remember how much Agile stresses sustainable pace. People working nights and weekends has a massive cost to it that is often hidden. You don't want to accidentally encourage cowboy heroics for a monthly reward by sacrificing the long-term health of your teams.
Good agile teams don't need carrots and they don't need sticks. Whoever came up with that idea is probably the problem. Instead of trying to create a hero culture where people continuously burn out and leave, think more about how to provide resources and enable teams to solve complicated engineering problems. Do that and you don't need sticks or carrots :)
I don’t think there’s a particular issue with giving praise to individual members, you just need to make sure it’s focused on how that action has benefited the team.
Great time to do this is in retrospectives when you discuss what went well. It’s healthier when people in the team feel comfortable giving praise, as opposed to it always coming from one person