Scrum: Lidando com a falta de motivação

De acordo com isso , "o Scrum depende muito de equipes altamente motivadas, colaboradoras, multifuncionais e auto-organizadas". Então, como você lida com colegas de trabalho que podem não estar tão motivados para se apropriar do código? Como você atrai alguém interessado em se apropriar?

Não sei se esse é o problema da sua equipe, mas definitivamente foi para nós quando introduzimos o scrum pela primeira vez. Nossa gerência veio até nós um dia e disse: a partir de agora você não estará trabalhando em silos individuais. Em vez disso, você estará trabalhando como scrum. Aqui estão alguns processos novos que você deve seguir e seguir.

A chave é que eles nunca vieram até nós, os desenvolvedores, e perguntaram: como vocês querem trabalhar? o que vai fazer você mais feliz? mais eficiente?. Então, o que ouvi foi: "você não possui mais nenhum código. Qualquer coisa que você escrever será atropelado (você sabe, propriedade da equipe). Você não moverá nem levantará um dedo porque agora gerenciaremos seu tempo a cada hora". Ah, e agora você tem um stand de 15 minutos chato todos os dias, onde as pessoas discutem coisas das quais você não se importa e geralmente leva 30 minutos e, a cada duas semanas, uma reunião de planejamento de 4 horas é chata e com certeza é péssima. toda a vida fora de você.

Na realidade, isso não é Agile ou Scrum, está apenas passando de um estilo de gerenciamento para um estilo diferente, onde tudo ainda é controlado centralmente, e isso não apenas sugou toda a minha vida, mas também me proporcionou muita liberdade. hora de atualizar meu currículo.

Nos últimos doze meses, depois de fazer lobby várias vezes para o gerente da equipe tentar algo diferente, ele aceitou minhas sugestões e acho que tivemos um ano de muito sucesso.

Acredito que a principal mudança para nós foi dar aos desenvolvedores muito mais voz e liberdade na escolha de como queremos trabalhar. Poucas coisas que fizemos:

1. Divida a grande equipe de desenvolvimento "ágil" em três pequenas, para que cada uma tenha apenas 3-4 desenvolvedores. Isso faz com que todos se envolvam e os indivíduos não sejam abafados.
2. Certifique-se de que todos da mesma equipe trabalhem em torno da mesma área funcional, para que as pessoas se importem com o que os outros estão falando em stand-ups e planejamentos de iteração.
3. Em vez de a gerência simplesmente escolher quem trabalha com o quê e atribuir histórias / tarefas, criamos uma lista de pendências e a própria equipe tem muito a dizer sobre como o trabalho é dividido.
4. Como tínhamos muitos membros novos, começamos com um sistema de silos em que cada pessoa possui uma área de responsabilidade primária. Isso permitiu que as novas pessoas se concentrassem na área menor de um produto desconhecido e também tivessem uma sensação mais rápida de que não estavam brincando na caixa de areia de outra pessoa. Porém, após 6-8 meses de programa, essas áreas começaram a se transformar à medida que os limites se tornaram mais cinzentos. Agora, os caras, nas equipes em que faço parte, estão bastante confortáveis ​​em adotar o código de outros ou fazer com que outros desenvolvedores trabalhem com os deles.
5. Revisões de código de todos os envios foram essenciais (e essa foi a primeira coisa que foi esquecida quando fizemos o Scrum):
   • Transferência de conhecimento em termos de técnicas / métodos de programação
   • Foi ótimo para outras pessoas aprenderem código que não teriam visto de outra forma
   • Sua equipe tem a chance de se comunicar e socializar, o que melhora a dinâmica da equipe
   • E eu acho que as revisões de código detectarão um bug ou dois, mas eu vejo o seu valor principalmente nos aspectos acima.
6. A gerência tem que ouvir a equipe. Se a equipe disser que algo não funciona ou precisa ser mudado, e eles simplesmente ignoram isso, os membros da equipe simplesmente fazem check-out e deixam a gerência lidar com o projeto. Se você deseja que as pessoas sejam motivadas, elas precisam ser investidas e só serão investidas se estiverem fazendo o que acreditam ser certo, e não o que lhes é pedido que façam de cima para baixo.

Existem muitas razões para a falta de motivação, mas provavelmente o mais comum é não sentir que você tem uma palavra a dizer. Quando nossa equipe começou a fazer scrum, notei que as pessoas menos motivadas sobre scrum se viraram depois de verem suas sugestões das retrospectivas serem implementadas.

Vários problemas menores podem ser desmotivadores. Por exemplo, uma coisa que surgiu na semana passada foi um membro da equipe que não gostou das 4:00 reuniões. Isso é facilmente corrigido.

Em outras palavras, a melhor maneira de descobrir o que está desmotivando sua equipe é perguntar a eles.

Dando a eles propriedade individual sobre o código.

Muitas lojas trabalham com um modelo de "propriedade da equipe". Isso é ótimo para colaboração cruzada e redução de riscos, mas não tão bom para motivar os indivíduos a serem pessoalmente responsáveis. A propriedade da equipe pode resultar em código médio, porque não há incentivo individual à propriedade.

Solução: atribua indivíduos a cada seção do código a serem administradores dessa parte do código, mas permita o acesso total da equipe a toda a base de código.

Consulte também: https://softwareengineering.stackexchange.com/a/33464/1204