Práctica del uso del rating personal de cada miembro del equipo en el contexto de Scrum y SAFe

En este artículo planeo contar cómo, en nuestra práctica, aplicamos el Rating personal de cada miembro del equipo en Scrum durante el trabajo con el framework SAFe

Probablemente, muchos estarán de acuerdo en que (especialmente en Rusia) nuestras personas con bastante frecuencia intentan trabajar (entregar el producto final dentro de sus competencias o mediante la obtención de nuevas) menos y recibir más dinero. Con el tamaño de la empresa, las posibilidades para esto, al parecer, crecen directamente proporcional. Con esto, por regla general, trabajan diversos cuasi-RRHH, que de todas las formas posibles intentan construir el sistema correcto de motivación. Aquí también están los OKR y etc. En general, parece que todo esto está orientado al equilibrio de la carga de cada uno dentro de la corporación y a la comodidad de todos los grupos de interés/equipos de la corporación. En este artículo compartiré la métrica que yo mismo inventé y aplico en el equipo. Ella permite, según me parece, complementar los esfuerzos de los RRHH y los OKR en el equilibrio de la carga dentro de un equipo concreto o ver el desequilibrio, respectivamente. También, bien puede escalarse al equipo de equipos, no veo en ello un problema particular.

Así, a mí como Scrum Master a veces me resulta bastante obvio que la carga en el equipo no está equilibrada, alguien trabaja por dos, alguien no hace nada (estas son formas extremas y, por supuesto, un problema serio, pero esta métrica muestra no solo las formas extremas). Me ocurrió tal situación y me puse a pensar qué métrica podría iluminar vívidamente dicho problema. En resumen, esto se tradujo en el rating personal de cada miembro del equipo.

Antes de describir la métrica en sí, me gustaría también señalar una idea, en mi opinión, muy importante. En este momento estoy absolutamente seguro de ella.

Las métricas deben construirse sobre la base de aquellos datos que ustedes ya reciben. La obtención de cualquier métrica no debe obligar al equipo a gastar sistemáticamente más tiempo y adaptar su proceso de entrega de valor a la propia métrica. Sobre esto con más detalle intentaré contar en uno de los siguientes artículos.

Entonces, un ejemplo de un caso concreto. Por supuesto, usamos un tablero para mover las User Stories por los estados desde DOR (Definition Of Ready) hasta DOD (Definition Of Done). Lo tenemos virtual (es decir, ubicado en internet mediante un enlace. El equipo también lo tenemos distribuido y los standups se realizan a través de Skype corporativo justamente con la transmisión del tablero.

Al miembro del equipo le resulta cómodo ponerse a sí mismo como participante de la User Story, para que al usar el filtro por sí mismo se pueda dejar rápidamente solo aquellas historias en las que participa en este momento (la mayoría de las veces usamos este filtro en los standups).

Aquí también me gustaría dar una aclaración: esto no significa que dicho miembro del equipo no pueda participar en otras historias (si, por ejemplo, en el standup alguno de los miembros del equipo pide ayuda, bien puede convertirse en participante de una nueva historia o, al contrario, si siente que su participación no es necesaria, puede dejar de ser participante de alguna historia.

Así, para calcular el rating de cada miembro del equipo, necesitamos ver en cuántos SP influye cada miembro del equipo. En nuestro caso, Arkadiy influye en 29 SP (historias 1, 2, 5, 6), Tatyana influye en 33 SP (participa en todas las historias), Vasiliy en 23 SP (historias 1, 3, 5, 6).

Cerrado (DOD cumplido) en Arkadiy 5 de 29 SP, en Tatyana 6 de 32 SP, en Vasiliy 5 de 23. Con la ordenación me atormenté bastante tiempo y llegué a la siguiente fórmula de comparación de dos miembros del equipo (team[i] - un miembro del equipo y team[j] - otro miembro del equipo):

Según esta ordenación obtendremos el rating actual de los miembros del equipo de la siguiente forma.

• 1er lugar. Vasiliy (Completado 5 de 23)
• 2do lugar. Arkadiy (Completado 5 de 29)
• 3er lugar. Tatyana (Completado 6 de 32)

Ahora generemos todos los datos del sprint. Imaginemos que el sprint dura 5 días laborables.

• Día 1
  

  

  
  1er lugar: Vasiliy (quemado 0 de 23)
  2do lugar: Arkadiy (quemado 0 de 29)
  3er lugar: Tatyana (quemado 0 de 32)
  
• Día 2
  

  

  
  1er lugar: Vasiliy (quemado 0 de 23) dinámica(1->1)
  2do lugar: Arkadiy (quemado 0 de 29) dinámica(2->2)
  3er lugar: Tatyana (quemado 0 de 32) dinámica(3->3)
  
• Día 3
  

  

  
  1er lugar: Vasili (quemado 5 de 23) dinámica(1->1->1)
  2do lugar: Arkadi (quemado 5 de 29) dinámica(2->2->2)
  3er lugar: Tatiana (quemado 5 de 32) dinámica(3->3->3)
  
• 4 día
  

  

  
  1er lugar: Vasili (quemado 8 de 23) dinámica(1->1->1->1)
  2do lugar: Arkadi (quemado 8 de 29) dinámica(2->2->2->2)
  3er lugar: Tatiana (quemado 9 de 32) dinámica(3->3->3->3)
  
• 5 día
  

  

  
  1er lugar: Vasili (quemado 23 de 23) dinámica(1->1->1->1->1)
  2do lugar: Tatiana (quemado 24 de 32) dinámica(3->3->3->3->2)
  3er lugar: Arkadi (quemado 21 de 29) dinámica(2->2->2->2->3)
  

Así, utilizando esta métrica se puede acumular estadística personal de cada miembro del equipo y ayudarle a sacar conclusiones correctas. Por ejemplo, aquí vemos que Vasili planificó su tiempo de forma muy sensata desde el principio (es decir, en la planificación del sprint acordó con el equipo el volumen de trabajo que efectivamente cumplió). Pero, al mismo tiempo, ¿podría haber ayudado de alguna forma a los demás miembros del equipo? Quizás no, pero vale la pena reflexionar sobre esta cuestión antes de la retrospectiva.

En Tatiana y Arkadi el problema es más serio. Es evidente que desde el principio, en la planificación del sprint, acordaron con el equipo participar en todas las historias y de hecho no pudieron cumplir los compromisos. También vale la pena reflexionar sobre las causas antes de la retrospectiva. Quizás conviene planificar menos para uno mismo, quizás ampliar las competencias para poder cumplir todo lo planificado, también son posibles otras soluciones.

Así, podemos acumular estadística no solo de todo el equipo y no solo de un sprint, sino también de participantes concretos del DEV TEAM a lo largo de todo el tiempo y usar esta información para la mejora continua del equipo.

Para concluir, me gustaría prestar especial atención al hecho de que antes de usar esta métrica en el equipo ya debe haber un nivel de confianza suficientemente alto en la mayor parte del equipo. Además, recomendaría poner un gran énfasis en lo primordial: la ausencia de horas extra y una actividad cómoda.

Nos centramos en la correcta previsión del resultado, y no en la motivación para trabajar horas extra con el fin de ocupar el 1er lugar. En última instancia, esta métrica está orientada a mejorar la capacidad de planificación de cada miembro del equipo por separado.