Rajesh Veliyatt perguntou se a sua idéia de criar o prêmio de "Melhor Time Scrum do Semestre" é boa ou ruim. Ele estava preocupado com os possíveis problemas que esse sistema poderia trazer:
- Subjetividade (igual qualquer outro sistema parecido)
- Se todos os times estiverem indo bem, escolher um entre eles pode fazer com que os outros times percam a produtividade.
- Alguns times podem começar a trabalhar contra o outro
- Os times podem começar a realizar um "overhead" do quadro com o intuito de provar que são melhores
- Produtos são diferentes, não é igual uma comparação apple-com-apple.
Complementando a idéia de Rajesh eu sugeri que uma competição tem chances de não ser saudável. Também citei o ponto de Dan Pink, autor do Drive, onde ele mostra que o sistema de recompensas só funciona para atividades mecânicas, para atividades criativas como o desenvolvimento de software o sistema não ajuda. Além da motivação externa, Pink diz que uma motivação intrínseca pode contribuir com a produtividade em tarefas criativas. Em complemento Michael James citou Dan Ariley:
"Em oito das nove tarefas que nós examinamos em três testes, grandes incentivos levaram a uma pior performance. De fato, nós fomos surpreendidos pela robustes do efeito" - Dan Ariely, Uri Gneezy, George Loewenstein, e Nina Mazar (2005) “Large Stakes e Big Mistakes” Working Papers No. 5-011, Federal Reserve Bank of Boston.
Steve Janvrin fez uma pergunta ao seu time Scrum: "como vocês se sentiriam se tivessemos diversos times de Scrum e vocês não ganhassem o prêmio?". A resposta foi "nós ficariamos nervosos com isso e não iriamos querer trabalhar com eles" .
Paul Tiseo sugeriu que ao invés de possuir um prêmio para a melhor equipe, criar uma competição onde onde todos os times podem lutar. Ele enfatiza que, nesse caso, um único prêmio significa considerar diversos pontos que a equipe se deu bem. Com esse pensamento, Rajesh sugeriu algumas formas de medição:
- Velocidade média do time (o time é consistente com os pontos que foram votados, isso pode ser influênciado pela premiação?)
- Efetividade na execução do Sprint (Gráfico de burn down, impedimentos removidos e como o time lida com tais impedimentos)
- Aderência do DefinitionOfDone (definição de pronto) - Esses dados devem vir do PO
- Comprometimento/atitude do time em relação ao Scrum - Esses dados devem vir do SM
Todas as medidas, especialmente velocidade (Para mais detalhes: Misuse of Velocity of an Agile Project), podem ser utilizadas em forma de jogo. Em geral qualquer medida irá nos convidar a trabalhar em torno dela, então nós devemos ter em mente o que irá acontecer se o trabalho se concentrar de forma excessiva nessas medidas.
Bachan Anand, possui experiência com competições "saudáveis" entre times. Ele descobriu que no curto prazo as coisas não são saudáveis, os times começam a trabalhar em silos e não colaboram com os outros times, mesmo que trabalhem no mesmo produto. Mas a empresa de Bachan descobriu que sessões de coaching e mentoring envolvendo integrantes de diversos times pode melhorar a colaboração.