top of page
Buscar
  • OnceDev

Incluye a todos los miembros del equipo en las reuniones del Sprint. Sí, a ellos también.

Actualizado: 5 may 2019

· Creado por: Mike Cohn

· traducido por: rick@oncedev.com

Los líderes Agile deben desalentar cualquier comportamiento que nos motive a pensar, como excluir a alguien de una reunión simplemente por su rol.

https://www.mountaingoatsoftware.com/blog/include-all-team-members-in-sprint-meetings.-yes-them-too


He estado en algunas disputas últimamente. Cada disputa era única, pero había un hilo común en cada una de ellas: si se debía invitar a todo el equipo a asistir a ciertas reuniones Scrum.


Creo firmemente que los equipos Agiles se desempeñan mejor cuando los miembros del equipo se sienten y actúan como un solo equipo:

· Cualquier sentimiento de "nosotros contra ellos" desaparece

· Se eliminan las actividades de señalar con el dedo y las de cubrirse las espaldas.

· Los miembros del equipo ponen las metas del equipo por encima de las agendas personales.

· Los miembros del equipo están más dispuestos a comprometerse para obtener consenso si al hacerlo ayudan al equipo a lograr sus objetivos generales


Los equipos Agiles deben fomentar una mentalidad de "equipo unido". Por ejemplo, un equipo Agile no debería sentir que tiene un subequipo de programación y un subequipo de prueba. Cuando un equipo actúa como un solo equipo, la idea de subequipos funcionales se desvanece. De la misma manera, los equipos Agiles no deben sentir que necesitan ocultarse algo entre ellos, y eso incluye al Scrum Master y al Product Owner. Los equipos que actúan como un equipo incluyen todos los roles en cada reunión Sprint: desde la planificación y los Scrum diarios hasta las revisiones y retrospectivas.


Las disputas en las que me encontré fueron con personas que no valoraban esta mentalidad de un solo equipo o todo el equipo tanto como yo. Sospecho que eso se debe a que no se dan cuenta de lo importante que es la mentalidad de todo un equipo para tener éxito con Agile.


Identidad del miembro del equipo


Déjame retroceder un momento. Cuando digo que los equipos Agiles no deberían tener subequipos funcionales como un equipo de programación y un equipo de pruebas, no estoy diciendo que todos deban ser generalistas .Ese es un mito común en Agile. Más bien, estoy diciendo que las personas en equipos Agiles deben obtener la mayor parte de su identidad de la membresía en el equipo en lugar de asociarse con otros con las mismas habilidades.


Para ver lo que quiero decir, piensa en un equipo deportivo. El deporte no importa, pero usaré el béisbol. Un lanzador de los Yankees de Nueva York debería considerarse un Yankee primero y un lanzador segundo.


Claro, este lanzador puede ocasionalmente juntarse con los lanzadores de otros equipos. Y cuando esos lanzadores se juntan, intercambian historias con las que solo los lanzadores pueden relacionarse con: "Hombre, una vez que cumplí 30 años, empecé a necesitar esas bolsas de hielo en mi hombro cada vez que hice más de 80 lanzamientos en un juego".


Pero, aun así, nuestro lanzador debe obtener la mayor parte de su identidad como un Yankee en lugar de como un lanzador.


Reglas especiales inhiben el pensamiento de "equipo unido"


Para fomentar una mentalidad de equipo unido, es importante eliminar cualquier regla especial creada o impuesta en el equipo que se aplique solo a un subconjunto del equipo. La moral del equipo de béisbol se vería afectada si hubiera una jarra de Gatorade en el vestuario con un cartel que decía "solo lanzadores". Y los equipos Agiles no pueden prosperar cuando hay un cartel metafórico en la puerta de la reunión que dice "Solo equipo de desarrollo".


Pero eso es exactamente lo que sucede en muchos equipos cuando se trata de dos reuniones Agiles específicas: el Scrum diario y la retrospectiva del Sprint.


Los argumentos que mencioné anteriormente se centraban en gran medida en torno a alguien que me decía que el Product Owner (y, a veces, incluso el Scrum Master) no debería participar en estas reuniones.


Esto está mal, mal, mal.


Excluyendo al Product Owner de las reuniones


Cualquier regla que establezca un equipo diciendo: "Este tipo de persona no debería participar debido a su rol" funciona completamente en contra del objetivo de crear una mentalidad de equipo unido.


Para ver lo incorrecto que es excluir al Product Owner de estas reuniones solo porque la persona sea propietaria del producto, imagina una regla a la que dichos evaluadores no puedan asistir. O los miembros zurdos del equipo no pueden asistir.


Si esas reglas suenan mal, entonces también lo es una regla que dice que los Product Owner o Scrum Master no pueden asistir.


¿Qué pasa si el Product Owner es un idiota?


A veces me dicen que un equipo no quiere que el Product Owner participe en un Scrum diario o en una retrospectiva porque el Product Owner es un imbécil. Bueno, la solución es hacer lo mismo que haría el equipo si un programador fuera un imbécil: abordar el comportamiento de esa persona.


No hagas una regla que diga que cierto rol no puede asistir.


Sí, algunos Product Owner son idiotas. Pero también lo son algunos programadores, evaluadores, escritores de tecnología, analistas, Scrum Master, administradores de bases de datos, etc.


Pero no cambiamos lo que es correcto solo porque algunos equipos tienen un Product Owner que abusa de una retrospectiva como una forma, por ejemplo, de arengar al equipo sobre por qué su velocidad no se ha duplicado en el último mes.


Los equipos Agile necesitan una mentalidad de equipo unido


Establecer una mentalidad de equipo unido es un objetivo importante para cualquier equipo que quiera rendir al más alto nivel posible. Esto no significa que las personas sean intercambiables o que todos aprendan cómo hacer el trabajo de todos los demás.


Pero significa que todos en el equipo piensan primero en cómo lograr los objetivos del equipo en lugar de los objetivos individuales de cada persona.


Tommy Lasorda, gerente del equipo de béisbol de los Dodgers de Los Angeles desde hace mucho, lo sabía. Dijo que su trabajo era hacer que los jugadores trabajaran para el nombre del equipo en el pecho en lugar de sus propios nombres en la espalda. Esta es la esencia de una mentalidad de equipo unido en la que todos los miembros del equipo sienten que están juntos.


Como entrenadores Agile, Scrum Master y otros líderes Agile, nuestra misión es ayudar a nuestros equipos a lograr esta mentalidad de equipo unido. Para hacer eso, debemos desalentar cualquier comportamiento que nos motive a pensar, como excluir a alguien de una reunión simplemente por su rol.


¿Qué piensas tú?


¿Tu equipo ha establecido una mentalidad de equipo unido? ¿Como lo hicieron? ¿Ha mejorado cómo los miembros del equipo trabajan juntos? Por favor comparte tus pensamientos en los comentarios abajo.

104 visualizaciones0 comentarios

Entradas Recientes

Ver todo
bottom of page