La duración de los Sprint, la manera (ojo, digo manera, no la realización) de estimar (usar puntos historia, lo qué significan, quizá decidir no estimar, etc.), el formato del Sprint Backlog, etc., en resumen me refiero a todo aquello relativo a la manera, Ágil, de trabajar, a la adaptación del framework Ágil de trabajo, finalmente, en todo ello… ¿Quién tiene la última palabra?
Conozco a un Scrum Master (uno que no considero en peligro de extinción), que sabe que su equipo tiene un problema con cómo hace las estimaciones, y de ahí, un problema en cómo cumple con el compromiso del Sprint. Él cree saber la solución, y yo también creo que su idea es mejor opción que la actual… pero no la pone en marchar porque al equipo no le parece la apropiada.
Pero los Sprints pasan y las cosas no cambian, tampoco se prueban nuevas maneras, Ágiles, de hacer las cosas. Y los Sprints pasan, uno tras otro… ¿Qué hacer? El Scrum Master propone, sugiere, pero al equipo no le parece bien ninguna de las propuestas del Scrum Master.
Creo que hemos mandado con demasiada fuerza (y con razón) el mensaje de que «el Scrum Máster no sea un Jefe de Proyecto encubierto» que, en algunos casos, hemos acobardado a muchos Scrum Master… y ahora tenemos Scrum Masters un poco miedicas.
Si las cosas no funcionan, pasa el tiempo, y no hay cambio… ¡alguien tiene que decidir! Creo que, visto desde fuera, la opción parece lógica y obvia… debería decidir el Scrum Master.
Pero como esta es sólo mi opinión, en base a mis experiencias, e incluso lo anterior puede sonar para algunos «poco ágil», vamos a ver que dicen por ahí los «agilistas» que saben, para tener más opiniones y referencias.
Por ejemplo, Mike Cohn, uno de los autores que más contribuyó a popularizar las «maneras Ágiles» de trabajar, escribía hace unos años un post en esta línea. Lo centró en quién debía decidir la duración de un Sprint, si bien es extrapolable a otros como el método de estimación (que no a estimar, ojo, no te confundas), etc.
Lógicamente, como decía Cohn en su post (y yo coincido), en primera instancia, la mayoría de ese tipo de decisiones deberían ser en consenso, todo el equipo, el Scrum Master, el equipo técnico, etc. Pero… ¿Y si no hay consenso?
El Scrum Master es la última instancia.
El Scrum Master debería fomentar en consenso, hacer ver la necesidad de decidir cambiar algo en la manera de trabajar, pero si no hay consenso, y el tiempo pasa, el Scrum Master es quién tiene que tomar la decisión sobre el proceso Ágil. Porque, como dice el post de Cohn, dicen otros tantos sitios y, humildemente te diré yo… el Scrum Master es el responsable del proceso.
El Scrum Master es el que más debe saber sobre agilidad, es el que debe llevar las mejores prácticas Ágiles al equipo. Al equipo técnico se le puede pedir que programe bien, pero no tanto que sea experto en buenas prácticas de estimación Ágil.
El Scrum Master es un líder sirviente, pero no pasivo, y por ello que en su día hablamos de que es mejor comparar el liderazgo de un Scrum Master con un «anfitrión», más que un sirviente (esto te lo conté en Servant Leadership vs Host Leadership y, si quieres más referencias de ello, esta idea nos vino de Cockburn, uno de los que firmó el manifiesto Ágil).
¿Es esto volver a lo de siempre? Hay gente de equipos técnicos me han comentado que, visto así, la agilidad es lo de siempre, es tener un Scrum Master que es un jefe de proyecto. Yo no lo creo. A diferencia del Jefe de Proyecto clásico, que tomaba decisiones de todo, el Scrum Máster es responsable del proceso, de gestionar la eliminación de impedimentos, de buscar la eliminación de desperdicios.
Pero aunque el Scrum Master tenga la última palabra en, por ejemplo, la manera de estimar… el no estima. Ni decide cómo se harán las cosas. Ni qué tareas deben deducirse de una Historia de Usuario. Las diferencias con el mundo «clásico» son muchas y enumerarlas se va del alcance de este post.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Completamente de acuerdo, el SM debe responder por las ceremonias Ágiles y si algo no se esta cumpliendo debería ser el SM quien pueda decidir en ultima instancia cual es el cambio a incluir en el camino.
Saludos!
Creo que el mayor desafío para el SM será convencer al equipo a que pruebe esa otra propuesta (sea método de estimación o cualquier otra) y que logre que el equipo vea esa mejora en la forma de trabajar. Invitar al equipo a probar otras formas de hacer las cosas es la clave!
Saludos.