Llevo un tiempo intentando organizar ideas y notas respecto a la implantación de la agilidad en empresas grandes, de Scrum, es decir, allá donde por el número de personas no puede haber un solo equipo, debe haber varios.
En agilidad, y en Scrum, se sigue la premisa de que los equipos grandes son menos productivos que los pequeños (recuerda aquel post de que los equipos con mucha gente (más de 7) son menos productivos. Y que tener equipos pequeños es una buena práctica (ágil, además). Por ello, los equipos en Scrum son de entre 5 y 9 personas. Con todo ello, en empresas con más personas, a la hora de implantar la agilidad en empresas grandes, surge la pregunta… ¿Y si somos en la empresa más de 7 cómo nos organizamos? ¿cómo implanto la agilidad en empresas grandes?
En estos dos post te voy a dejar cinco decisiones, y buenas prácticas, que se suelen plantear principalmente a la hora de implantar la agilidad en empresas grandes: 1 – Scrum Master de los Scrum Master y el Product Owner de los Product Owner, 2 – Reuniones Scrum de Scrums, 3 – Sincronización de los Sprint y de las reuniones diarias, 4 – Equipos especializados frente a multifuncionales y 5 – Una pila de producto para todos los equipos o una pila de producto para cada equipo.
1 – Scrum Master de los Scrum Master y el Product Owner de los Product Owner
Cada equipo Scrum debe tener sus roles típicos, el equipo, el Product Owner y el Scrum Máster. Si hay tres equipos, normalmente, habrá tres Scrum Máster.
En estas situaciones, a la hora de implantar la agilidad en empresas grandes, cuando suele haber ya varios equipos Scrum, es bastante recomendable introducir la figura del Scrum Master de los Scrum Master, cuya responsabilidad es facilitar la resolución de problemas entre los equipos.
Igualmente, es común ver el Product Owner de los Product Owner, figura que coordina la funcionalidad global y a los Product Owner de cada equipo.
Ambos roles, Scrum Master de los Scrum Master y el Product Owner de los Product Owner, suelen tener sentido con tres o más equipos.
2 – A la hora de implantar la agilidad en empresas grandes, utiliza las reuniones Scrum de Scrums
Resumidamente, las reuniones Scrum de Scrums se basan en que cada equipo Scrum identifica a una persona que asiste a la reunión Scrum de Scrums, una reunión específica para coordinar el trabajo de varios equipos de Scrum.
Estas reuniones son similares a la reunión diaria de Scrum (el daily meeting), pero no ocurren necesariamente todos los días. En muchas organizaciones, suelen ser dos o tres veces a la semana.
3 – Sincronización de los Sprint y de las reuniones diarias
Al implantar la agilidad en empresas grandes tendremos varios equipos, cada equipo trabajará en sus Sprint, y ya hablamos en aquel post de cuánto tiempo debería durar una iteración en un proyecto ágil, y que lo normal es que para un equipo todas las iteraciones duren igual. Pero con dos o más equipos surgen dudas de ¿deberían durar lo mismo para ambos equipos? ¿deberían empezar y terminar a la vez?
Lo más recomendado y usado a la hora de implantar la agilidad en empresas grandes es intentar que los Sprint, las iteraciones, de todos los equipos duren lo mismo y comiencen y terminen a la vez.
En ocasiones, cuando hay más de un equipo, es conveniente que las reuniones diarias no se solapen, es decir, que si el equipo 1 hace la reunión diaria todos los días a las 9:00 el equipo 2 las haga todos los días a las 10:00. La idea es permitir al product owner del equipo 1 asistir, si fuese necesario, a las reuniones del equipo 2, y lo mismo con el Scrum Master de Scrum Master.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Buenas!!
Nosotros nos encontramos en esta situación, y efectívamente cada equipo (proyecto) tiene su equipo scrum con sus scrum-master, su product-owner, etc
Antes hacíamos una retrospectiva, conjunta, de todos los miembros de la empresa. Ahora, cada equipo hará su retrospectiva y después haremos una retro de retros, digamos 🙂
¿Crees que es lo ideal?
Y yendo más allá… ¿Es posible hacer scrum de scrums de scrums?
Quiero decir… ahora tenemos scrum de scrums como he comentado, pero solo del equipo de Producto y Desarrollo… creo q sería muy beneficioso poner un nivel más alto y hacer scrum con el resto de departamentos de la empresa (marketing, administración, operaciones, etc etc)
Creo que el único problema sería el de siempre, evangelizar a ese nivel…
Saludos!