MVP ágil (jogador / programador mais valioso)

Recentemente, estive envolvido em um projeto ágil (usando scrum) em que a gerência teve a ideia de que a equipe nomeasse um desenvolvedor 'MVP' e um QA 'MVP' no final de cada sprint, votado pelo equipe. O MVP recebe uma pequena recompensa monetária e almoço grátis, além de um troféu para exibir em sua mesa. Até agora, tivemos dois sprints com esse sistema de recompensa em vigor.

O bom que vejo disso é o seguinte:

• Mais bugs foram corrigidos (que é o que a alta gerência quer ver, um número muda na direção que eles querem)
• O MVP de cada 'equipe' é reconhecido e ganha um impulso na auto-estima (ou é um impulso no ego?)

Percebi alguns aspectos que consideraria ruins em fazer uma coisa dessas (pelo menos do ponto de vista do desenvolvedor):

• Alguns desenvolvedores estão tão preocupados com o número que a qualidade das correções caiu. Correções em uma área estão causando regressões em outra.
• Existem alguns desenvolvedores que estão escolhendo os bugs 'mais fáceis / mais rápidos' para aumentar sua contagem de erros. Poderia ser bom ou ruim aqui, eu acho.
• De prioridade mais alta (que na maioria das vezes se correlaciona com 'mais difícil / mais tempo para corrigir') os defeitos tornam-se, na verdade, prioridade mais baixa.
• Os defeitos de bloqueio não são resolvidos em tempo hábil, pois geralmente levam mais tempo e exigem mais coordenação com o controle de qualidade.
• O aspecto da equipe dentro da equipe de desenvolvimento foi perdido. O aspecto de equipe do Dev e do QA trabalhando juntos como um também não melhorou, mas na verdade não mudou muito antes.
• O trabalho além das correções de bugs ou o trabalho para esse número não é facilmente reconhecível / rastreado.

Eu acredito que cada um dos 'maus' acima pode ser tratado até certo ponto, dependendo de como a equipe lida com cada um.

Minha pergunta é, então, alguém conseguiu com êxito algo assim, onde você reconhece um MVP por sprint? Se sim, o que você acha que contribuiu para esse sucesso?

O Agile enfatiza o esforço da equipe , não o esforço dos indivíduos. Portanto, não, essa abordagem claramente não é ágil.

Em vez de incentivar a colaboração da equipe, isso incentiva cada membro da equipe a se concentrar em seu próprio resultado. Pode até levar os membros a evitar ajudar uns aos outros (ou pior), o que a longo prazo impedirá que a equipe melhore.

Sugiro recompensar a equipe como um todo se eles fizeram um bom trabalho.

Eu acho que é um bom exemplo de gamificação sendo aplicada. O problema é que seus programadores potencialmente tinham motivação intrínseca para solucionar problemas e vencer desafios (encontrar e corrigir bugs) E, desde que você implementou o Scrum, ao trabalhar como EQUIPE. Em outras palavras, eles potencialmente queriam fazer um bom trabalho.

Agora, pelo menos para alguns deles, essa motivação intrínseca ou parte dela foi substituída por motivação extrínseca que consiste em títulos ("MVP da semana") e recompensas (valor monetário e almoço grátis), que geralmente são parte da mecânica de jogos de um processo gamificado.

A gamificação pode ser aplicada com sucesso no trabalho, mas você deve ter muito cuidado ao alavancar a motivação intrínseca / extrínseca. A motivação extrínseca tem que poder alimentar a autodeterminação para que a motivação se torne intrínseca. No entanto, o que aconteceu aqui é o inverso, os programadores estão "jogando o jogo" para vencer .

O que você pode fazer para corrigir isso é solicitar à gerência que altere um pouco as regras:

• dê pontos correspondentes à dificuldade e prioridade dos ingressos. Faça com que seja muito mais interessante, em termos de pontos, corrigir um erro difícil de encontrar / reproduzir.
• dar pontos para resolver problemas de forma cooperativa (novamente, a EQUIPE). É aqui que você pode obter mais programadores para interagir com o controle de qualidade. Dê pontos para um problema que está sendo resolvido cooperativamente por um programador E um QA, por exemplo.
• dê títulos diferentes, um para mais pontos e um para mais ingressos. Isso deve satisfazer os instintos competitivos dos programadores.
• Possivelmente estabelecer uma competição amigável entre o desenvolvedor e o controle de qualidade, somando pontos de todos os membros de uma equipe

Reduzir a possibilidade de erros de regressão aparecerem, no entanto, é outro problema. Você poderia, por exemplo, aplicar pontos negativos, mas tenho certeza de que não é uma boa ideia, pois seria uma forma de punição. Talvez o melhor seja iniciar automaticamente um sprint com alguns pontos se nenhum erro de regressão tiver sido detectado na semana passada. Se erros de regressão foram detectados, o programador começa com 0.

Além disso, em "gamification" existe "game". E o aspecto fundamental de um jogo é que você joga / participa voluntariamente. No contexto do trabalho, pode ser imposto pela gerência, como é o caso aqui, mas normalmente ninguém deve ser forçado a isso.

Para concluir, essa coisa do MVP não é necessariamente uma má idéia, mas a abordagem pode ser um pouco alterada para fazer os negócios (solucionar bugs importantes) virem primeiro e enfatizar o trabalho em equipe e não os indivíduos.

Algum tipo de reconhecimento de grupo dos esforços de um membro da equipe pode ser um motivador valioso, mas, neste caso, parece que está sendo mal aplicado. Você afirma que o MVP é escolhido por votação, mas há muitas menções ao número de erros corrigidos por sprint. Parece que seu tempo tem uma definição engraçada de MVP - eu suporia que a pessoa que merece o título de "mais valioso" é a pessoa que agregou mais valor ao software nesse sprint. Se um membro da equipe estiver escolhendo bugs que podem ser corrigidos rapidamente, detectando-os o mais rápido possível e causando bugs de regressão e outros problemas, então eles não estão agregando valor, estão criando mais trabalho para quem quer que tenha para segui-los na identificação e correção desses problemas.

Minha sugestão seria tentar iniciar uma discussão adequada na próxima vez que sua equipe tiver um desses votos. Não faça apenas um show de mãos; fale primeiro. Se alguém parece estar ganhando votos com base no grande número de "correções" que fez, indique (com tato) onde essas correções causaram regressões e sugira que talvez a pessoa que as corrigiu deva ser indicada para limpar outras pessoas. bagunça. Se alguém gastou todo o sprint se esquivando de uma questão desagradável, aponte para a equipe, destacando o fato de que, embora a contagem de correções dessa pessoa seja uma, eles resolveram sozinho um grande problema com o seu software - um problema que era tão desagradável que ninguém mais queria tocá-lo.

Escolher correções fáceis e fazê-las de maneira apressada ou aleatória não é valioso; portanto, os desenvolvedores que fazem isso provavelmente não devem se qualificar como candidatos a MVP. Ao selecionar o novo MVP, esqueça tudo sobre a equipe e as pessoas que estão nele e observe o software. Escolha a mudança mais importante nesse software desde a última vez. Quero dizer solteiro aqui; "não tantos pequenos insetos" não é uma grande mudança. Um bug particularmente flagrante foi corrigido? Foi adicionado um ótimo novo recurso? Depois de identificar qual é essa grande mudança, pergunte quem foi responsável por ela. Uma dessas pessoas é provavelmente o seu MVP atual. Se "não há tantos pequenos insetos" é a única diferença, então e somenteentão, a contagem de bugs é uma medida válida do MVP - e, mesmo assim, verificaria a proporção de bugs corrigidos por bugs de regressão causados. Todo bug causado por alguém deduz pelo menos 1 da sua contagem. Na verdade, eu diria mais de 1, porque uma correção incorreta causará um bug desconhecido que você precisará encontrar, o que é pior do que um bug conhecido que já foi encontrado. Um bug conhecido requer esforço do desenvolvedor para corrigir; um bug desconhecido exige esforço de controle de qualidade para ser encontrado, e esforço do desenvolvedor para corrigi-lo e, então, há o risco de que o controle de qualidade perca esse controle.

Em teoria, se os desenvolvedores perceberem que o caminho para o prêmio é resolver menos problemas maiores, eles procurarão os difíceis, os complexos, os defeitos de bloqueio. Isso exigirá que eles se unam às vezes, ou porque não há problemas de carne suficientes para circular, ou porque o problema é complicado o suficiente para exigir mais olhares . Talvez sugira que, em casos como esse, o prêmio possa ser compartilhado se não for claro imediatamente qual grupo de pessoas trabalhou mais para corrigir um bug - e lembre-se, trabalho realizado! = Linhas de código escritas. Os desenvolvedores provavelmente saberão disso, mas você disse que o gerenciamento está envolvido e que o gerenciamento nem sempre entende esse ponto.

E, ei, se tudo mais falhar, esqueça o programa MVP. Converse com seus colegas desenvolvedores fora dos scrums e aponte o impacto negativo que os prêmios MVP estão tendo no software. Veja se você pode fazer com que eles o ignorem, ou não faça disso um grande negócio. Deixe o troféu em uma gaveta, gaste o prêmio em dinheiro em uma rodada de bebidas para a equipe depois do trabalho, use o almoço gratuito para obter algo que você possa compartilhar, como um monte de cupcakes. Agile é um sistema de equipe; destacando os riscos individuais de desempenho, colocando a equipe um contra o outro. Unidos você está, dividido você envia software cheio de bugs, após o prazo final, excede o orçamento.

Este é um exemplo clássico de como uma prática específica (reconhecimento público como MVP) pode ter um impacto significativo, mas indireto, no comportamento de sua equipe. Isso vai além de incentivos, motivações e recompensas e, na verdade, toca em idéias na psicologia ambiental / comportamental e na arquitetura de decisão. Coisas legais.

A questão é: como você pode projetar um processo para que sua equipe pareça fazer as coisas certas naturalmente, sem ter que implementar políticas rígidas ou forçar as pessoas a fazer alguma coisa?

Eu escrevi sobre o uso de recursos (na tradição do Design de coisas cotidianas de Donald Norman ) para processos como um mecanismo para projetar um processo que funcione para sua equipe. A idéia básica é que as práticas em um processo influenciam diretamente o comportamento de uma pessoa. Como tal, surgem problemas quando as disponibilidades do seu processo não estão totalmente alinhadas com os valores da sua equipe.

Realizei vários workshops sobre esse tópico e esse problema em particular surge como um exemplo em grupos de tempos em tempos. A aplicação da teoria das possibilidades ao caso que você compartilhou em sua pergunta pode ser algo como isto .....

Suponha que sua equipe valorize consistência, previsibilidade e código de alta qualidade.

Você tem uma lista de comportamentos negativos que observou e todos parecem resultar do uso de métricas de defeitos para escolher um MVP de equipe. Por exemplo, os colegas de equipe parecem querer naturalmente escolher e corrigir erros aleatoriamente, afetando negativamente os três valores. (Estou assumindo que também havia um problema antes, e foi isso que levou à ideia do MVP).

Em vez de ter um único MVP baseado em métricas de defeitos, tentaremos mudar o comportamento da equipe fazendo algumas mudanças pequenas, mas significativas.

• Deixe alguém dar um "kudo da equipe" a todos (e todos, e não apenas um) indivíduo que demonstrem abraçar os valores da sua equipe. Isso promoverá a previsibilidade democratizando o sistema de valores da equipe por meio de exemplos. (Na verdade, fazemos isso em nossa equipe ..)
• Inicie a programação em pares (ou atribua "amigos de bugs") para toda a correção de bugs. Isso promoverá a qualidade, desencorajando decisões de programação apressadas ou meia-boca e incentivará a consistência, porque os amigos temperarão o comportamento irregular. (Essa ideia é comumente sugerida durante os workshops, parece intuitiva ..)

E estes são apenas alguns exemplos para demonstrar a abordagem e começar ...

O que há de bom nessa abordagem é que você está projetando ativamente as alterações do processo e tem motivos justificáveis ​​para as alterações feitas no processo. Assim como no objeto ou no design da interface do usuário, você pode até medir os resultados para entender se as coisas estão funcionando ou não.

Um dos ajustes mais fáceis de fazer para garantir que algo como um programa MVP funcione é recompensar os membros da equipe por serem os mais valiosos para o sucesso da equipe, não por serem os trabalhadores mais esforçados.

Fizemos isso com sucesso, reconhecendo pessoas que nem sequer trabalhavam com bugs ou recursos, mas fizemos algo incrível que fez com que todos da equipe tivessem sucesso. Por exemplo, tivemos um desenvolvedor que assumiu a tarefa de orientar vários membros novos para a equipe, para que eles aprendessem a arquitetura e como trabalhamos. Nossa velocidade aumentou porque tínhamos esses novos recrutas capazes de fornecer resultados com rapidez e eficiência, embora individualmente a velocidade de um desenvolvedor tenha diminuído porque ele estava gastando mais tempo ajudando o restante da equipe.

Recompense o trabalho em equipe e a equipe notará que é a EQUIPE que importa, não o sucesso pessoal deles.