A menudo pensamos que el Scrum Master es el que debe hacerlo.

Y, sí, el Scrum Master puede facilitar cuando sea necesario, y lo hará en mayor medida con equipos que están empezando (en la etapa de forming o formación, si seguimos el modelo de Tuckman).

Pero no es quien debe facilitar siempre y todo.

Se trata de que la gente se autogestione y asuma su accountability, su responsabilidad, también a la hora de conducir los eventos.

Mis “por defecto” respecto a quien debe facilitar cada evento en Scrum:

👉 Sprint Planning: el Scrum Master facilita. Porque es uno de los eventos más complejos, con muchos input (Product Backlog, capacidad del equipo y rendimiento pasado, Definición de Hecho, el Incremento en sí, mejoras identificadas en la Retrospectiva), y con posible “tensión” entre Product Owner y Desarrolladores, que tienen que negociar y ponerse de acuerdo en cuanto al Objetivo del Sprint y a los elementos del Product Backlog a seleccionar para el Sprint.

👉 Daily Scrum: los Desarrolladores la facilitan. La Daily es por y para los Desarrolladores. Ellos deciden quién y cómo facilitarla. El Scrum Master puede facilitar con equipos nuevos, para luego ir “retirándose” y quedar como observador.

👉 Sprint Review: el Product Owner. El Product Owner es el anfitrión de la Sprint Review. Quien debe invitar a los stakeholders y el principal interesado en recabar feedback para decidir qué hacer en el siguiente Sprint.

👉 Sprint Retrospective: cualquier miembro del equipo Scrum. Es muy común que el Scrum Master sea quien facilite las Retrospectiva. Sin embargo, esto complica que el Scrum Master pueda participar como un contribuyente más a la sesión, aun cuando puede que tenga mucho que aportar.

El Scrum Master sigue siendo “accountable” respecto a que los eventos sean productivos, aunque la facilitación la asuman otros.