¡Llegó el día! tras tres años sin actualizaciones, los creadores de Scrum han decidido actualizar el marco coincidiendo con el 25 aniversario de su presentación oficial. Vamos a analizar los últimos cambios, que han sido muy profundos. En líneas generales, se ha eliminado mucha redundancia, prescripción en favor de ser más claros y directos sobre el propósito de cada uno de los elementos de Scrum. ¡Os lo contamos sección por sección!
Finalidad de la Guía Scrum
La finalidad de la guía ha sido ampliada con respecto al 2017. En esta versión, se explica claramente que el objetivo de Scrum es ayudar a resolver problemas complejos, y no tanto al desarrollo de productos de software, aunque esas fueran sus raíces. Cada elemento de Scrum tiene un propósito. La primera aclaración interesante: Scrum es una base, sobre la que se pueden incluir multitud de prácticas que funcionan, pero, son contextuales. Es decir, cada equipo tiene que buscar su manera de “jugar” a Scrum.
Definición de Scrum
La propia definición de Scrum sufre pequeñas variaciones interesantes. Por un lado, nos habla de que resuelve problemas complejos mediante soluciones adaptativas, en vez de soluciones prescriptivas.
Un cambio importante, es que, la propia definición de Scrum evoluciona, antes se hablaba de que era ligero, fácil de entender y difícil de dominar. Ahora, entra en harina y argumenta que, Scrum requiere de un Scrum Master (desmitificando la idea de que los equipos maduros no necesitan Scrum Master), y que su misión es generar un entorno (pensamiento sistémico) donde:
- El Product Owner ordena el trabajo en el Product Backlog
- El equipo Scrum (al completo, antes comentaba que era el Development Team) convierte el trabajo en incremento que genere valor durante el Sprint.
- El Equipo Scrum y los interesados inspeccionan los resultados y se adaptan para el siguiente Sprint.
- Iteramos.
A continuación, aclara que Scrum es incompleto por definición, cada equipo debe completarlo con las prácticas que le puedan funcionar. Lo único que debe permanecer constante son los cuatro puntos anteriores. Debemos evitar el concepto “manual del empleado” que prescribe detalladamente cómo debemos actuar, en vez de eso, se apuesta por la inteligencia colectiva.
En la versión anterior, se daba una definición de Scrum menos detallada, y se explicaba que el resto de la guía se encargaba de explicar el propio marco.
Usos de Scrum
Este apartado ha sido eliminado en la versión de 2020. No deja de ser curioso, porque fue una de las nuevas secciones de la versión de 2017. Parte de su contenido está explicitado en otras secciones.
Teoría de Scrum
Esta sección sigue apostando porque el empirismo es la base de Scrum. Sin embargo, en la nueva guía se añade el concepto de pensamiento Lean, que trata de eliminar desperdicios en nuestro proceso de trabajo.
Evitando el antiguo concepto de multifuncional (cross-functional en inglés), aclara que los equipos deben contener las habilidades para sacar adelante su producto o bien para adquirir dichas habilidades. Estos equipos trabajan comprometidos mediante iteraciones.
El empirismo requiere de tres pilares fundamentales (los pilares de Scrum): transparencia, inspección y adaptación. En este caso, se hace una redefinición de los tres.
- Transparencia: se da una definición más directa y mejor explicada, en la que se aclara que los artefactos son los encargados de la transparencia, y que con niveles bajos de transparencia las decisiones pueden afectar a la entrega de valor. La transparencia habilita la inspección.
- Inspección: aparece gracias a los eventos, que son oportunidades para inspeccionar. Gracias a ello, podemos detectar desviaciones o problemas. Inspeccionar sin adaptar es inutil.
- Adaptación: Clave para reducir los desperdicios y las desviaciones. Cuanto antes nos adaptemos, mejoraremos las posibilidades de éxito. La adaptación necesita de empoderamiento y autogestión para ser efectiva.
Valores de Scrum
Esta sección ha sido reescrita, aunque se mantienen los mismos valores: coraje, foco, compromiso, apertura y respeto.
Se refuerza la idea de que, estos valores deberían ser reforzados a medida que aplicamos Scrum, y que es necesario actuar con ellos presentes. Debemos tener compromiso para alcanzar los objetivos que nos marquemos. Debemos tener foco en el Sprint para alcanzar dichos objetivos. Debemos estar abiertos (apertura) al trabajo que y restos que aparezcan. Debemos de respetar las capacidades e independencia de nuestros compañeros. Debemos tener coraje para hacer lo correcto.
Esta redefinición, aclara en mayor medida el significado de los valores.
The Scrum Team
En esta sección aparece uno de los grandes cambios. Se elimina el “Development Team” y se crea el rol de “Developer” haciendo referencia a todas aquellas personas que contribuyen al Scrum Team a sacar adelante el producto. Aparece el concepto de Product Goal, el objetivo para el cual construimos nuestro Producto (le da sentido). El Scrum Team es un equipo (generalmente pequeño) que trabaja sin jerarquías ni subequipos para alcanzar dicho Product Goal.
Aparece una aclaración, que generaba confusión, y es que el Scrum Team es autogestionado y multidisciplinar. Es decir, el Scrum Team es el responsable de la creación del producto. En la versión de 2017 muchas personas se confunden a la hora de diferenciar el Scrum Team y el Development Team.
Se elimina la sección sobre el tamaño del equipo. Aún así, se mantiene la recomendación de que los equipos Scrum sean de 10 miembros o menos, porque afecta a su capacidad de comunicarse de manera efectiva.
Los equipos tienen el deber de crear su producto, para lo que tendrían que estar empoderados. Además, son responsables de toda actividad relacionada con su producto, no solo crearlo, también mantenerlo, explotarlo o retirarlo. Dentro del Scrum Team, existen responsabilidades: Scrum Master, Product Owner y Developers. (No hablamos de roles)
Developers (antiguo Development Team)
Los developers son las personas que se encargan de generar el incremento usable. Esto significa, que debemos crear productos que aporten valor, esta aclaración es clave para entender que construir un producto, que no quiere nadie, significa que Scrum no funciona. Se evoluciona de “terminado” a usable, lo que aclara que no se trata de “acabar cosas” sino de “hacer cosas útiles”.
Se ha eliminado las características de un Development Team, y se han añadido sus responsabilidades:
- Crear el Sprint Backlog
- Velar por la calidad (DOD)
- Adaptarse cada día para alcanzar el Sprint Goal
- Ser responsables y profesionales
Product Owner
La sección del Product Owner recibe pequeños matices pero no cambia en esencial. Sigue siendo el responsable de maximizar el valor del Scrum Team (antes era del Development Team). Debe mantener el Product Backlog, es decir:
- Desarrollar y comunicar explícitamente el Product Goal
- Aclarar los PBI (elementos del Product Backlog)
- Mantenerlo transparente y visible
- Disponerlo ordenado
Se sigue aclarando que, aunque puede delegar, sigue siendo el accountable de sus responsabilidades. La organización debe respetar sus decisiones. Los diferentes interesados pueden influir en el Product Owner, pero no pueden “saltárselo”.
Un matiz que no existía en 2017, es que, el Product Owner utiliza la inspección de la Sprint Review para adaptar el producto. Este detalle es importante, ya que el Sprint Review es, desde mi perspectiva, de los eventos peor gestionados por los equipos.
Scrum Master
El Scrum Master sufre pequeños, e interesantes cambios. En esencia, sigue transmitiendo la idea de que, su misión es hacer que el Scrum Team y la organización entiendan Scrum, tal y como se define en la guía. Sin embargo, hay una frase añadida interesante, el Scrum Master es responsable de la efectividad del Scrum Team. Hay una evolución entre líder sirviente (2017) a líder auténtico (2020).
El Scrum Master sirve al Scrum Team (antes era al Development Team) de varias maneras:
- Les enseña a ser autogestionados y multifuncionales (se mantiene)
- Acompaña para crear productos de alto valor (se mantiene)
- Elimina impedimentos (se mantiene)
- Se aclara que, los eventos deben ser productos y útiles, ajustándose al time-box. En la versión de 2017 la explicación era más ambigua.
El Scrum Master sirve al Product Owner de varias maneras:
- Enseñando al Product Owner a definir el Product Goal y a mantener el Product Backlog (se mantiene con matices).
- Haciendo ver la importancia de que los PBIs sean claros (se mantiene).
- Hacer entender que planificamos en un entorno complejo y con empirismo (se mantiene).
- Facilitando la colaboración entre las partes interesadas (se aclara con respecto a 2017).
El Scrum Master sirve a la organización de varias maneras:
- Liderando y organizando la implantación de Scrum en la organización (se mantiene).
- Planificando y asesorando la implantación de Scrum (se mantiene con matices).
- Ayudando a entender a las partes interesadas como trabaja el empirismo para resolver problemas complejos. (se aclara)
- Eliminar barreras entre los interesados y el Scrum Team (se mantiene).
En líneas generales, se mantiene la manera en la que el Scrum Master acompaña al resto de personas, pero con pequeñas aclaraciones y matices.
Los Eventos de Scrum
La introducción a los eventos se ha reescrito, ahora se relacionan mucho con los pilares de Scrum. Se aclara que, los eventos nos permiten inspeccionar y adaptar, y que, en caso de hacerlos mal o no hacerlos, perdemos oportunidades de adaptarnos para ser más efectivos. Se mantiene la idea de que, realizar los eventos con regularidad, debería reducir el resto de reuniones que necesita un equipo para funcionar.
Todos los eventos se realizan a la misma hora y lugar para reducir la complejidad. Esta regla sólo se explicaba en el Daily, pero se extiende al resto.
El Sprint
El Sprint no sufre apenas modificaciones en la versión de 2020. Un detalle menor es que, ahora se habla de que el Sprint es el latido de Scrum, cuando antes se comentaba que era el corazón. El Sprint sigue siendo un periodo inferior a 30 días.
Se sigue aclarando que, durante el Sprint, no debemos añadir cambios que pongan en peligro el Sprint Goal, la calidad no puede disminuir de lo que hayamos fijado, y se puede renegociar el alcance. Se añade una propiedad nueva, durante el Sprint debemos refinar el Product Backlog.
Se mantiene que los Sprints pueden considerar proyectos cortos. Los Sprints deben ser cortos para reducir el riesgo de desviarnos. Además, se elimina la sección de “cancelar Sprint” y se resume en una frase: Es autoridad del Product Owner cancelar un Sprint.
Sprint Planning
La Sprint Planning mantiene su esencia. Es el primer evento del Sprint, y su duración es de 8 horas para Sprints de un mes. Su objetivo es planificar el trabajo del Sprint.
En la versión 2017 se definia que en la Sprint Planning se debían discutir dos topics: ¿Qué vamos a hacer? ¿Cómo lo vamos a hacer?
En esta nueva versión se añade un nuevo topic: ¿Por qué este Sprint crea valor? Es una discusión que tenemos que tener para definir nuestro Sprint Goal. Cada Sprint debe generar un incremento, y este tiene que tener una justificación para asegurarnos que el producto tiene éxito.
En esta nueva versión, se elimina toda referencia a las estimaciones. Los developers son los encargados de decidir “cuánto entra” en el Sprint, en base a su experiencia y su rendimiento pasado.
Se aclara que los developers deben generar el plan para abordar los items seleccionados. Usualmente (no es obligatorio) se pueden descomponer en partes pequeñas de máximo un día de duración. Esta aclaración es interesante, no tenemos porqué dividirlo, en la versión de 2017 parecía que era obligatorio.
La unión del Sprint Goal (topic 1), los items del Product Backlog seleccionado (topic 2) y el plan para conseguir (topic 3) son los componentes del Sprint Backlog.
Se ha desplazo la sección “Sprint Goal” en la versión 2020 hacia los artefactos.
Daily Scrum
La sección de la Daily Scrum ha sido reescrita, aunque mantiene su esencia. El propósito de la Daily Scrum es permitir inspeccionar y adaptar el Sprint Backlog. De esta manera, el equipo trata de organizar su trabajo para ser efectivos y alcanzar el Sprint Goal que se hayan propuesto. Se aclara que, la Daily Scrum puede no ser el único momento para actualizar el Sprint Backlog, durante el día se pueden hacer más actualizaciones.
Se añade un punto interesante, si el Scrum Master o el Product Owner están creando producto, deben participar como developers en la Daily Scrum.
Se han eliminado las famosas tres preguntas. En el 2017 se trató de aclarar que estas preguntas eran una técnica. Dado que, todavía muchos equipos siguen usando esta opción, se han eliminado, y aclara que los equipos deben buscar la técnica que mejor se ajuste a su contexto.
Sprint Review
La Sprint Review ha sufrido una gran reducción en contenido, precisamente para hacer la guía menos prescriptiva. Se han eliminado los ocho topics que debían tratarse, y se ha aclarado el propósito.
La Sprint Review sirve para inspeccionar el resultado del Sprint y generar adaptaciones futuras. El Scrum Team presenta el resultado del producto a los interesados, y juntos analizan el avance hacia el Product Goal.
Se aclara que es una sesión de trabajo conjunta, y que debe quedarse en una mera presentación. El Product Backlog se puede adaptar con nuevas necesidades detectadas. Debemos inspeccionar nuestro producto y que ha cambiado en su entorno.
Su duración sigue siendo de cuatro horas para Sprints de un mes (usualmente menos para Sprint más cortos).
Sprint Retrospective
La Sprint Retrospective también se ha reducido en esta nueva guía, y se ha reescrito para mejorar su entendimiento. El propósito es mejorar la calidad y efectividad del equipo.
Durante la Sprint Retrospective, inspeccionamos a las personas, sus relaciones, procesos y herramientas. Debemos analizar lo que falló y su origen, y aquello que fue bien. Se identifican acciones de mejora. Las que creamos que aportarán más valor, pueden ser añadidas al Sprint Backlog del Sprint siguiente. En la versión 2017 este paso era obligatorio, ahora queda abierto.
La duración sigue siendo de tres horas para Sprint de un mes, y usualmente menos para Sprint más cortos.
Los Artefactos de Scrum
Los artefactos de Scrum mantienen su definición. Su función es aumentar la transparencia, clave para inspeccionar y adaptar en los eventos. Sin embargo, en esta nueva versión se añade el concepto de compromiso. Cada artefacto tiene un compromiso que asegura que genera transparencia.
- El Product Backlog con el Product Goal
- El Sprint Backlog con el Sprint Goal
- El Incremento con el Definition of Done
Product Backlog
El Product Backlog mantiene su esencia, sigue siendo una lista ordenada que es la fuente de trabajo para todo el Scrum Team. Los items pueden considerarse “ready” para el siguiente Sprint gracias al refinamiento. El refinamiento consiste en trabajar los PBIs en elementos más pequeños y manejables.
Por tanto, el refinamiento es modificado, siendo una actividad de todo el Scrum Team, necesaria para dejar “ready” los items que queramos abordar. Los atributos de los PBIs quedan abiertos al contexto del equipo.
El tamaño que deben tener los items, lo determinan los developers, aunque el Product Owner puede ayudar a clarificar.
Compromiso: El Product Goal
El Product Goal describe un estado futuro de nuestro producto, que sirve de guía al Scrum Team para sus planificaciones. Esta meta está dentro del Product Backlog, dejando como emergente los PBIs que necesitemos para alcanzarla.
Se aclara que con Scrum desarrollamos Producto, y que este puede ser un servicio o un bien físico. Solo debemos tener un Product Goal, y si lo abandonamos o lo conseguimos, podremos definir otro.
Sprint Backlog
El Sprint Backlog se aclara más en la nueva guía, y se reduce su contenido. El Sprint Backlog contiene el Sprint Goal, los PBIs seleccioandos y el plan para acometerlos.
El Sprint Backlog debe tener el detalle suficiente para que los Developers puedan inspeccionar su trabajo y saber si están alcanzando el Sprint Goal marcado.
Compromiso: Sprint Goal
La sección antigua (2017) del Sprint goal se ha desplazado a esta parte de la guía. En esencia se mantiene el mismo concepto de Sprint Goal. Solo debe haber uno, y supone un compromiso para los Developers (esto aclara muchas dudas). Eso sí, debe permitir que haya muchas maneras de conseguirlo, de manera que el Sprint Backlog sea flexible. En el caso de que los Developers crean que no van a poder alcanzarlo, deben renegociar con el Product Owner las tareas, sin afectar al Sprint Goal.
Incremento
El incremento es aclarado y reescrito. Cada incremento debe ser un paso hacia el Product Goal que nos hayamos fijado. Debemos asegurar que un nuevo incremento funciona con el resto. Se aclara que, durante el Sprint, se pueden generar muchos incrementos, y que estos se presentarán juntos en la Sprint Review al finalizar el Sprint. Había mucha confusión sobre “cuándo se entregaba el incremento”. De hecho, se aclara que la Sprint Review no es el momento de “aprobar el incremento”. Un trabajo que no cumple la Definition of Done, no se considera parte del incremento.
Compromiso: Definition of Done
La Definition of Done es una descripción formal del estado del Incremento cuando alcanza las medidas de calidad requeridas para el producto.
Todo trabajo que cumpla la Definition of Done, se considera incremento, y puede ser presentado en el Sprint Review. Todo elemento que no lo cumpla, volverá al Product Backlog para tratarlo en el futuro.
Se aclara que la organización puede tener estándares que afecten a la Definition of Done. El Scrum Team debe de definir su DOD adecuado para su producto. Anteriormente esta función era del Development Team.
Nota Final
La nota final se mantiene, podemos coger partes de Scrum y puede que nos funcione, pero el resultado no es Scrum.
¿Qué os ha parecido la nueva guía?
