Guía Scrum 2020 – Análisis de sus Cambios

Coincidiendo con el 25 aniversario de Scrum, la Guía Scrum ha recibido una actualización por parte de sus creadores Jeff Sutherland y Ken Schwaber. En mi opinión, los cambios son tremendamente acertados y en la línea que creo demandaba la comunidad ágil y todos aquellos que usan o están pensando en usar Scrum.

Vamos a ver en detalle los cambios principales que la versión del año 2020 ha introducido en Scrum.

La guía ya de por sí escueta, ahora lo es aún más. Esta viene de la mano con la eliminación de redundancia y de una concreción aún mayor. Pasamos de 19 páginas que tenía la Guía en 2017, a las 14 de esta versión. Ligereza aún mayor y mensajes mucho más directos y concisos.

Hay cambios importantes en la terminología. Los que me han parecido más relevantes son:

Hay una clara disminución en la orientación a productos “software” en esta versión de la Guía Scrum. Ya desde la definición que se hace de la finalidad de la propia Guía se deja de soslayo el antiguo objetivo fundacional del producto software, y en esta revisión se deja en un enfoque genérico relacionado con la ayuda a la resolución de problemas complejos. Sin duda, esto es algo que el mercado y la propia comunidad llevaba demandando hace bastante tiempo, dado que cada vez se observa más claramente el uso de Scrum más allá del desarrollo de activos tecnológicos, en una conquista constante de nuevos terrenos dentro de las organizaciones.

También se trata de resolver otro tema largamente debatido en Scrum aclarando de una vez por todas que el “Scrum Master” es un rol necesario aún en equipos maduros.

Hay ligeros cambios acerca del involucramiento, no sólo como antiguamente del “Development Team”, ahora “Developers”, en la construcción del incremento, pasando ahora a explicitar claramente que es el “Scrum Team” al completo el responsable de esa generación.

Se aclara el hecho de la posible entrega múltiple dentro de un Sprint, incluso durante el mismo, dejando manifiesta esa posibilidad. Este era otro de los temas que generaba debates y malos entendidos.

Otro tema muy importante desde mi punto de vista, es la inclusión del pensamiento Lean dentro de la base de Scrum. El empirismo sigue siendo la base sólida de Scrum. Eso no cambia, pero Lean aparece para tratar de aportar en el ámbito de la eliminación de desperdicios dentro del proceso de trabajo Scrum.

Respecto a los pilares de transparencia, inspección y adaptación, hay también ligeros cambios en cada uno de ellos. En este caso, son más bien aclaraciones y puntualizaciones, que dejan claros temas como:

Aunque permanecen los mismos cinco anteriores, sí que es cierto que la sección de la Guía ha sido completamente reescrita. Esta nueva redacción simplemente trata de aclarar más el papel y significado concreto de cada uno de ellos.
Vamos a detenernos un poco en uno de los cambios más notorios y que más va a impactar en Scrum tras la salida de la nueva Guía. La Guía elimina el “Development Team” y pasamos a llamarlo simplemente “Developers”. Sinceramente creo que aquí ha faltado un poco de arrojo para dar ya el paso definitivo y cambiar una terminología que claramente alude al mundo del software, aunque su pura definición no lo haga.
En este paso hacia la minoración del “tufillo” a software de versiones anteriores de la Guía y en un claro cambio de rumbo para conquistar nuevos territorios dentro de las organizaciones, algo que en la práctica está más que asentado, este redefinido rol de “Developer” aglutina a toda persona que contribuye al “Scrum Team” a construir el producto, sea esta un desarrollador de software o no. Esto en la práctica creo que era de común entendimiento que así podía ser y cada vez se extendían más los equipos Scrum en los que no existía un perfil tecnológico o este era residual.

Alrededor de este tema también hay que hacer mención especial a la eliminación en la Guía de la referencia explícita al tamaño del equipo. Aunque sí se mantiene la recomendación acerca del tamaño del mismo.

Otro tema no menos importante, quizá sólo un paso por detrás del cambio que acabamos de mencionar, es la aparición estrella del “Product Goal”. Creo sinceramente que esta adición es más importante de lo que parece. Por un lado, ofrece una tranquilizadora simetría con el “Sprint Goal”, dejando este último en el terreno de lo táctico y situando al nuevo invitado a la fiesta en el de lo “estratégico”. El disponer de esta nueva meta a nivel de producto aumenta la transparencia enormemente y visibiliza de manera patente qué es lo que se espera del producto, poniendo foco en las expectativas del mismo.

El “Scrum Master” sufre sutiles cambios. El más destacado quizás es un añadido que deja claro que este rol es el responsable de la efectividad del “Scrum Team”, una clara evolución en su papel de liderazgo.

El “Product Owner” queda impactado por la aparición del “Product Goal”, sobre el que la Guía dice que este rol es el encargado, no solo de desarrollarlo, sino también de comunicarlo explícitamente. Queda claro pues que el “Product Goal” no es una foto estática, sino que es cambiante en el tiempo. Y aquí la Guía también deja claro que esta meta debe mantenerse hasta que se alcance, o se vuelva obsoleta, y haya que moverse a una nueva.

Los “Developers”, el nuevo rol, se focaliza en un grupo de personas que tienen la misión de construir el incremento. La nueva Guía sí que hace hincapié en que estos incrementos han de ser realmente de valor y que, si no existe este en el incremento, no estamos haciendo Scrum de la manera adecuada. También cambia el “terminado” por “usable”, lo que sin duda aterriza el concepto de que si lo que construimos no es usable, el propósito no se habrá alcanzado.

Respecto a las ceremonias, esta versión no contempla ninguna incorporación o salida, algo previsible dado que lo que hay funciona perfectamente.

El “Sprint Planning” no recibe grandes cambios. El más notable es el añadido en relación a las preguntas que hacernos en esta ceremonia, a las que se añade a las habituales de “Qué vamos a hacer” y “Cómo lo vamos a hacer”, una nueva pregunta que es “Por qué este Sprint genera valor”. Curiosamente, se elimina toda referencia a las estimaciones durante esta reunión, dejando ese papel a los Developers y basándolo en su experiencia previa y en el histórico pasado de rendimiento.

La “Daily Scrum” se ha reescrito por completo y se han eliminado las famosas tres preguntas tradicionales. Sin duda, otro de los grandes cambios de esta nueva revisión, ya que uno de los elementos más reconocible en Scrum son estas preguntas. Ya en el pasado se indicaba que el uso de las preguntas era más una facilitación que una obligación metodológica. Pero la verdad es que, en la realidad, las preguntas han persistido de manera encomiable.

Otro cambio reseñable en la “Daily” es que se aclara que tanto el “Product Owner” y el “Scrum Master”, en caso de estar participando de manera activa en la creación del producto, cosa que ocurre más frecuentemente en la realidad de lo que pudiera parecer, pueden y deben estar presentes en la Daily, pero con el rol de “Developer”.

Lo primero que se observa acerca de la “Sprint Review” es que en la Guía ha sufrido una considerable reducción de literatura. En el mismo sentido que se observa en el resto del documento, que hace un esfuerzo por tener un carácter menos prescriptivo y más abstracto, en este caso los ocho puntos que se explicitaban en la Guía de 2017, han desaparecido en esta. En esencia, la “Review” conserva todo su contenido, aunque parece potenciarse más si cabe el carácter de demo de la ceremonia.

La “Sprint Retrospective” también ha visto reducida su redacción y ha recibido además una reescritura completa en aras de aclarar sus objetivos. El cambio fundamental se encuentra en que el implementar las mejoras identificadas en el siguiente Sprint era un paso de obligado cumplimiento en la Guía de 2017, mientras que en esta revisión se deja en opcional.

Vamos con el contenedor de todo, el “Sprint”, que es uno de los elementos que menos cambios sufre en esta revisión de 2020. Los dos grandes cambios, por llamarlos de alguna forma, más bien serían matizaciones, sobre todo la primera, de la denominación del “Sprint”, que pasa a ser el “latido” de Scrum, cuando antes se consideraba el “corazón”, y la eliminación de la sección de cancelación de Sprint, para pasar a resumirla en una sola frase que dicta tajantemente: “Es autoridad del Product Owner” cancelar un “Sprint”, sin más.

Para terminar, vamos a dar un repaso rápido a los artefactos, nuestros queridos “Product Backlog”, “Sprint Backlog” e Incremento.

Cada uno de ellos conlleva asociado un compromiso: el del “Product Backlog” es el recién introducido “Product Goal”, el del “Sprint Backlog” es el “Sprint Goal” y el del Incremento es el “Definition of Done”. El aporte de estos compromisos impacta directamente en el pilar de la transparencia. La aparición del “Product Goal”, más allá de las virtudes obvias, aporta una simetría que simplifica el marco metodológico.

Los cambios en el “Product Backlog” son mínimos. Aparece de una manera destacada el hecho de definir algunos elementos del mismo como “listos” para ser candidatos a ser seleccionados en el “Sprint Planning”. Acerca de este estado de listo, la Guía indica que se alcanza vía el refinamiento, una aclaración muy importante.

Su compromiso asociado, el “Product Goal”, se presenta como la descripción de un estado futuro deseado para nuestro producto, y que este se mantiene constante hasta que se alcanza, cuando debe aparecer uno nuevo. También se aclara que, aunque en Scrum desarrollamos un producto, este puede ser algo tangible o un servicio, otra excelente aclaración que amplía el ámbito de actuación de Scrum.

El “Sprint Backlog” recibe aclaraciones adicionales en esta revisión, pero en esencia se mantiene igual. En este caso, el compromiso asociado, el “Sprint Goal”, al igual que su artefacto asociado, no contiene cambios de relevancia.

Para acabar, el Incremento recibe una completa reescritura. Respeto al mismo se deja claro que se pueden generar varios incrementos dentro del Sprint, siendo todos presentados en la “Review”. Se aclara también que no es la “Review” el instrumento para aprobar Incrementos sino que es el “Definition of Done” el que dilucida qué se considera un incremento válido.

Respecto al “Definition of Done”, compromiso del Incremento, el cambio fundamental es que es responsabilidad de todo el “Scrum Team” la definición de su DoD, no el “Development Team” que era el encargado antaño.

Creo que es una revisión que contiene elementos mayormente esperados y que dicen mucho de lo atentos que están Jeff y Ken a lo que ocurre en el mercado con Scrum. Esta capacidad de escuchar y adaptar convenientemente el marco de trabajo es encomiable porque además se hace sin estridencias, sin grandes cambios de timón que pongan en peligro lo construido hasta ahora. Estos cambios que hemos comentado en el artículo, diría que la mayoría, en gran medida estaban presentes en la comunidad y en muchos de los proyectos gobernados con Scrum.

Los cambios y adaptaciones suman y no restan, salvo el que he comentado anteriormente respecto al carácter optativo de la inclusión de mejoras observadas en la retrospectiva para el siguiente Sprint.

Una revisión, como ellos mismos dicen, menos prescriptiva y con un lenguaje simplificado para llegar a una mayor audiencia, sin duda acompañado de la eliminación sustancial de parte del “aroma” a software que enraizaba la Guía y Scrum.

En definitiva, como gran titular, un paso adelante hacia un horizonte más amplio.