Scrum: la guía extendida

La Guía Scrum es un documento breve. Demasiado sucinto, quizás. En su última versión, de 2020, la Guía ocupa tan solo 13 páginas. De un lado, esto quiere decir que los que utilizamos Scrum tendremos libertad para dotarlo de contenido. De otro lado, sin embargo, la falta de detalles o ejemplos prácticos puede dejar a algunos equipos “en el limbo”, sin saber cómo interpretar lo que la Guía quiere decir. Por ello, hemos creado esta Guía Scrum extendida, con todo lo que necesitas saber sobre Scrum, expresado en un lenguaje llano, pero siempre siendo fieles a la Guía oficial.


1. ¿Qué es Scrum?

Scrum es un framework ligero y empírico para la creación de un producto complejo, que nos permite obtener un Incremento de este durante o al final de cada Sprint o ciclo corto de desarrollo. Scrum es lo que la Guía Scrum dice que es: tan sencillo y liviano a priori como difícil de dominar.

El Sprint es el corazón de Scrum: contiene a los diferentes eventos, en los cuales se crean o revisan los artefactos, y a lo largo de este se produce todo el trabajo de desarrollo, incluyendo las pruebas que sean necesarias e, incluso, el despliegue o puesta en producción del Incremento obtenido. El trabajo es realizado por el Equipo Scrum, que es un equipo pequeño, de un máximo de entorno a diez miembros, que se compone por un Scrum Master, un Product Owner y los Desarrolladores.


1.1. Scrum como framework ligero

Scrum no es una técnica, un método o un proceso predefinido, con pasos que puedan aplicarse de principio a fin. Al contrario, es el continente en el que aplicar todo ese conjunto de técnicas. Scrum nos da “las reglas del parchís”, pero no nos dice cómo o con qué tácticas ganar. Esto es potestad de cada Equipo Scrum, que irá creando su propio proceso, con Scrum como framework base.

Este framework esencial se integra por:

Decimos que es un marco de trabajo ligero precisamente por la brevedad de los elementos que lo componen y de la propia Guía Scrum, a la que antes aludíamos. No estamos ante un manual cerrado y pormenorizado sobre cómo crear software. Scrum solamente define las reglas del juego, el tablero en el que jugar.

Hay que tener en cuenta que, si alteramos u omitimos los elementos del framework, ya no estaremos haciendo Scrum, sino otra cosa. Esto afectará a la probabilidad de que hagamos working software de calidad con éxito. Continuando con el símil, si nos saltamos las reglas del parchís, ya no estaremos jugando al parchís, sino a otro juego distinto e inventado. Es habitual encontrarse con equipos que dicen hacer Scrum con “adaptaciones”, “porque a ellos les funciona mejor así”; no se dan cuenta de que, con esos ajustes, simplemente han dejado de utilizar Scrum y han renunciado a sus beneficios potenciales.


1.2. Scrum y el empirismo

Scrum se sustenta en el empirismo, esto es, en la toma de decisiones basada en aquello que ya ha sucedido. El típico grafico de Gantt, creado con todo lujo de detalles y que nunca se cumple, no tiene ningún sentido. En Scrum, nuestras predicciones deben basarse en el rendimiento que observamos en el pasado. Nada de adivinar el futuro. Por ejemplo, si un Equipo Scrum tuvo una velocidad de 10 puntos en el primer Sprint y de 12 en el segundo, sería razonable estimar que, en el tercer Sprint, la velocidad será de entre 10 y 12 puntos.

El empirismo, aplicado a Scrum, se sustenta en tres pilares:

Por ejemplo, si, al presentar el Incremento de producto en la Sprint Review, los stakeholders detectan carencias en el mismo, o apuntan a cambios de mercado, el Product Backlog podrá ser convenientemente adaptado.


1.3. Scrum como marco de trabajo para desarrollar productos complejos

Scrum no es adecuado para cualquier contexto. En situaciones de caos, o de carácter simple o complicado, Scrum no tiene porqué funcionar y puede haber otros modelos más pertinentes.

Scrum brilla en entornos complejos, es decir, donde las incertidumbres superan a las certidumbres y es preciso que la solución emerja a medida que avanzamos. 

Esta clasificación de contextos es la auspiciada por el modelo de Cynefin.


2. Historia de Scrum

El germen de Scrum tiene su origen en el artículo The new new development game, escrito por los profesores japoneses Hirotaka Takeuchi y Ikujiro Nonaka, publicado en Harvard Business Review en 1986. En este trabajo aluden a cómo empresas americanas y japonesas habían descubierto una forma de trabajar holística, en fases solapadas, contrapuesta a la tradicional o secuencial, y utilizaban el rugby como metáfora. Se referían a cómo los jugadores avanzaban por el terreno de juego como una unidad: «as in rugby, the ball gets passed within the team as it moves as a unit up the field». Esta era una mención indirecta a la posición de rugby denominada Scrum o melé.


scrum-agile

Este artículo fue retomado siete años después, en 1993, por Jeff Sutherland y su equipo en la empresa Easel, donde trasladaron sus conceptos, orientados al manufacturing, al ámbito de la creación de software. En OOPSLA 1995 Sutherland y Ken Schwaber presentaron SCRUM development process, cuyo paper original puede consultarse aquí. Scrum, por las propias experiencias profesionales de Sutherland, nace como contraposición a la metodología waterfall, como forma alternativa de gestionar equipos de desarrollo más eficientemente y de construir mejores productos de software. Sutherland y Schwaber crearon también la Guía Scrum, que es algo así como “la Biblia de Scrum”. Scrum se ha aplicado también en ámbitos diferentes al software, como el hardware, las ventas o el marketing, si bien es en el desarrollo de software donde su aplicación sobresale.

Por cierto, si deseas profundizar sobre la historia de Scrum, quizás te interese el libro Scrum, The Art of Doing Twice the Work in Half the Time (Scrum: El revolucionario método para trabajar el doble en la mitad de tiempo), escrito por el co-creador de Scrum Jeff Sutherland. Personalmente no lo recomiendo: está lleno de “batallitas” redundantes de escaso valor didáctico y a veces parece que lo que más preocupa a Sutherland es dejar claro que él inventó Scrum. Sé que otros agilistas sí que recomiendan esta lectura… Para gustos, los colores.


Scrum-The-Art-of-Doing-Twice-the-Work-in-Half-the-Time

2.1. ¿Por qué usar Scrum? Los resultados de Scrum

Desde los inicios, Scrum demostró enormes aumentos de productividad, de hasta el 800% según Sutherland. La fórmula de equipos de desarrollo pequeños, multifuncionales y autónomos funcionaba. Conceptos como el de Sprint, Product Backlog o Daily Scrum se han popularizado enormemente gracias a los números.

Traigo a colación las métricas de la empresa Genomica -empresa de bioinformática y que fue una de las pioneras en la adopción de Scrum, allá por el año 2000- antes y después de implantar Scrum, que hablan por sí solos.

MedidaWaterfallScrum
Esfuerzox10x1
Velocidadx1x7
Satisfacción del clientePobreExcelente
Adaptado de Kenneth S. Rubin, Essential Scrum.

2.2. Principales organizaciones relacionadas con Scrum

El uso de Scrum ha sido promocionado por diversas organizaciones, entre las que destacan dos: Scrum Alliance y Scrum.org. En particular, Scrum.org ofrece certificaciones de reconocido prestigio y que no caducan para Scrum Master y Product Owner. Destacamos las certificaciones Professional Scrum Master I y Professional Product Owner I, enormemente extendidas en el sector.

Puedes consultar nuestra guía de preparación de la certificación PSM I, así como acceder aquí a nuestro simulador de examen de certificación para Scrum Master.


2.3. Scrum y Agile

Scrum es una de las corrientes dentro de Agile, quizás la principal o más conocida, pero ni mucho menos la única. Dicho de otra manera, Agile incluye a Scrum y a otras muchas técnicas y metodologías como Extreme Programming, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development y Pragmatic Programming. En 2001, 17 representantes de estas formas alternativas de hacer software se reunieron para acordar una serie de bases comunes en el Agile Manifesto o Manifiesto por el Desarrollo Ágil de Software. Con el término Agile estos líderes evitaban otros como “light” o “lightweight”, que habían sido empleados hasta entonces.


2.4. Scrum a escala

A medida que grandes organizaciones implantaban Scrum, han surgido diversos frameworks de escalado como Nexus, SAFe o LeSS. Por ejemplo, un Nexus (“nodo”) comprende entre tres y nueve equipos Scrum, contempla un nuevo rol, el Equipo de Integración Nexus, e instaura el refinamiento como ceremonia obligatoria.


3. Los valores Scrum

Para implementar Scrum, es necesario “vivirlo”, dotarse del espíritu que Scrum requiere. Este suele ser uno de los principales obstáculos a la hora de implantar Scrum con éxito en las organizaciones.

Scrum propone cinco valores: compromiso, foco, sinceridad o apertura, respeto y coraje.

Puedes leer más sobre los valores Scrum aquí.


4. El Equipo Scrum

La actualización 2020 de la Guía Scrum ha eliminado la palabra “roles”, que se reemplaza con “responsabilidades” (del inglés “accountabilities”, que tiene mala traducción al español). Así, los tres roles tradicionales pasan a ser tres conjuntos de responsabilidades, que definen el papel del Scrum Master, del Product Owner y de los Desarrolladores.

Además de este cambio nominal, se definen más claramente cuáles son esas responsabilidades. En la versión de la Guía de 2017 era necesario repasar y destilar estas de su lectura; ahora, en cambio, se recogen de manera más concisa y difícil de obviar.

Antes de entrar a comentar las tres responsabilidades, convine resaltar que la Guía también asigna responsabilidades al Equipo Scrum como tal, a todos sus miembros:

Veamos a continuación cada una de las responsabilidades definidas en la Guía.


4.1. El Scrum Master

Le corresponde implantar Scrum tal y como se define en la Guía Scrum. Es responsable de:

Puedes leer todo sobre el Scrum Master en este artículo.


4.2. El Product Owner o Propietario del Producto

Es el encargado de maximizar el valor del producto en el que trabaja el Equipo Scrum y de gestionar el Product Backlog. Asimismo, se responsabiliza de:

El Product Owner puede delegar estas actividades en otros, pero sigue siendo responsable.

Puedes leer todo sobre el Product Owner en este artículo.


4.3. Los Desarrolladores

Son quienes realizan el trabajo del Sprint y se compromete a crear el Incremento. Se responsabilizan de:


5. Los eventos Scrum

Scrum contempla cinco eventos: el Sprint y cuatro reuniones o ceremonias que han de celebrarse en cada Sprint. Se dice, por tanto, que el Sprint contiene a los otros cuatro eventos, que son la Sprint Planning, el Scrum Diario, la Sprint Review y la Retrospectiva del Sprint.


5.1. El Sprint

Es un ciclo corto de desarrollo encaminado a la obtención de un Incremento de producto, y cuya duración no debe exceder de un mes.

Puedes leer todo sobre el Sprint en Scrum aquí.


5.2. Sprint Planning

Es la ceremonia que da comienzo al Sprint, en la que se crea el Sprint Goal y se selecciona y planea el trabajo a realizar durante aquel.

Puedes leer todo sobre la Sprint Planning aquí.


5.3. Daily Scrum

Reunión por y para los Desarrolladores, en la que inspeccionan el progreso hacia la consecución del Objetivo del Sprint y adaptan o actualizan el Sprint Backlog.

Puedes leer todo sobre la Daily aquí.


5.4. Sprint Review

Ceremonia en la que el Equipo Scrum y los stakeholders colaboran respecto al resultado del Sprint, inspeccionando el Incremento y determinando futuras adaptaciones.

Puedes leer todo sobre la Sprint Review aquí.


5.5. Sprint Retrospective

Evento con el que concluye el Sprint. La Retrospectiva constituye una oportunidad para que el Equipo Scrum se inspeccione a sí mismo en lo relativo a procesos, interacciones y herramientas.

Puedes leer todo sobre la Sprint Retrospective aquí.


6. Los artefactos Scrum

Los artefactos Scrum representan trabajo o valor y contribuyen a generar transparencia, dado que pueden ser inspeccionados y adaptados.

Los artefactos son tres: el Product Backlog o Pila de Producto, el Sprint Backlog y el Incremento de producto. Cada uno de los artefactos tiene un compromiso asociado, como veremos en el apartado 7.


6.1. El Product Backlog

Es una lista ordenada de todo aquello conocido que el producto puede necesitar. Es gestionado por el Product Owner.

Puedes leer todo sobre el Product Backlog aquí.


6.2. El Sprint Backlog

Es el plan de trabajo de los Desarrolladores para el Sprint, que incluye: el Sprint Goal u Objetivo del Sprint, los elementos del Product Backlog seleccionados para el Sprint, así como el plan de ejecución para crear el Incremento. Visualmente, suele recogerse en un tablero Scrum o Scrum board.

Puedes leer todo sobre el Sprint Backlog aquí.


6.3. El Incremento

Es la iteración de producto que ha de obtenerse en cada Sprint, que incluye tanto la funcionalidad añadida durante el Sprint como la ya creada en los Sprints anteriores.

Puedes leer todo sobre el Incremento de producto aquí.


7. Los compromisos en Scrum

La Guía Scrum 2020 lleva el valor compromiso a su máxima expresión (para un repaso de los valores Scrum, puedes leer este artículo) y recalca que dicho compromiso no es con tareas, sino con objetivos. En Scrum, compromiso significa dar lo mejor de nosotros mismos y como equipo para conseguir el Sprint Goal (a corto plazo) y el Product Goal (a largo plazo), respetando la Definición de Hecho.  La palabra compromiso (commitment o commit) aparece en la Guía 2020 en nueve ocasiones, frente a dos menciones en la de 2017.

A fin de dotar al framework de una estructura que lo haga más inteligible, la Guía asocia un compromiso a cada uno de los artefactos.

En la siguiente tabla resumimos a quien compete la creación y adhesión a cada uno de los compromisos:


Compromiso¿Quién lo crea?¿Quién se adhiere?
Product Goal, asociado al Product BacklogEl Product OwnerEl Equipo Scrum
Sprint Goal, asociado al Sprint BacklogEl Equipo ScrumLos desarrolladores
Definición de Hecho, asociada al IncrementoEl Equipo Scrum (si no disponible en la organización)Los desarrolladores

Este esquema hace que los elementos del framework encajen mejor. Hasta la actualización 2020 de la Guía, el Objetivo del Sprint y la Definición de Terminado se quedaban “colgando”, en tierra de nadie, de manera que muchos equipos ni si quiera los aplicaban. Ahora se formulan de forma nítida, y se añade el Produt Goal para armar este modelo de tres artefactos y tres compromisos vinculados.

Estos compromisos contribuyen a aumentar la transparencia de los artefactos y el foco en torno a su estado y progreso. Refuerzan el empirismo y los valores Scrum, tanto para el Equipo Scrum como para los stakeholders.  


8. La actualización 2020 de la Guía Scrum: diferencias con la versión de 2017

La nueva Guía Scrum, que reemplaza a la de 2017, es más breve e intenta ser más concisa y menos prescriptiva (puedes leer también nuestro análisis sobre la nueva Guía Scrum). Entre los principales cambios:


9. El futuro de Scrum

En este aparatado me aventuro a hacer algunas breves predicciones sobre el futuro de Scrum.


Todas las secciones de la Guía Scrum Extendida

Responsabilidades:

Eventos:

Artefactos:

Compromisos: