Revisar lo que no funciona y mejorarlo es necesario. Inspección y adaptación, en jerga Scrum. Hasta ahí, creo que todos de acuerdo. Lo que me pregunto es si la actualización de 2020 de la Guía Scrum sirve para resolver las “anti-patterns” que intenta combatir, o si más bien contribuye a crear otras nuevas. Tengo sentimientos encontrados respecto a esta actualización, que es de un calado considerable. Veo aspectos positivos y otros que no lo son tanto.

[Update 01/12/2020:

A medida que empiezo a usar la nueva Guía y que las nuevas ideas se asientan, cada vez me gusta más. Las luces superan a las sombras. Llego a la conclusión de que la Guía Scrum 2020 es mejor que la versión de 2017, por dos motivos:

1/ En general, pone mucho más énfasis en el porqué de las cosas. ¿Por qué merece la pena que creemos este producto? Los mejores equipos en los que he trabajado siempre han tenido un propósito claro que le daba sentido a todo. Es muy positivo que la Guía recalque este aspecto. No podemos dejar que Scrum simplemente nos lleve a crear un producto rápido y de gran calidad técnica, pero que ningún cliente quiere.

2/ En general, la redacción es más amena que la de su predecesora.]

Es una versión de la Guía Scrum más breve, pues pasa de 19 a 13 páginas, y supuestamente más concisa y menos prescriptiva. ¿Y por qué es bueno que sea aún más sucinta y quizás menos prescriptiva, si la Guía aspira a darnos “the rules of the game”? Eso es lo que no sé si está tan claro, y solo se entiende en un contexto en el que los creadores de Scrum buscan la expansión de su criatura más allá del mundo del software. “Me siento mucho más cómodo dando esta Guía a un equipo de ventas”, dice Jeff Sutherland. Este es el gran objetivo tras la reciente actualización, hacer Scrum más universal, más main stream.

Mi duda es si, al intentar hacerla más accesible para equipos de trabajo en cualquier ámbito, no se ha perdido utilidad en lo que a software se refiere. Una cosa es la brevedad, y otra es que resulte parca en detalles o tan flexible que cualquier cosa valga. Esta Guía es menos descriptiva que la anterior. Comparto, eso sí, la visión de Sutherland cuando explica que “Scrum es una herramienta para construir mejores empresas”. El uso de Scrum no tiene por qué limitarse al departamento de IT.

A continuación hago un repaso de los cambios y comparto mis primeras impresiones sobre ellos. ¡Que nadie se ofenda, es solo mi opinión! Vayamos apartado por apartado.

Purpose of the Scrum Guide

Nada nuevo bajo el sol. Esta sección se expande para hacer mención a la evolución de Scrum desde los 90 y para incidir en una mención que anteriormente solo estaba al final de la Guía: si alteramos partes esenciales de Scrum esteremos limitando sus beneficios o, incluso, haciendo que sea inútil.

Scrum Definition

Sin novedades.

Uses of Scrum

Este apartado se elimina. Tiene sentido, ya en la Guía de 2017 no aportaba demasiado.

Scrum Theory

Nada nuevo, salvo una mención a que Scrum se basa, además de en el empirismo, en el “lean thinking”. Supongo que no han podido resistirse a incluir el término “lean” en alguna parte. O que han querido justificar como un logro el recorte de páginas. O reflejar el trabajo que Scrum Inc. hace con Toyota.

Scrum values

Nada nuevo.

Scrum Team

Aquí sí que hay cambios relevantes. Veamos:

– Ya no hay roles. Ahora se habla de tres tipos de “accountabilities” (responsabilidades) dentro del Scrum Team. Esta es una respuesta a la «titulitis» de la que viene padeciendo el mundo Agile. Si, por ejemplo, tu puesto de trabajo es el de «project manager» pero asumes las responsabilidades de un Scrum Master, a efectos de Scrum eres Scrum Master.

– El “Development Team” pasa a ser “Developers”. Con esta actualización se quiere poner el énfasis en el Equipo Scrum en su totalidad, evitando la posible tensión y división entre Product Owner y Equipo de Desarrollo, con el Scrum Master en medio, mediando entre unos y otros. Pensamos en la típica Sprint Review en la que el Product Owner “regaña” al Equipo de Desarrollo por no tener lo que dijeron que iban a tener (que siempre ha sido un uso viciado de Scrum); o en los desarrolladores que trabajan como autómatas en lo que el Product Owner diga, sin preocuparse por la validación de hipótesis y crear un producto de valor. Más allá del cambio de nomenclatura y foco, no hay modificaciones en el fondo.

Por cierto, si el objetivo principal de la actualización era hacer la Guía más amigable para equipos en cualquier clase de industria, no creo que un equipo de ventas o de marketing se sienta especialmente reflejado en el término “developers”. Ya con la de 2017 había que explicar a testers o diseñadores que ellos también eran parte del Equipo de Desarrollo… Quizás lo más consecuente hubiera sido hablar de miembros del Equipo Scrum distintos al Scrum Master y al Product Owner, y eliminar “developers”. O hablar, en sentido amplio, de «profesionales». Demasiado radical, probablemente.

– En vez de hablar de equipos “autoorganizados”, sustituyen la palabra por “autogestionados”. Creo que esto es más bien una cuestión teórica y semántica. La motivación tras este cambio es atajar el uso viciado de autoorganización que muchos desarrolladores han realizado: autoorganización no es sinónimo de “puedes hacer lo que te venga en gana”.

– Tamaño del equipo: antes el número de miembros del Equipo de Desarrollo era entre 3 y 9, sin contar al Product Owner y al Scrum Master. Ahora se dice que, “típicamente”, el Equipo Scrum tiene a 10 personas o menos. Esto parece una mención algo vaga. Ya no hay límite por debajo para hacer Scrum, y podríamos tener equipos de dos personas. Y también podríamos tener un equipo de 20. En los tiempos que corren, sugerir 10 me parece una multitud. 5 o 6 será mucho mejor. Sería interesante ver los estudios empíricos en los que se basan los autores para proponer 10 y no 9 + 2, como antes.

– Se especifican las responsabilidades de los desarrolladores. Esto sí es positivo, dado que agrupa aspectos que antes había que destilar de la lectura de la Guía. Estas responsabilidades son: crear el Sprint Backlog, cumplir con la Definición de Hecho y ver el progreso diario hacia la consecución del Objetivo del Sprint. Ahora bien, se pierde una parte descriptiva que sí contenía la versión de 2017: no se explicita que Scrum no reconoce sub-equipos ni títulos entre los developers.

– Respecto al Product Owner, no hay cambios, aunque se añade una responsabilidad: la de desarrollar y comunicar el Product Goal. ¿Y qué es eso del Product Goal? Lo comentamos más abajo.

– En lo concerniente al Scrum Master, se elimina su calificación como “servant leader”, y ahora se habla de “true leaders who serve”. Este cambio no me entusiasma. A nosotros nunca nos gustó la adjetivación del Scrum Master como líder sirviente, y hemos defendido la de líder de nivel 5. Empero, el fondo siempre fue el mismo o similar. Con la actualización de 2020 entramos en territorio desconocido. ¿Qué es eso de “true” leader? ¿Acaso hay líderes de verdad y de mentira? Al menos, la noción de servant leadership servía para encapsular el espíritu del rol. Lo de “true” suena hasta dogmático. Al parecer, Ken Schwaber identificó la denominación “servant leader” como uno de los mayores problemas de Scrum, porque era una forma de convertir al Scrum Master en “secretario” del Equipo. Este es, sin duda, uno de los usos viciados de Scrum, aunque no veo cómo “true leader” lo solventa. Al margen de la redacción, no demasiado afortunada, lo que está claro es que se quiere poner el foco en la parte de leader y no en la de servant. Le han «dado la vuelta».

– Se matizan o explican mejor algunas de las responsabilidades del Scrum Master. Ahora es más evidente que el Scrum Master no es quien necesariamente resuelve un impedimento, y la mención a “facilitar” los eventos se sustituye por una explicación de en qué consiste facilitar los eventos: que tengan lugar, dentro del time-box, y que sean positivos y constructivos. Se añade también que el Scrum Master facilitará la colaboración con los stakeholders, en apoyo al Product Owner, y que el Scrum Master elimina barreras entre stakeholders y desarrolladores. Asimismo, se subraya en el papel del Scrum Master como coach de la organización.

Sprint

Se eliminan los detalles respecto a la cancelación del Sprint, que tampoco tiene mayor importancia, por la poca frecuencia con la que esto se da, y porque sigue siendo una potestad del Product Owner.

Sprint Planning

Aquí hay varios matices:

– Se indica que el Product Owner debe asegurarse de que los asistentes a la reunión estén “preparados” para hablar de los elementos más importantes del Product Backlog (por cierto, prescripción que antes no constaba). Me parece correcto: todos sabemos que, cuando el Product Owner no ha preparado la Planning, lo cual exige haber trabajado con el resto del Equipo Scrum previamente, la Planning es un desastre.

– Mención expresa a que el Scrum Team puede invitar a otras personas a la reunión, para que aporten consejo. Antes solo el Equipo de Desarrollo invitaba a terceros.

– En lugar de dos topics a tratar en la ceremonia, se añade un tercero: “¿Por qué el Sprint entregará valor?” En realidad, lo único que hace es desgajar y considerar el Objetivo del Sprint como un tema aparte. Bueno, vale.

– Se elimina una mención relevante a que, al final de la reunión, trabajo suficiente para los primeros días del Sprint debe haber quedado descompuesto. Ahora esto queda al arbitrio de los developers, que podrán hacer esta descomposición cómo y cuándo consideren.

Daily Scrum

Se quitan las tres preguntas clásicas y ejemplificativas sobre cómo los desarrolladores pueden estructurar la reunión. Entiendo que el foco se quiera poner en el seguimiento del progreso hacia el Objetivo del Sprint y no en las “preguntitas”, que se han utilizado por muchos equipos de forma rutinaria y casi robótica, o que han servido al Scrum Master en modo “comandante”. Ahora bien, como preguntas de ejemplo que eran, creo que ayudaban a llevar la teoría a la práctica.

En definitiva, la Daily nunca ha tenido que ceñirse a las tres célebres preguntas. Por ejemplo, Jeff Sutherland ha sugerido formular una única pregunta para todos los desarrolladores: “¿por qué la primera historia de usuario no está terminada?” Y, a continuación, hacer que todos nos pongamos manos a la obra.

Sprint Review

Si un neófito en materia Scrum se lee los tres escuetos párrafos que han dejado en este apartado, seguramente no entienda demasiado. Ya no hay mención alguna a los elementos a tratar en la Review, solo un genérico “inspeccionar el resultado del Sprint y adaptar el Product Backlog si procede”. No hay rastro de la mención a que el Product Owner invite a stakeholders, ni se indica quién hace qué. Por ejemplo, la demo la podría hacer el Product Owner o el Scrum Master, ya no tienen que ser los desarrolladores quienes presenten el resultado de su propio trabajo.

Sprint Retrospective

Todo más o menos igual, aunque con menos énfasis en la necesidad de implementar mejoras identificadas en el siguiente Sprint. De hecho, ya no es obligatorio llevar al menos una mejora identificada en la Retro al Sprint Backlog. Ahora nos dice que las mejoras se implementen “cuanto antes”. Esto puede contribuir a “relajar” a los Equipos y a dejar la mejora continua de procesos y relaciones de lado. Cuidado.

Scrum Artifacts

Se especifica que cada artefacto contiene una suerte de “compromiso”: el Product Goal, en el caso del Product Backlog; el Sprint Goal, en el caso del Sprint Backlog; y la Definition of Done, que se predica del Incremento. A pesar de la abstracción de la palabra “compromiso”, este esquema seguramente hace que el framework en este apartado sea más compacto, más “bonito” conceptualmente hablando.

Product Backlog

Se ha suprimido buena parte de la descripción que permitía entender qué son el Product Backlog y el refinamiento. Un par de matices:

– Ahora se habla de “sizing”, no de estimaciones.

– Ya no se sugiere que el refinamiento no consuma más del 10% de la capacidad del Equipo de Desarrollo; tampoco se especifica que el refinamiento lo hagan Product Owner y desarrolladores, lo que abre la puerta a que, teóricamente, el Scrum Master también haga refinamiento. Para mí, el refinamiento debería ser parte obligatoria del framework. Ahora, al contrario, apenas si se explica o recomienda.

Y llegamos así “la joya de la corona”: el compromiso con el “Product Goal”, que se define como un «estado futuro del producto» que ayuda al Equipo Scrum a planificar. En Product Management, se habla de visión de producto y de roadmap de producto. Lo de Product Goal me confunde: ¿Estamos ante una especie de estadio intermedio entre visión de producto y Objetivo del Sprint? ¿Coincide con los OKRs? ¿Acaso el Objetivo del Sprint no es también un Objetivo de Producto? Entiendo que se quiera dar sentido a los sucesivos Objetivos del Sprint en torno a un objetivo amplio de producto, pero esto ya se hacía, sin necesidad de la obligatoriedad del Product Goal como tal, y variará notablemente según la empresa. En este aspecto, la Guía Scrum se vuelve bastante más prescriptiva que antes.

Asimismo, la Guía se aventura a incluir una definición de producto un tanto extraña, en la que se llega a decir que un producto puede ser un servicio, un producto físico u, ojo, literalmente, “algo más abstracto”.

Sprint Backlog

Sin cambios aparentes, aunque se especifica que el Objetivo del Sprint es parte del Sprint Backlog, junto con los elementos seleccionados y el propio plan de trabajo.

Increment

Pocos cambios, si bien aclara cosas que ya eran obvias, como que en un Sprint se pueden crear varios Incrementos, y que se pueden entregar antes de la Review.

Definición de Hecho

La responsabilidad de crearla ya no es de los desarrolladores, sino de todo el Equipo Scrum. Los desarrolladores deben asegurar la conformidad con dicha Definición.

Hasta aquí mis impresiones por el momento. En los próximos meses los cambios irán cuajando en la comunidad y veremos su impacto. Lo que es seguro es que, en lo sustancial, Scrum sigue siendo Scrum. Y, oye, que el framework se reinvente de vez en cuando es necesario y evita que nos acomodemos. Nada menos agile que no evolucionar.

¿Cuál es tu opinión sobre la nueva Guía Scrum?

Por si te sirve, puedes descargarte estas diapositivas con un resumen de los cambios en la Guía Scrum 2020.

Dejamos aquí también el video en el que los dos co-creadores de Scrum, Ken Schwaber y Jeff Sutherland, presentan y responden a preguntas sobre algunos de los cambios principales.

Imagen de portada: Scrum Guide 2020.