Should the Best Scrum Team Be Rewarded?

Rajesh Velliyatt asked whether his management idea to create a  “Best Scrum Team of the Quarter” is good or bad. He was concerned about the potential downsides of the award system:

• Subjective ( like any other such system ) 
• If all teams are doing well (or even otherwise), picking one among them can pull other teams down
• May work against collaboration across teams
• Too much overhead (data collection) to substantiate "we are best of the pack" to the panel (for the scrum master?)
• Different product teams, no apple-to-apple comparison

In addition to the Rajesh’s point this reporter suggested that the competition was likely to be unhealthy. He also made the point that for creative tasks Dan Pink, author of Drive, has shown that while rewards work for mechanical tasks, for creative activities such as software development they don’t help. Rather than an external motivation, Pink explains that an intrinsic one is what improves productivity on a creative task. Michael James provided a reference from Dan Ariley: “In eight of the nine tasks we examined across the three experiments, higher incentives led to worse performance. In fact, we were surprised by the robustness of the effect;” -  Dan Ariely, Uri Gneezy, George Loewenstein, and Nina Mazar (2005) “Large Stakes and Big Mistakes” Working Papers No. 5-011, Federal Reserve Bank of Boston.

Steve Janvrin asked his Scrum team what they would think: "how would you feel if there were multiple Scrum teams and you didn't win the award?"  Their answer was "we'd be mad at them and wouldn't want to work with them."

Paul Tiseo suggests that instead of a top team award make it something that all teams can strive for. He points out that a single reward means splitting hairs over which team did best. In this spirit, Rajesh suggested some measures:

1. Velocity trend of the team (Assumption: team is consistent with point estimation, *could be* influenced by the reward system?)

2. Sprint execution effectiveness (Burn down chart, Impediments raised and How the team dealt with impediments) 

3. Adherence to DoD (Data comes from PO) 

4. Commitment/attitude of the team towards Scrum process (Data comes from SM)

This reporter pointed out that all of these measures, especially velocity (For more details: Misuse of Velocity of an Agile Project), can be gamed. In general any measure will invite the to work towards it, so we must consider what happens if the team does too much of this thing.

Jay Conne offered a market driven alternative: “Let business units bid on the teams they want to do their projects? That would cover many dimensions in one fell swoop. And as a balancing factor, have the teams bid on the projects. That would demonstrate earned trust both ways.”

Bachan Anand, has experience running this “healthy” competition between teams. He found that in the short term it became very unhealthy, teams started working in silos and not collaborating with other teams working on the same product. But Bachan’s organization found that coaching and mentoring sessions that involve people from more than one team helped improve collaboration.