← Ensaios

Prática do uso do rating pessoal de cada membro da equipe no contexto de Scrum e SAFe

Neste artigo pretendo contar como, na minha prática, calculamos e aplicamos o rating pessoal de cada membro da equipe em Scrum durante o trabalho com o framework SAFeBlog pessoal.

5 min de leitura
TelegramOriginal
Prática do uso do rating pessoal de cada membro da equipe no contexto de Scrum e SAFe

Neste artigo pretendo contar como, na minha prática, aplicamos o Rating pessoal de cada membro da equipe em Scrum durante o trabalho com o framework SAFe

Provavelmente, muitos concordarão que (especialmente na Rússia) as pessoas com bastante frequência tentam trabalhar (entregar o produto final dentro de suas competências ou por meio da obtenção de novas) menos e receber mais dinheiro. Com o tamanho da empresa, as possibilidades para isso, ao que parece, crescem diretamente proporcionalmente. Com isso, via de regra, trabalham diversos profissionais de RH, que de todas as formas tentam construir o sistema correto de motivação. Aqui também entram os OKRs e etc. Em geral, parece que tudo isso visa o equilíbrio da carga de cada um dentro da corporação e o conforto de todos os grupos de interessados/equipes da corporação. Neste artigo eu compartilharei uma métrica que eu mesmo criei e aplico na equipe. Ela permite, ao que me parece, complementar os esforços dos RHs e dos OKRs no equilíbrio da carga dentro de uma equipe específica ou ver o desequilíbrio, respectivamente. Além disso, ela bem pode escalar para a equipe de equipes, não vejo nisso um problema especial.

Assim, para mim como Scrum Master, às vezes é bastante óbvio que a carga na equipe não está equilibrada, alguém trabalha por dois, alguém não faz nada (estas são formas extremas e, claro, um problema sério, mas esta métrica mostra não apenas as formas extremas). Comigo aconteceu essa situação e eu pensei sobre qual métrica poderia evidenciar claramente esse problema. No final, isso resultou no rating pessoal de cada membro da equipe.

Antes de descrever a própria métrica, gostaria também de destacar uma ideia muito importante, na minha opinião. No momento, estou absolutamente certo dela.

As métricas devem ser construídas com base nos dados que você já obtém. A obtenção de qualquer métrica não deve obrigar a equipe a gastar sistematicamente mais tempo e ajustar seu processo de entrega de valor à própria métrica. Mais detalhes sobre isso eu tentarei contar em um dos próximos artigos.

Então, um exemplo de caso concreto. Claro, usamos um quadro para mover as User Stories pelos status de DOR (Definition Of Ready) até DOD (Definition Of Done). Ele é virtual para nós (ou seja, está localizado na internet por um link. Nossa equipe também é distribuída e os standups acontecem via Skype corporativo justamente com a transmissão do quadro.

Para o membro da equipe é conveniente se colocar como participante da User Story, para que, ao usar o filtro por si mesmo, seja possível deixar rapidamente apenas as histórias nas quais ele participa no momento (na maioria das vezes usamos esse filtro nos standups).

Image

Aqui também gostaria de dar uma explicação: isso não significa que este membro da equipe não possa participar de outras histórias (se, por exemplo, no standup algum dos membros da equipe pedir ajuda, ele bem pode se tornar participante de uma nova história ou, ao contrário, se sentir que sua participação não é necessária, pode deixar de ser participante de alguma história.

Assim, para calcular o rating de cada membro da equipe, precisamos ver em quantos SP cada membro da equipe influencia. No nosso caso, Arkady influencia 29 SP (histórias 1, 2, 5, 6), Tatiana influencia 33 SP (participa de todas as histórias), Vasily em 23 SP (histórias 1, 3, 5, 6).

Fechado (DOD cumprido) para Arkady 5 de 29 SP, para Tatiana 6 de 32 SP, para Vasily 5 de 23. Com a ordenação eu sofri bastante e cheguei a esta fórmula de comparação de dois membros da equipe (team[i] - um membro da equipe e team[j] - outro membro da equipe):

Image

De acordo com esta ordenação, obteremos o rating atual dos membros da equipe na seguinte forma.

  • 1º lugar. Vasily (Concluído 5 de 23)
  • 2º lugar. Arkady (Concluído 5 de 29)
  • 3º lugar. Tatiana (Concluído 6 de 32)

Agora vamos gerar todos os dados do sprint. Imaginemos que o sprint dura 5 dias úteis.

  • 1º dia

    Image

    Image


    1º lugar: Vasily (queimado 0 de 23)
    2º lugar: Arkady (queimado 0 de 29)
    3º lugar: Tatiana (queimado 0 de 32)
  • 2º dia

    Image

    Image


    1º lugar: Vasily (queimado 0 de 23) dinâmica(1->1)
    2º lugar: Arkady (queimado 0 de 29) dinâmica(2->2)
    3º lugar: Tatiana (queimado 0 de 32) dinâmica(3->3)
  • 3º dia

    Image

    Image


    1º lugar: Vasily (queimados 5 de 23) dinâmica(1->1->1)
    2º lugar: Arkady (queimados 5 de 29) dinâmica(2->2->2)
    3º lugar: Tatiana (queimados 5 de 32) dinâmica(3->3->3)
  • 4º dia

    Image

    Image


    1º lugar: Vasily (queimados 8 de 23) dinâmica(1->1->1->1)
    2º lugar: Arkady (queimados 8 de 29) dinâmica(2->2->2->2)
    3º lugar: Tatiana (queimados 9 de 32) dinâmica(3->3->3->3)
  • 5º dia

    Image

    Image


    1º lugar: Vasily (queimados 23 de 23) dinâmica(1->1->1->1->1)
    2º lugar: Tatiana (queimados 24 de 32) dinâmica(3->3->3->3->2)
    3º lugar: Arkady (queimados 21 de 29) dinâmica(2->2->2->2->3)

Assim, usando esta métrica é possível acumular estatísticas pessoais de cada membro da equipe e ajudá-lo a tirar as conclusões corretas. Por exemplo, aqui vemos que Vasily planejou seu tempo de forma muito competente desde o início (ou seja, no planejamento da sprint ele concordou com a equipe sobre o volume de trabalho que ele de fato realizou.) Mas, ao mesmo tempo, será que ele poderia de alguma forma ter ajudado os outros membros da equipe? Talvez não, mas vale a pena pensar nessa questão antes da retrospectiva.

Tatiana e Arkady têm um problema mais sério. É evidente que desde o início, no planejamento da sprint, eles concordaram com a equipe em participar de todas as histórias e, na prática, não conseguiram cumprir as obrigações. Vale a pena pensar nas causas também antes da retrospectiva. Talvez valha a pena planejar menos para si, talvez ampliar as competências para conseguir cumprir tudo o que foi planejado, outras soluções também são possíveis.

Assim, podemos acumular estatísticas não apenas de toda a equipe e não apenas de uma sprint, mas também de participantes específicos da DEV TEAM ao longo de todo o tempo e usar essas informações para o aprimoramento contínuo da equipe.

Por fim, gostaria de chamar especial atenção para o fato de que, antes de usar esta métrica na equipe, já deve haver um nível de confiança suficientemente alto na maior parte da equipe. Além disso, eu recomendaria dar grande ênfase ao que é primordial - a ausência de horas extras e uma atividade confortável.

Nós focamos no prognóstico correto do resultado, e não na motivação para fazer horas extras a fim de ocupar o 1º lugar. Em última análise, esta métrica visa melhorar a capacidade de planejamento de cada membro da equipe individualmente.