En los últimos días ha habido un debate muy activo en el grupo de Scrum Development do Yahoo Groups sobre qué hacer cuando una persona de su equipo está teniendo "bajo desempeño". En el hilo de más de 130 respuestas, Rotten Apple in Scrum Team, el debate fue desde consejos hasta la cuestión principal, hablando de la moral del equipo y quien la gestiona, hasta el clásico debate de la medición de
los individuos, para distinguir si un equipo es realmente un "equipo" y más.
Marko Majkic comenzó el debate describiendo a un miembro de su equipo que parece tener problemas de "bajo desempeño" y pedió consejos sobre cómo hacer frente a eso (cita derivada del post original y de una respuesta posterior):
La contribución media por desarrollador es de 38 usp (user story points, o puntos de historia de usuario). Dos miembros hacen apenas 19 ups - dos veces menos que los demás.
....
No creo que esta persona sea perezosa o malintencionada. A mí me parece que tiene la mente ausente del trabajo y/o tiene falta de
concentración.
...
Debo llevar eso a una reunión de revisión de Scrum o debo hablar con esta persona en particular? ¿Qué harían?
A partir de esta declaración muchos temas se pusieron en marcha, uno de los cuales es un debate sobre la primer cuestión de Marko sobre cómo tratar con la persona de bajo rendimiento. Muchas de estas respuestas retornan a la base de sugerir que la acción más crucial es hacer una nueva evaluación objetiva de lo que está sucediendo realmente. Paul Hudson, resume:
Como han dicho otros, es posible que tenga que volver un paso atrás aquí. Creo que, sobre la base de lo que dice usted que asume que
el individuo debe ser considerado responsable de la baja productividad, en lugar de buscar solucionar algunas cuestionessubyacentes.
...
Creo que (y muchos otros) le sugerimos que utilice otros puntos de vista. No hay una fórmula mágica. Usted necesita saber qué problemas la persona en cuestión puede tener y discutirlos con él.
...
Por lo tanto, las sugerencias (concretas) fueron:
- Comprobar si el problema es realmente un problema y eso es lo que usted cree que es
- Obtener más información acerca de los problemas que la persona pueda enfrentar
- Levante y discuta el problema a nivel del equipo o individual
Más consejos sobre cómo actuar en relación con las cosas mencionadas en las sugerencias de alto nivel de Paul, incluyen cosas como:
- Tenga cuidado con las palabras que elige para describir a este individuo especialmente, "manzana podrida" es probablemente una mala
manera de referirse a esta situación. - El consejo de Mark Levison fue abordar la situación con la mente de principiante (como lo presentado por Jean Tabaka y David Hussman).
- El consejo de varias personas, incluyendo a George Dinwiddie, fue separar a esta persona algún tiempo y hacer la programación en
parejas con esa persona. - Sabiduría para mantener objetivo sin juzgar, incluyendo sugerencias como un aventón con Linda Rising.
Curiosamente, un debate posterior puso de manifiesto que la preocupación de Marko no fue tanto sobre la producción real de la persona
por sí solo, sino el temor de que el resto del equipo puede reaccionar negativamente a la persona, tal vez trayendo esto a una retrospectiva. Como era de esperar, muchas respuestas se apresuraron a subrayar que este es un resultado deseado, y no debe ser
temido. Como declaró Ilja Pruess:
Yo realmente me preocuparía mucho mas sobre lo que *no* hablar haría a la atmósfera del equipo.
...
Entonces sí yo sentí que había malos sentimientos acerca de este "bajo desempeño" en el equipo, yo vería esto como mi responsabilidad como un facilitador, *fomentar* a los miembros del equipo para que hablen y ayudar a solucionar con gracia el problema.
A partir de esto vino también un debate sobre el tema de la "moral del equipo". Particularmente, fueron notables las respuestas a la pregunta de quién "es el responsable (de mantener la moral del equipo)? ". Las respuestas dadas por Alistair Cockburn, Dan Rawsthorne, Michael Wollin, Paul Hudson y otros se discute si ésta es la función principal del Scrum Master, director de proyecto, Dueño del Producto, del equipo en sí, del CEO, de otros y/o todos los citados anteriormente. Asimismo, una referencia de información sobre cómo mejorar la moral fue presentada en el centro de la discusión.
También a partir de la declaración inicial de Marko rescucitó el debate en torno a la medición del desempeño individual (re: Marko utiliza "puntos por persona"), que Ron Jeffries recordó, que no debe haber tal cosa como "puntos completados por cada persona" si el equipo está realmente funcionando como un "equipo". Una discusión relacionada presentada con la idea de que la medición del desempeño de las personas (objetivamente) puede no ser necesariamente erradas, pero sólo debe utilizarse como una entrada de muchas de sus evaluaciones subjetivas de una persona (por ejemplo, registro de Eric Deslauriers).
Para obtener más información sobre este tema, vea un post popular de InfoQ sobre "análisis de performance" y dos post recientes de George Dinwiddie en la química del equipo, y juzgando el rendimiento y también uno de Mark Levison.
Por último, recuerde, hasta la fecha hubo mas de 130 respuestas en Scrum Development Yahoo Group discussion, por lo tanto, si te interesa el tema y tenes ganas de profundizar mas sobre el mismo, esta fue solo una visión muy general y hemos intentado de poner los enlaces necesarios como para que puedas centrarte mas en el tema profundizando en cada uno de ellos.