En los equipos Agile/Scrum, el concepto de un equipo autoorganizado y la noción de que "el equipo posee todas las historias, los individuos no" está resultando difícil de comunicar. He visto muchos artículos y muchas páginas de texto que explican esto.
Un ejemplo que he escuchado es el de personas que limpian una sala de conferencias desordenada, después de un ejercicio de trabajo en equipo que involucra notas adhesivas, carteles, marcadores, aviones de papel, globos, etc. Nadie le dice a nadie qué hacer: todos colaboran para hacer una parte de la limpieza hasta que se completa.
¿Hay otros buenos ejemplos que ayuden a transmitir esta idea al equipo?
¡En lugar de explicar, déjelos experimentarlo! Use uno de los muchos juegos de creación de equipos en los que comprenderán durante el juego que deben cooperar y organizarse.
Aquí un ejemplo típico:
Dependiendo de su redacción, tendrán la sensación de que es una carrera y el grupo que termine primero su rompecabezas ganará. Sin embargo, hay un truco:
Después de un tiempo, lo notarán y preguntarán qué hacer. No responda, simplemente déjelos continuar. Ellos mismos lo resolverán.
Después del juego debes ayudarlos a reflexionar sobre lo que pasó. Comenzaron como grupos independientes, pero solo pudieron resolver el problema general trabajando juntos y autoorganizándose.
No podrá encontrar un solo ejemplo que ejemplifique todos los diversos conceptos que normalmente se incluyen en el término autoorganización . Para encontrar un ejemplo apropiado para su caso de uso, debe decidir qué comportamiento específico está tratando de modelar.
Nadie le dice a nadie qué hacer: todos colaboran para hacer una parte de la limpieza hasta que se completa.
No estoy seguro de que este ejemplo comunique algo más que "estás solo". Sí, puedo ver cómo se puede retomar un tema de autogestión en torno a la conveniencia de que la gente limpie la sala de conferencias, pero no creo que envíe el mensaje correcto.
El comportamiento real que está tratando de modelar con el ejemplo que proporcionó es:
Estos son ciertamente aspectos de la autoorganización, pero ninguna de estas cosas realmente resalta la propiedad colectiva que dices que quieres modelar. Necesitas un enfoque diferente.
En mi experiencia personal, el concepto de propiedad colectiva se modela mejor a través de ejercicios de Planning Poker que se amplían para incluir a todos los miembros de un equipo multifuncional. Por ejemplo, puede usar una historia de página de inicio de sesión y alentar al equipo a ampliar la historia de desarrollo para incluir redacción técnica, arquitectura de base de datos o topología de red para mostrar que todo el equipo debe ser parte del plan y la ejecución.
También puede considerar probar un ejercicio que requiere que cada miembro del equipo agregue valor a una historia, para mostrar que una historia no se puede completar sin la participación de todo el equipo.
Por ejemplo, puede dar a todos los miembros del equipo un único rasgo facial para Mr. Potato Head . Todos agregan valor a Mr. Potato Head agregando un ojo o una oreja, o asegurándose de que las partes estén en los lugares correctos. Al pasar la cabeza alrededor de un círculo, modela la participación de todo el equipo en la definición de hecho .
NOTA: Es posible que tenga la tentación de tratar de hacer que este ejemplo en particular tenga una forma más libre para modelar la comunicación necesaria para enjambrar o autoorganizarse en torno a una solución desarrollada en equipo, pero en mi experiencia, la tarea es demasiado prescriptiva y demasiado simplista para hacer ese punto con eficacia. Su experiencia puede ser diferente.
La autoorganización es un concepto sorprendentemente complejo de comunicar. Cada ejercicio debe comunicar claramente una faceta individual de este concepto. Como corolario, centrarse en las facetas de la autoorganización en lugar de la Gestalt puede requerir que use más de un ejemplo para ilustrar sus puntos y refinar iterativamente la comprensión del equipo con el tiempo.
Siéntase libre de aplicar los conceptos de "inspeccionar y adaptar" de Scrum a los ejercicios de su equipo. Si tiene un punto que hacer, utilice una revisión o una retrospectiva del ejercicio para asegurarse de que el punto se comunicó de manera efectiva y prepare el escenario para la mejora de ejercicios futuros.
Todd A. Jacobs