BT

Os melhores times de Scrum devem ser recompensados?

por Mark Levison , traduzido por Pedro Mariano em 25 Ago 2010 |

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:

  1. Velocidade média do time (o time é consistente com os pontos que foram votados, isso pode ser influênciado pela premiação?)
  2. Efetividade na execução do Sprint (Gráfico de burn down, impedimentos removidos e como o time lida com tais impedimentos)
  3. Aderência do DefinitionOfDone (definição de pronto) -  Esses dados devem vir do PO
  4. 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.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT