¿Cómo detectar al miembro perezoso del equipo en un equipo autoorganizado?

Un poco de contexto primero: soy gerente de proyectos en una empresa de desarrollo de software con un entorno Kanban. En el equipo que dirijo no existen personas que me informen sobre su trabajo, o personas que cuenten una tras otra lo que hicieron ayer, etc. Durante las reuniones de pie nos enfocamos en el flujo, casi nunca en una pieza en particular. de trabajo.

El otro día estaba teniendo una (pequeña) discusión con mi jefe sobre una frase del libro Management 3.0 de Jurgen Appelo:

Si los empleados necesitan gerentes es irrelevante. Son los accionistas los que necesitan a los administradores de su negocio. La autoorganización carece de valor. Se necesita a alguien interesado en sus resultados para decidir si los resultados de la autoorganización son "buenos" o "malos".

Entonces el jefe hizo esta pregunta:

Teniendo en cuenta un equipo autoorganizado en el que nunca se informa sobre el trabajo individual, ¿cómo detecta al miembro del equipo perezoso?

Uno de los principios clave de Scrum gira en torno al concepto de equipo autogestionado. ¿Has visto la película Full Metal Jacket? En esa película, el equipo descubre que Pvt. Pyle es un miembro perezoso (que come donas) del equipo. El equipo descubre que esto aumenta la carga de trabajo del resto del equipo. Entonces, como buen equipo autoorganizado, colaboran de forma independiente para encontrar una solución que funcione para todo el equipo. Esto funciona, y Pvt. Pyle acelera el paso. Desafortunadamente, esto resulta contraproducente para la administración más adelante. No daré ningún spoiler, pero te sugiero que veas la película para entender la historia completa.

Respuestas (3)

Juicios de valor versus análisis de flujo

Teniendo en cuenta un equipo autoorganizado en el que nunca se informa sobre el trabajo individual, ¿cómo detecta al miembro del equipo perezoso?

Esta es la forma incorrecta de hacer la pregunta, pero es comprensible ya que las personas son animales sociales. La pregunta se hace a través de un filtro social que imputa motivos en lugar de analizar el flujo del proceso e identificar cuellos de botella, brechas en el proceso o impedimentos.

Una mejor manera de ver este problema es observar el flujo general del proceso. Si la cadena de valor está intacta y el ciclo de tiempo del proceso es aceptable, la cuestión de si un miembro del equipo es una superestrella o un superfracaso es en realidad irrelevante . La única pregunta que importa es si esa persona agrega valor a la cadena o si el proceso se encamina alrededor de esa persona (por ejemplo, la persona es un cuello de botella/impedimento que podría considerarse "desperdicio" desde una perspectiva Kanban).

Supongamos por el momento que la persona es perezosa, pero sin embargo agrega valor al proceso. Tal vez esta persona es la única que sabe cómo agrandar el whatsit antes de enviarlo al cliente. Si bien puede ser tentador reemplazar a esta persona con alguien que está emocionado de presentarse todos los días y hacer que todo crezca más rápido, la Ley de las consecuencias no deseadas sugiere que esto en realidad puede no mejorar su proceso o los tiempos de ciclo. Tal vez el proceso no pueda moverse más rápido de lo que lo hace, o tal vez esta persona proporcione un valor no rastreado a la cadena del proceso que no es capturado por ningún carril de natación o tarjeta de historia en particular.

Si quieres andar despidiendo gente por "vileza moral" o algún otro equivalente social, está bien. Pero no cometa el error de pensar que se trata de un problema de proceso , porque los datos que ha presentado no lo respaldan.

No optimice las subtareas

En Kanban (como en otras metodologías ágiles), el seguimiento del desempeño individual es siempre la métrica incorrecta. Bob Lewis ha dicho repetidamente :

No puede optimizar el todo optimizando las partes, ya sea que esté diseñando un automóvil, un sistema de software o una organización de TI.

Es un tema omnipresente para el Sr. Lewis, y aunque el contexto de la entrada de blog a la que se hace referencia es ligeramente diferente a su problema, el mensaje central aún está en el objetivo. Si cree que alguna parte del proceso no es óptima, debe considerar cuidadosamente si la optimización de alguna subtarea o función mejoraría o degradaría realmente su proceso general.

Si siente que alguien es "perezoso", implícitamente está abordando una posible optimización. Debe considerar cuidadosamente su métrica (¿Por qué cree que esta persona es perezosa?) y determinar si realmente importa o no para el proceso general. Si está midiendo algo incorrecto u optimizando algo que no sea la cadena de valor, la reducción de desperdicios o el rendimiento del proceso, entonces solo está participando en la ingeniería social.

Uno realmente no puede detectar a un miembro del equipo perezoso en un equipo interfuncional . Lo bueno de los equipos interfuncionales es la cohesión, que "ocultará" el desempeño (bueno o malo) del individuo, por lo que no se puede decir realmente que X o Y son perezosos. Puede suceder que los miembros del equipo estén hablando de otro miembro, pero esa discusión no debe ser visible en el nivel de su jefe, a menos que los miembros del equipo la escalen. El libro de Jurgen trata sobre la gestión ágil, y no conozco a su jefe, pero después de recibir el libro, se dará cuenta de que no hay respuesta a su pregunta en un contexto Agile o Management 3.0.

Digamos que eres un miembro del equipo y piensas que tu colega es vago. Considero la pereza como un síntoma. En la mayoría de los casos, hay algo más detrás, por lo que averiguar qué está pasando es la clave. Recuerdo que un antiguo colega mío estaba convencido de que otro colega era un vago y continuamente intentaba demostrarlo y deshacerse de ese otro colega. En realidad, no era nada holgazán, pero sí mucho más lento que los demás. Entonces, si cree que alguien en su equipo es vago, profundice y descubra su motivo . Hay dos soluciones: ayudarlo o buscarle otro equipo.

1) forma sencilla: dado que tiene un tablero Kanban, debería ser relativamente fácil realizar un seguimiento de la cantidad promedio de tareas/puntos realizados por cada miembro del equipo

2) pídale (individualmente) a cada miembro del equipo que elija 1 o 2 socios para una tarea difícil e importante (tarea, historia) y vea quién NO será elegido; este método podría brindarle más información sobre el equipo, pero podría resultar contraproducente, por lo que ten cuidado.


una cosa más: no tienes que optimizar para "puntos de historia por persona" pero podría ser una buena idea saber que tienes un eslabón débil en el equipo (tal vez, alguien que produce resultados negativos (lo he visto))

Kanban no está diseñado para realizar un seguimiento del rendimiento individual. Si optimiza para "puntos de historia por persona", no está optimizando para el flujo del proceso o el rendimiento.
@CodeGnome: estoy de acuerdo, pero (afaik) 1) cada elemento activo (tarea) en el tablero Kanban debe tener el nombre de la(s) persona(s) que trabajan en este elemento 2) cada historia y tarea debe estimarse por adelantado -> si gerente realmente quiere estimar el rendimiento del miembro del equipo, es posible hacerlo.
una cosa más: no tienes que optimizar para "puntos de historia por persona" , pero podría ser una buena idea saber que tienes un eslabón débil en el equipo (quizás, el que produce resultados negativos )
En Kanban, las historias no tienen propietarios. Los carriles de natación o las columnas de proceso podrían, pero las historias en sí mismas deberían ser "papas calientes" propiedad de la comunidad que se extraigan a través de las colas de proceso. Las colas ascendentes inactivas generalmente son un signo de problemas de rendimiento o WIP, y no necesariamente "pereza". La gente puede ser perezosa, pero no se puede medir únicamente en función del tiempo del ciclo entre procesos.
@CodeGnome No dije "historias", dije tareas . Y no estaba hablando de los propietarios, pero, en mi humilde opinión, esa nota adhesiva debería tener el nombre de la persona que está trabajando en esta tarea en este momento ; la razón es simple: si algo sale mal con esta tarea (o si tiene alguna pregunta), ¿ a quién le pedirá detalles ?