Scrum funciona porque propone una serie de actividades que es necesario ejecutar de una manera determinada. Aquí explicaremos cómo, quien, cuándo y por qué se llevan a cabo estas actividades.
La base de todas las actividades de Scrum es el Sprint. El Sprint es la pieza a partir de la cual organizaremos el trabajo en un marco de trabajo que favorezca la focalización, la atención a la calidad y a la entrega de valor de forma continuada.
El Sprint es el tiempo que el equipo otorga para la construcción de una pequeña parte del producto. Suficientemente pequeña para que sea perfectamente entendible por el equipo y no supere el horizonte de previsión. Y suficientemente grande cómo para proporcionar un incremento de valor para los destinatarios del producto.
El Sprint, además, puede verse desde otra perspectiva. Cómo un gran contenedor. El equipo encuentra pautadas todas las actividades necesarias para conseguir el objetivo de entregar un incremento de valor al finalizar el Sprint. Hay tres actividades ampliamente conocidas y claramente visibles en cada Sprint:
Estas actividades se caracterizan por ejecutarse una única vez a cada Sprint. Pero además, hay dos actividades más que se llevan a cabo a lo largo del Sprint, y que se ejecutan diversas veces a lo largo del mismo:
A lo largo de este artículo explicaremos cada una de estas actividades.
El horizonte de previsión corresponde a uno de los principios esenciales de la teoría de control de procesos empíricos (empirismo) que, recordemos, es la piedra filosofal del marco de trabajo Scrum. El horizonte de previsión dice que hay un momento en el futuro en que, si ocurre un hecho inesperado, este puede tener repercusiones negativas sobre el trabajo que estamos haciendo ahora.
Este horizonte no conviene superarlo si queremos fomentar equipos que puedan focalizarse en la creación de incrementos de valor de forma iterativa. Y se mide en semanas (nunca en meses). Es por esto que Scrum basa la duración del Sprint en una horquilla de tiempo que va de 1 a 4 semanas. Scrum afirma que un cambio no es más que más trabajo en el Backlog. Esto solo es posible si trabajamos en iteraciones de tiempo que permitan tener control del horizonte de previsión.
Un MVP (Minimum Valuable Product o Minimum Viable Product) es la pieza mínima objetivo de un Sprint. Cuándo hablamos que el Sprint favorece la creación de un incremento de valor, nos referimos a que este incremento ha de proporcionar un beneficio tangible a los destinatarios del producto. Nosotros, cómo equipo, y junto a los destinatarios del producto, adquirimos un compromiso bidireccional:
No puede haber una cosa sin la otra. No puede haber valor si los destinatarios no nos den feedback. No puede haber uso si el equipo no es capaz de proporcionar valor.
Pero, que es “incremento de valor”?
El siguiente esquema intenta dar una respuesta:
| Incremento | Valor | |
|---|---|---|
 |
 |
En la primera ilustración tenemos un ejemplo de producto incremental, que tiene cómo objetivo la construcción de un vehículo. Para hacer realidad este objetivo último, se propone una política de incrementos consistente en proporcionar “piezas” del vehículo perfectamente funcionales. Así se plantea proporcionar en primera instancia las ruedas, posteriormente el chasis, la carrocería y, finalmente, el deseado vehículo completo.
La pregunta que seguramente muchos os estáis haciendo es: Qué utilidad tiene para el destinatario de este vehículo que le proponemos una rueda? Por muy perfectas que sean. Por mucho que cumplan los criterios de calidad más exigentes, nadie hace nada específico con unas ruedas. Este es un ejemplo de que podemos entregar un producto en periodos iterativos, pero no por ese motivo seremos ágiles. La agilidad ha de prever otros factores necesarios. Y uno muy importante es el valor continuo (MVP)
En el segundo ejemplo podemos ver que la estrategia es diferente. Para proporcionar este vehículo, se proporcionan partes intermedias que, por si solas, resuelven alguna necesidad específica. Supongo que alguien debe estar pensando. ¡¡Si ok!! ¡¡Pero esto tiene un precio!! Parece que se requiere de más esfuerzo en esta última estrategia respecto a la primera. Es cierto. Requiere de esfuerzo por parte de todos:
A veces no es posible dar valor al finalizar un Sprint. Bien sea porque el sprint es muy corto. O porque provoca muchas molestias en un producto que puede ser crítico. O porque operativamente es muy difícil hacer la publicación de los incrementos a cada Sprint. Sea como sea, hay ocasiones en que el Scrum Team puede pactar una política de releases. La release no es mas que la suma del valor obtenido en diversos Sprints.
Esta política es variable y puede someterse a cambios o a la conveniencia del equipo o de la organización. Así, en un proyecto, puede establecerse una release de los sprints 1 y 2, posteriormente una release del sprint 3, para acabar con una release de los sprints 4, 5 y 6. Cualquier combinación sería válida siempre y cuándo sea producto del consenso del Scrum Team.
La Release no puede servir de justificación para alterar cualquiera de las actividades de Scrum. Si en un Sprint no se publicará el valor obtenido, no quiere decir que el Sprint Review no se realice de forma completa y con la participación del Product Owner y de los Stakeholders.
(+info Sprint Planning. Detalls que necesitas conocer)
El Sprint Planning es la primera actividad que es necesario ejecutar siempre en el inicio de cada Sprint. El Sprint Planning tiene cómo objetivo organizar el trabajo para aquel Sprint. Permite a los técnicos focalizarse en un objetivo pequeño, asumible, técnica y organizativamente, y de valor. Para conseguir este objetivo, el equipo dispone de 8 horas de tiempo para sprints de 4 semanas.
En esta actividad asisten el Product Owner, el equipo técnico y el Scrum Master. La reunión ha de ser liderada por el equipo técnico, el cual se compromete a disponer de la información y a haber trabajado los temas necesarios para poder ejecutar esta actividad de forma efectiva. Esto implica forzosamente que el equipo, durante el Sprint anterior, ha de haber trabajado de forma completa al menos todas las historias de usuario más prioritarias.
(+info Sprint Review. Detalls que necesitas conocer)
Una vez el Sprint llega a su última jornada. Llega el momento de someter a inspección el resultado de nuestro trabajo. El Sprint Review es el momento de mostrar el incremento, y demostrar su valor y su calidad. Directamente a los destinatarios del producto (sin intermediarios).
El Sprint Review es la reunión más coral de todas las existentes. Tiene una duración máxima de 4 horas para sprints de 4 semanas Tiempo más que suficiente par poder mostrar el incremento construido. Esta reunión está liderada por el Product Owner. Y debe asistir todo el mundo. Especialmente una parte suficientemente representativa de los destinatarios del producto (los stakeholders más impactados por el incremento). El Product Owner no puede ejercer de Stakeholder en esta reunión. Algunos de los técnicos y el Scrum Master también deben asistir.
No se trata de hacer una demo. Y no se trata de hacer una aceptación con datos maquillados. Se trata de que los stakeholders toquen el producto en un entorno realista y comprueben los criterios de aceptación que permitan dar una aceptación firme.
El Product Owner que lleva la agenda de la reunión, e invita a las personas que crea conveniente
(+info Sprint Retrospective. Detalls que necesitas conocer)
La Sprint Retrospective es la actividad específicamente diseñada para que el equipo tenga un espacio para la búsqueda de la mejora continua. La mejora continua se lleva a cabo desde múltiples perspectivas:
El concepto de mejora continua guarda relación con la teoría de control de procesos empíricos, y fue definida por primera vez en los años 50 por Edwuards W Deming, con lo que se conoce como ciclo de Deming o PDCA
El ciclo de Deming propone que, si queremos mejorar cualquier aspecto de nuestro trabajo, debemos añadir dos acciones a las ya conocidas de “Planificar” y “Ejecutar”. Si solo planificamos y ejecutamos, no tenemos espacios ni motivos para hallar aspectos de mejora sobre lo que hemos hecho. Así Deming plantea dos acciones nuevas:
En Scrum, la actividad del Sprint Review permite realizar esta función de inspección. Y la actividad de Retrospectiva permite buscar y planificar las acciones de adaptación que permitan mejorar en las iteraciones siguientes.
Una retrospectiva centrada en los problemas no es una buena retrospectiva. Es deseable generar entorno de grupo y motivación. Y es por eso que los éxitos deben celebrarse siempre.
El Scrum Master es el responsable de organizar la reunión y crear la dinámica para extraer aspectos de mejora útiles para el equipo.
Una lista de propuestas o de acciones. De las cuales ha de existir el compromiso de aplicar alguna de estas mejoras en el siguiente sprint. No existe mejora continua sin trabajo. O dicho de otra manera: Al Sprint siguiente deben existir acciones tangibles centradas en la aplicación de pequeñas mejoras. Estas acciones pueden ser de naturaleza muy diversa:
etc.
Curiosamente, inmediatamente después de una retrospectiva no se inicia un nuevo sprint. Generalmente, hay unas horas muertas que pueden tener utilidades muy provechosas:
(+info La Daily. Detalls que necesitas conocer)
La Daily es una reunión diaria y rápida que permite la sincronización de los técnicos que participan en el proyecto. Es una reunión necesaria que, si se hace correctamente, marcará un antes y un después en la relación con y entre los técnicos. Después de muchos años de trabajo secuencial y reactivo, es habitual encontrar que los técnicos tienen problemas a la hora de comunicarse con sus compañeros. Se establece un mecanismo de encargo que provoca que los técnicos se centren en su trabajo particular, y no se preocupan por la integración y la sincronización con el trabajo del resto del equipo. Podría decirse que se ha favorecido durante años que la gente se encierre en su cueva particular.
La Daily pretende ayudar a resolver esto y a fomentar el verdadero compromiso del equipo, por encima de la simple implicación. Para conseguir esto se propone que los técnicos, diariamente, comparten la situación de su trabajo, y colaboren para avanzar en un objetivo común: Proporcionar valor a plazos cortos de tiempo.
Los técnicos. Y únicamente ellos en favor del poder auto-organizativo que ostentan. El Scrum Master puede asistir a las Dailys de forma voluntaria. El Product Owner y los Stakeholders extrañamente tendrán motivo para asistir a una Daily.
Usualmente, las reuniones de Daily se llevan a cabo al principio de la jornada laboral. Para que los técnicos puedan sincronizarse y seguir con su jornada con información actualizada.
(+info Refinement. Detalls que necesitas conocer)
El Refinement es quizás la actividad más desconocida en Scrum. No tiene una única motivación. Y sirve para hacer todo aquello que no haríamos en cualquier otra reunión de las descritas anteriormente. La duración también es variable. Existe una recomendación de que una reunión de refinement no supere 1 hora de duración. Siempre que sea posible, seguimos este consejo, ya que la atención de los asistentes a la reunión disminuye mucho pasada la primera hora.
Por otro lado, se recomienda no hacer reuniones de refinement por un tiempo global que supere el 10% de la duración del Sprint. Es decir, para jornadas tradicionales de 8 horas diarias y sprints de 15 días, no deberíamos superar una duración global de reuniones de Refinement por encima de las 8 horas. Si superamos este límite, probablemente estamos afectando a la normal ejecución del Sprint. Y estaríamos comprometiendo los objetivos del Sprint.
Como la motivación no está clara, no existe un único responsable de la reunión. La responsabilidad la tendrá la persona con mayor interés para que la reunión tenga lugar.
Muy importante mantener siempre el Product Backlog actualizado con los cambios o nueva información que hemos obtenido en la reunión.
(+info Mapa de actividades Scrum)
Habitualmente cuelgo este diagrama en los tableros físicos, o en los repositorios de trabajo, para que todo el equipo sea conocedor de las actividades, objetivos, responsables y tempos que todo el mundo en el proyecto debería conocer. Esto no substituye las múltiples acciones de formación i fomento que cómo Scrum Master siempre deberíamos tener a la agenda. Pero ayuda bastante que el equipo tenga acceso a estos esquemas.
Descarga el esquema para imprimir aquí
