SCRUM Guide 2020

Coincidiendo con el 25 aniversario de Scrum, tras tres largos años sin actualizaciones, nuestra Guía Scrum favorita, ha recibido una actualización por parte de sus creadores Jeff Sutherland y Ken Schwaber. Quedémonos con la parte positiva del asunto y con el famoso refrán, “nunca es tarde, si la dicha es buena”, y vaya que si es buena en este caso. 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 desgranar en detalle los cambios principales que la versión de 2020 ha introducido en Scrum. Empezaremos por los más obvios, fáciles de observar a primera “lectura”.

Primeras impresiones

La Guía ya de por sí escueta, ahora lo es aún más. Esto viene de la mano de 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, tema capital. Por ejemplo, los que me han parecido más relevantes son:
a. “Roles” se sustituye por “Responsabilidades”. ¡Ahí es nada!

b. ‘Development Team’ desaparece y se convierte en ‘Developers’, entiendo que en parte para evitar las confusiones existentes con el ‘Scrum Team’ y disolver el concepto del equipo dentro del equipo.

c. Los términos “accountable” y “responsible” se usan de forma más coherente.

d. Autogestión y autoorganización, se circunscriben de una manera más clara al “quién y cómo” hacer el trabajo.

e. Se introduce el término “objetivo del producto”, ‘Product Goal’, que sirve para definir un objetivo del mismo y apuntar un estado futuro.

f. Los 3 artefactos presentes en la Guía de Scrum: ‘Product Backlog’, ‘Sprint Backlog’ e 'Incremento', tienen asociados un compromiso específico: ‘Product Goal’, ‘Sprint Goal’ y ‘Definition of Done’.

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 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 de la involucración, 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 generalmente generaba debate y malos entendimientos.

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.

Pilares

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:

· La transparencia se consigue a través de los artefactos y la ausencia de la misma afecta directamente a la entrega de valor. Sin transparencia, no hay inspección.

· La inspección se consigue a través de los eventos. Sin inspección, no hay adaptación.

· La adaptación incorpora el concepto Lean que hemos comentado antes, y ahonda en que este pilar es capital a la hora de la eliminación de desperdicios y pone foco en lo capital de este pilar en el éxito del producto.

Valores

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. Quizá el cambio estrella, no sé, el tiempo lo dirá. La Guía se “carga” el tan famoso ‘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. Bienvenido sea el cambio que constata una realidad patente.

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 mantenga 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, al menos en mi opinión, 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 si cabe aún más foco en las expectativas del mismo.

Roles y ceremonias

Para continuar, vamos a darle un repaso a los roles y eventos en la nueva Guía.

El ‘Scrum Máster’ sufre sutiles cambios. El más destacado quizá 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 rol de ‘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 sólo de desarrollarlo, si no también de comunicarlo explícitamente. Queda claro pues, que el ‘Product Goal’ no es una foto estática, si no 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, al igual que antaño, 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?’. Curioramente, al menos para mí, 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, al menos en mi percepción, uno de los elementos más reconocibles 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’. Veremos este punto como lo hacemos funcionar en vivo.

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 desparecido 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’, ceremonia que a los que seguís mis artículos sabéis que le tengo cariño y le doy una importancia especial, 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. Este punto concreto, por el momento y a priori, es el único punto con el que no me encuentro cómodo en esta revisión. Habrá que madurarlo y entender bien el por qué de esta decisión.

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 manera, 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.

Artefactos

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

Cada uno de ellos, como decíamos al principio, 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, 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 más 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’, el nuevo invitado a la fiesta, 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 producto, este puede ser algo tangible o un servicio, otra excelente aclaración que amplía el ámbito de actuación de Scrum, algo que ya habréis ido observando, es el tema de fondo de esta nueva revisión.

El ‘Sprint Backlog’ recibe aclaraciones adicionales en esta revisión, pero en esencia se mantiene igual.

En este caso el compromiso asociado, un viejo conocido, el ‘Sprint Goal’, al igual que su artefacto asociado, no contiene cambios de relevancia. Estabilidad en esta pareja artefacto, compromiso, que dicho sea de paso, parece algo razonable ya que funcionaban, a mi parecer, estupendamente.

Para acabar el Incremento, recibe una completa reescritura.. Respecto al mismo se deja claro, como decíamos anteriormente, que se pueden generar varios incrementos dentro del Sprint, siendo eso sí, todos presentados “en sociedad”, en la ‘Review’. Se aclara a este respecto también, que no es la ‘Review’ el instrumento para aprobar incrementos, 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’ ( aunque ya no existe como tal ), que era el encargado antaño.

Conclusión

Creo que es una revisión que contiene elementos mayormente esperados y que dicen mucho de lo atentos que están Jeff y Ken (permitidme la licencia de tratarlos casi como viejos amigos), 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.

Si bien, podemos poner un pero al espacio de tiempo entre revisiones de la Guía. Esto ya pasó anteriormente, entre 2013 y 2016, 3 largos años, pero en el punto en el que se encuentra Scrum actualmente, que no es el de 2013, esperar 3 años para hacer una revisión del marco de trabajo, en mi opinión es esperar demasiado.

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.