Durante el año pasado, en Scrum.org trabajamos junto con los creadores de Scrum, Jeff Sutherland y Ken Schwaber, así como Scrum Alliance y Scrum Inc. en una actualización de la guía de Scrum.

Aunque estaba previsto que se anunciara en Primavera, la pandemia provocada por el COVID-19 hizo que se pospusiera el anuncio de la nueva guía, que no se había actualizado desde 2017.

En este post repaso la evolución de Scrum y su guía a lo largo de este tiempo, para sentar las bases de los próximos cambios que vendrán en breve.

Scrum, quién te ha visto y quién te ve

En Noviembre, Scrum cumplió 25 años desde que se anunció en la OOPSLA en el año 1995. Y durante estos últimos 25 años, Scrum ha cambiado mucho.

La primera vez que llegó a mis manos un manual de la “Metodología SCRUM”, tenía 160 páginas que describían detalladamente todas las mecánicas, roles y artefactos de lo que entonces era una metodología, no un marco de trabajo. Varias decenas estaban orientadas a explicar en profundidad cómo hacer estimaciones.

Por aquel entonces, lo único que necesitabas para ser Scrum Master era el manual, valor y mucha paciencia para aplicar todo aquello en un equipo.

Sin embargo, conforme pasó el tiempo y más organizaciones fueron adoptando Scrum, se hizo evidente que era imposible describir todas las posibles situaciones a las que un equipo usando Scrum podían enfrentarse.

Para entonces, ya habían pasado más de cinco años desde la edición de aquel pesado manual de 160 páginas y se había producido una explosión de personas que usaban Scrum junto con otros métodos, como XP.

Así, surgió la iniciativa de los autores para producir una guía más ligera, más enfocada en los aspectos clave y menos en los superficiales, que fuera una referencia a la que acudir ante la miríada de versiones sobre los que ocurría en Scrum, fuertemente avivadas por la explosión de formadores y formadoras que habían aprendido Scrum y lo enseñaban a través de sus propias experiencias.

Así, en 2010, nació la guía oficial de Scrum.

2010 – La primera guía oficial de Scrum

En la versión 1.0, además de la sustancial reducción de literatura, se hacía referencia por primera vez a Scrum como un “marco de trabajo” en lugar de una metodología.

El cambio no es gratuito. Los fans de las metodologías exigían una explicación minuciosa de cada detalle de las partes que gobernaban Scrum, llevando habitualmente a reducciones ad absurdum.

Cambiando la palabra metodología por marco de trabajo se expresaba que Scrum, de manera efectiva, es una herramienta que puede ser usada de diferentes maneras, y que es responsabilidad del que la usa conocerla y adaptarla a su realidad -o viceversa-.

En esta versión se hace referencia a la metáfora de los cerdos y las gallinas, a un release planning meeting y como artefactos obligatorios se listan el release burndown y el Sprint Burndown.

Quizás una de las referencias más interesantes sea, por primera vez, la de undone work o trabajo no finalizado. Algo que a los que llevábamos tiempo practicando Scrum nos surgía muy a menudo y para lo que no había una solución clara.

2011 – Definición de Scrum, Grooming y descripción de los Roles

Las dos grandes cambios de la primera gran revisión, en Julio de 2011, fueron definir Scrum como un framework en el que se lidia con problemas complejos adaptativos para construir productos del mayor valor posible y la adición del Grooming para preparar historias de usuario.

De nuevo, un pequeño cambio de lenguaje como es el uso de “producto” en lugar de “proyecto”, supone un cambio sustancial en la manera de usar Scrum. Marca la dirección de los siguientes años en Scrum, que donde realmente aporta valor es ayudando a resolver la incertidumbre del desarrollo de productos, más que a ayudar al cumplimiento de fechas, presupuestos y alcance de los proyectos.

El Grooming deja de ser una sugerencia para convertirse en una práctica para hacer Scrum y el Sprint Plan deja de ser un compromiso para convertirse en una previsión.

También se pone énfasis en realizar una descripción de qué hacen los roles en Scrum. El Scrum Master aparece como ScrumMaster -lo cual tenía poco sentido y se elimina poco después- y se eliminan la referencia a Cerdos y Gallinas, aunque ésta tardará años en salir del ideario de los practicantes de Scrum.

Por último, en Octubre de ese mismo año se produce un cambio menor orientado a relajar el foco en las reglas de Scrum.

2013 – Las tres preguntas en la Daily Scrum y el foco en el Sprint Goal

En la versión que se publicó en Julio de 2013 se pone el foco en el Sprint Goal. Muchos de los equipos que utilizaban Scrum nos estaban viendo mejoras sustanciales porque habían convertido al equipo Scrum en una caja negra que ingería requerimientos y digería código, lo que no estaba de ningún modo relacionado con la capacidad de aportar valor a la organización de los equipos que estaban utilizando Scrum.

Así, la palabra valor toma mucha relevancia a lo largo de toda esta iteración. Además se añade una sección en cómo los artefactos de Scrum facilitan la transparencia. De nuevo, se pone el foco en el control empírico de procesos como la base de Scrum

De nuevo, se reduce el lenguaje de la guía y se introducen cambios sutiles. El más prominente es el cambio de las preguntas del Daily Scrum: ¿Qué hiciste ayer? a ¿Qué hiciste ayer para ayudar a conseguir el Sprint Goal?.

2016 – Los valores de Scrum

Tras la desaparición en 2011 del commitment del Sprint, se debatió mucho sobre la necesidad de trabajar con equipos comprometidos, y el uso de la palabra previsión podía dar lugar a pensar que cumplir con una entrega de valor continua es algo opcional. Eso se arregla en la versión de 2016.

Además, para que funcione el control empírico de procesos -Transparencia, Inspección y Adaptación-, la transparencia es condición necesaria. Si no, no puede haber inspección y adaptación

Sin embargo, muchos practicantes de Scrum observaban cómo los equipos, más veces que menos, carecen de transparencia y profesionalidad.

Por primera vez, la conversación se dirige hacia los valores que tienen que tener estos equipos y no hacia las skills o conocimientos de los mismos.

Así, se introducen el compromiso, la apertura, el foco, el respecto y el coraje. Son descritos como un sustrato sobre el que trabajar para hacer que Scrum tenga éxito dentro de una organización.

Esto, además, proporciona unos principios guía para los Scrum Masters con los que poder dirigir la evolución cultural que Scrum requiere para proporcionar los máximos resultados.

2017 – Las preguntas en el Daily Scrum son optativas y los usos de Scrum

En la última versión publicada por primera vez se reconoce que las preguntas en el Daily Scrum son optativas y solamente una manera de dirigir el evento. Además, se relajan otra serie de reglas y se eliminan prácticas, para dejar los conceptos clave más a la vista.

También se introdujo una sección sobre los usos de Scrum, para reconocer que es algo que ha evolucionado más allá de los equipos de tecnología. También se hizo menos dependiente de la palabra Software, ya que hay multitud de equipos no relacionados con la tecnología usando Scrum en todo el mundo.

Además se incluyen multitud de pequeños cambios de lenguaje para hacerlo más claro.

2020 – Autogestión, Product Goal y Scrum más allá del Software

La última versión de la guía de Scrum continua con los cambios orientados a hacer Scrum agnóstico y a reconocer que se usa en muchas industrias más allá del desarrollo de Software.

Por eso se ha trabajado mucho en eliminar no sólo la terminología relacionada sino el trasfondo de desarrollo de productos digitales que hay de fondo. En esto entraré a fondo en un próximo post.

Además se ha puesto el acento en producto, producto y más producto. Desde la guía del 2013, la evolución ha sido principalmente a intentar alejar Scrum de la gestión de proyectos, que por su naturaleza de tiempo, coste y alcance cerrados no aprovechan la principal ventaja de Scrum, la capacidad de adaptación a la incertidumbre y la entrega continua de valor.

Entre los cambios, hay tres muy importantes.

La introducción del Product Goal

La meta del Product Goal es servir de guía para entender como los esfuerzos de cada Sprint van dirigidos a un objetivo de negocio concreto. El Product Goal habitualmente consistirá en un gran objetivo de negocio a ser conseguido a lo largo de uno o múltiples Sprint.

Para situarnos en el lugar correcto, pensemos en el Product Goal como releases de nueva funcionalidad. Los equipos de desarrollo trabajan consiguiendo alcanzar Sprint Goals y una vez que se cumple el Product Goal, se pasa al siguiente.

De hecho, es tan importante que se ha ligado la propia existencia del Product Backlog a la existencia del Product Goal. Ahora, en el Sprint Planning, el equipo Scrum tiene que desarrollar un Sprint Goal que sirva de paraguas para el trabajo desarrollado durante el Sprint y que además esté asociado al Product Goal.

El Product Goal es, además, una medida de progreso que la organización puede valorar a la hora de medir el valor generado.

Equipos autogestionados

Durante muchos años se ha debatido sobre el poder de la auto organización en Scrum. Es un tema recurrente en la mayoría de los foros, pero lamentablemente hay que reconocer que aunque el término es poderoso, se habla más de él por su ausencia que por su presencia.

La realidad es que la mayoría de los equipos Scrum no tienen capacidad de organización, simplemente porque las organizaciones no dejan espacio para que esta auto organización ocurra.

Si permitimos a los equipos auto organizarse pero decidimos sobre salarios, incentivos, horas de trabajo, herramientas, políticas de vacaciones, organización del desarrollo de producto y hasta en qué mesa pueden sentarse, ¿Que nos queda para organizar nosotros? ¿La retrospectiva? Y muchas veces ni siquiera eso.

Sutherland y Schwaber han querido dejar esto claro en la nueva guía, donde ahora se puede leer que el equipo Scrum se autogestiona.

De hecho, ya no diferencia entre Scrum Team y Development Team. Ahora el equipo Scrum es UN sólo equipo. Incluso deja entrever que el Scrum Master o el Product Owner tienen que sentarse a trabajar en producto si es necesario.

Incrementos útiles y de valor

Por último, el cambio que a mi más me ha gustado ha sido con respecto al incremento. En guías anteriores se hablaba de incrementos potencialmente entregables. Eso daba lugar a sesudos debates en torno a qué era potencialmente entregable. ¿Es en producción? ¿En preproducción? ¿En postproducción? ¿Pri, pra, pre, pro o pra?

En resumen: En todos sitios menos en las manos del usuario.

Con la nueva guía queda claro que los incrementos tienen que ser útiles y de valor. ¿Qué significa esto? Pues que tiene que estar en manos de un usuario. Que tienen que ser útiles para el usuario, y que además tienen que generar valor y medirlo.

Esto supone un salto de calidad grande sobre lo que teníamos anteriormente, que era un lenguaje vago que la mayoría de las veces conducía a una discusión sobre que significaba potencialmente entregable en lugar de trabajar para hacerle ganar a la organización.

Aunque existen más cambios, estos son los que más poderosos me han parecido. ¿Y a ti? ¿Qué cambios de la guía te han gustado más? Puedes dejárnoslo en los comentarios.