En este artículo se presenta un resumen de qué es y cómo se implementa en un proyecto el framework ágil Scrum siguiendo la Guía de Scrum™ de los creadores de este marco de trabajo.
Scrum(1) es un framework con procesos y técnicas creado por Jeff Sutherland y Ken Schwaber a principios de la década de los noventa que había sido previamente probado y perfeccionado por ellos mismos en organizaciones como Individual, Inc., Newspage, Fidelity Investments e IDX (en la actualidad GE Medical), entre otras.
Según la Guía de Scrum™(2)
«Es un marco de trabajo a través del cual las personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el máximo valor.»
(Schwaber & Sutherland, 2017, p. 3)
Los equipos scrum entregan productos con calidad y mayor valor al negocio en el menor tiempo posible maximizando el retorno de la inversión (ROI). Las prioridades son definidas desde negocio y los equipos se autogestionan para proporcionar las funcionalidades del producto priorizadas.
La historia de Scrum
El framework Scrum fue presentado en la conferencia de Oopsla (Austin, Texas, EE.UU.) en 1995. Su nombre proviene del artículo científico "The New New Product Development Game" de Takeuchi y Nonaka publicado en 1986.
Más tarde, en febrero de 2001, Jeff Sutherland y Ken Schwaber formaron parte de los 17 líderes de desarrollo de software que se unían para crear el Manifiesto para el Desarrollo de Software Ágil. Actualmente, Scrum es el framework ágil más utilizado en todo el mundo.
El manifiesto ágil
El Manifiesto por el Desarrollo Ágil de Software(3) es un documento que gracias a la experiencia de sus integrantes en el desarrollo de software intenta valorar:
Individuos e interacciones sobre procesos y herramientas
Sofware operativa sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Responder al cambio sobre seguir un plan
Lo que significa que admiten el valor de los elementos de la derecha pero valoran más los de la izquierda.
Por otro lado, se basa en 12 principios:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
La Guía de Scrum™
El cuerpo de conocimiento de Scrum se basa en La Guía de Scrum™ escrita por Jeff Sutherland y Ken Schwaber. La primera publicación de la guía fue en 2010 y tuvo actualizaciones incrementales en 2011, 2013, 2016 y 2017.
En la misma se establece que
«El marco de trabajo Scrum consiste en los Equipos Scrum y sus roles, eventos, artefactos y reglas asociadas. Cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de Scrum y para su uso. Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las relaciones e interacciones entre ellos.»
(Schwaber & Sutherland, 2017, p. 3)
Scrum como marco de trabajo (framework) emplea un enfoque iterativo e incremental con el objetivo de optimizar el valor entregado al cliente y el control del riesgo del proyecto.
Basado en el empirismo, que asegura que el conocimiento procede de la experiencia, se soporta en tres columnas: transparencia, inspección y adaptación.
Por transparencia se entiende que todos los integrantes del equipo deben saber lo que está pasando en cada momento, inspección significa que todos comprueban el trabajo a medida que éste se va realizando, y adaptación permite hacer los cambios pertinentes con el objetivo de generar el máxima valor para los stakeholders.
Para ello, todos los participantes deben compartir un lenguaje común y una definición clara y concisa de "terminado" (done en inglés).
Scrum prescribe cuatro eventos formales para la transparencia, inspección y adaptación dentro del Sprint:
Planificación del Sprint (Sprint Planning)
Scrum Diario (Daily Scrum)
Revisión del Sprint (Sprint Review)
Retrospectiva del Sprint (Sprint Retrospective)
Valores
Para utilizar con éxito en un equipo el framework Scrum son necesarios 5 valores: compromiso, coraje, foco, apertura y respeto.
Compromiso individual para alcanzar las metas del equipo, teniendo coraje para trabajar en los problemas, con foco en el trabajo del sprint, manteniendo apertura mental y respetando al conjunto de stakeholders.
«Los miembros del Equipo Scrum (Scrum Teams) aprenden y exploran estos valores a medida que van trabajando en los Eventos (Events), Roles (Roles) y Artefactos (Artifacts) de Scrum. El uso exitoso de Scrum depende de que las personas lleguen a desarrollar unas habilidades extraordinarias en alcanzar las metas del Equipo Scrum (Scrum Team).»
(Schwaber & Sutherland, 2017, p. 5)
Los elementos de scrum son eventos, roles y artefactos; mientras que los roles del equipo scrum (scrum team) son: Propietario del Producto (Product Owner- PO), Scrum Master (SM) y el Equipo de Desarrollo (Development Team).
El Equipo Scrum
Los Equipos Scrum (Scrum Teams) son auto-organizados y multifuncionales; y están diseñados para optimizar la flexibilidad, la creatividad y la productividad. Su objetivo es hacer entregas incrementales e iterativas de producto "terminado" (done). El Scrum Team se compone de un Product Owner, un Development Team y un Scrum Master.
Roles en Scrum
Product owner
«El Propietario del Producto (Product Owner – PO) es el responsable de maximizar el valor del producto del trabajo del Equipo de Desarrollo (Development Team).»
(Schwaber & Sutherland, 2017, p. 6)
El PO es la única persona responsable de gestionar la Pila del Producto (Product Backlog) que incluye priorizar y ordenar sus elementos, asegurar que el Development Team los entienda a nivel necesario, y optimizar el valor de trabajo de éste. El Development Team también puede gertionar el Product Backlog pero el responsable seguirá siendo el PO.
El PO es una única persona pero puede representar los deseos de un comité.
Development Team
«El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de entregar un Incremento de producto ‘Terminado’ que potencialmente se pueda poner en producción al final de cada Sprint.»
(Schwaber & Sutherland, 2017, p. 7)
Los miembros del Equipo de Desarrollo son multifuncionales, cuentan con un alto grado de autonomía y responsabilidad, y se auto-organizan en vez de ser dirigidos por un jefe de equipo o jefe de proyecto.
Scrum no reconoce títulos en el team ni reconoce subequipos. El tamaño del equipo debe ser entre 3 y 9 integrantes sin contar al PO y al SM. La responsabilidad es compartida.
Scrum Master
«El Scrum Master es un sirviente líder que está al servicio del, y para el Equipo Scrum (Scrum Team). El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no.»
(Schwaber & Sutherland, 2017, p. 8)
Pueden concentrarse hasta dos roles en la misma persona, siempre y cuando no sean el de Scrum Master y Product Owner.
El Scrum Master sirve al PO a encontrar técnicas para gestionar la Pila del Producto, facilitar los eventos de Scrum según se requieran y asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el Equipo Scrum.
En cuanto al Equipo de Desarrollo, lo servirá ayudándolo a ser auto-organizado y multifuncional, eliminando impedimentos; y lo guiará en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.
Finalmente, liderará la organización en la adopción de Scrum, planificando las implementaciones y ayudando a los empleados e interesados a entender y llevar a cabo este framework.
Eventos
En Scrum existen eventos predefinidos que sirven para organizar el trabajo en equipo, siendo todos éstos bloques de tiempo (time-box en inglés) con duración máxima. Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los otros eventos en cambio pueden acortarse siempre que se alcance su objetivo.
Sprint
el Sprint es un contenedor de otros eventos, los cuatro principales dentro del mismo son Daily Meeting, Sprint Planning, Sprint Review o Demo y Retrospective; y tiene una duración de hasta un mes, aunque la duración más utilizada es de dos semanas. Su objetivo es crear un incremento de producto ‘Terminado’ utilizable y potencialmente desplegable (deploy).
Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior, siendo conveniente mantener su duración consistente a lo largo del proyecto.
Los Sprints consisten en la Planificación del Sprint (Sprint Planning), los Scrums Diarios (Daily Scrums), el trabajo del Equipo de Desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective).
Durante el Sprint puede renegociarse el alcance pero no se pueden realizar cambios al objetivo (goal). La predictibilidad se asegura mediante la transparencia, inspección y adaptación, y se limita el riesgo del proyecto a la duración del mismo.
Un Sprint puede cancelarse antes de que su time-box finalize pero solamente si su objtivo queda obsoleto y sólo el PO lo puede hacer. Esto suele ser muy poco común.
Planificación del Sprint (Sprint planning)
Es el primer evento del Sprint y sirve para planificar el trabajo a realizar durante el mismo. Tendrá una duración máxima de dos horas por cada semana del mismo. Por ej. si el Sprint dura 2 semanas, el Sprint Planning durará 4 horas.
Esta planificación está divida en dos temas que responden a las preguntas
«¿Qué puede entregarse en el Incremento resultante del Sprint que comienza? y ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?».
(Schwaber & Sutherland, 2017, p. 10)
Tema uno: Qué puede hacerse en este sprint?
«El Equipo de Desarrollo (Development Team) trabaja para proyectar la funcionalidad que se desarrollará durante el Sprint. El Propietario del Producto (Product Owner) discute el objetivo que el Sprint debería lograr y los elementos de la Pila del Producto (Product Backlog) que, si se completan en el Sprint, lograrían el objetivo del Sprint (Sprint Goal).»
(Schwaber & Sutherland, 2017, p. 11)
Como entradas al evento se utilizarán la Pila del Producto, el último Incremento de producto, la capacidad proyectada del Equipo de Desarrollo para el Sprint y el rendimiento pasado del Equipo de Desarrollo. Solo el Equipo de Desarrollo puede evaluar qué es capaz de lograr durante el Sprint que comienza.
Tema Dos: ¿Cómo se conseguirá completar el trabajo seleccionado?
«Una vez que se ha establecido el objetivo y se han seleccionado los elementos de la Pila del Producto (Product Backlog) para el Sprint, el Equipo de Desarrollo (Development Team) decide cómo construirá esta funcionalidad para formar un Incremento de producto ‘Terminado’ durante el Sprint. Los elementos de la Pila del Producto (Product Backlog) seleccionados para este Sprint, más el plan para terminarlos, reciben el nombre de Pila del Sprint (Sprint Backlog).»
(Schwaber & Sutherland, 2017, p. 12)
El output del Sprint Planning será el objetivo del Sprint y el Sprint Backlog. El Equipo de Desarrollo (Development Team) se auto-organiza para asumir el trabajo de este último.
«Al finalizar la Planificación del Sprint (Sprint Planning), el Equipo de Desarrollo (Development Team) debería ser capaz de explicar al Propietario del Producto (Product Owner) y al Scrum Master cómo pretende trabajar como un equipo auto-organizado para lograr el objetivo del Sprint y crear el Incremento esperado.»
(Schwaber & Sutherland, 2017, p. 12)
Daily Scrum
Es una reunión de 15 minutos que se realiza todos los días a la misma hora con todo el Equipo de Desarrollo preferentemente de pie. Cada miembro del equipo informa sobre qué ha hecho desde la última reunión, qué tiene planificado hacer hasta la próxima reunión y qué impedimento o bloqueo está teniendo en su trabajo (si es que lo tiene).
El Scrum Master se asegura que no haya impedimentos para realizar la reunión y que ésta dure como máximo 15 minutos. Dado que es una reunión interna del Equipo de Desarrollo (Development Team), si otras personas están presentes, el Scrum Master se asegura de que la no interrumpan.
Durante o luego de la reunión es útil actualizar el tablero kanban y los gráficos burn down / burn up.
Sprint Review
4 hs. máximo para un sprint de un mes
«Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el Incremento y adaptar la Lista de Producto si fuese necesario. Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint.»
(Schwaber & Sutherland, 2017, p. 13)
Es una reunión informal para presentar el trabajo hecho por parte del Equipo de Desarrollo, donde además el PO hablará de la Pila de Producto en su estado actual, y se intercambiará información acerca de qué hacer a continuación. Su resultado es una Pila del Producto revisada con elementos posibles para el siguiente Sprint. Participan el Equipo Scrum y los stakeholders.
Sprint Retrospective
Tiene un bloque de tiempo de máximo tres horas para sprints de un mes. La retrospectiva es la última reunión del Sprint, sigue inmediatamente después de la revisión y nunca debe ser omitida. En ella el Equipo Scrum (único participante) se inspecciona a sí mismo y crea un plan de mejoras para el siguiente Sprint.
Según la Guía ScrumTM:
«El propósito de la Retrospectiva de Sprint es:
Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas; Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras; Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.»
(Schwaber & Sutherland, 2017, p. 14)
Scrum Artifacts
«Los Artefactos de Scrum representan trabajo o valor en diversas formas que son útiles para proporcionar transparencia y oportunidades para la inspección y adaptación. Están diseñados específicamente para maximizar la transparencia de la información clave, necesaria para asegurar que todos tengan el mismo entendimiento del artefacto.»
(Schwaber & Sutherland, 2017, p. 15)
La Guía ScrumTM describe tres artefactos: Product Backlog, Sprint Backlog, e Increment.
Product backlog
La Pila del Producto (Product Backlog) es la lista de funcionalidades por desarrollar en orden de prioridad. Solo existe un Product Backlog por producto y su responsable es el Product Owner.
El Product Backlog es dinámico y se va actualizando a cada sprint enumerando las características, funcionalidades, requisitos, mejoras y correcciones que deben realizarse sobre el producto para futuras entregas.
Los elementos de la Lista de Producto tienen como atributos mínimos la descripción, el orden, la estimación y el valor; y muchas veces incluyen descripciones de las pruebas que demostrarán el elemento ‘Terminado’.
Debe cumplir el acrónimo DEEP: Detallado Apropiadamente, Estimado, Emergente, y Priorizado.
Refinement
«El refinamiento (refinement) de la Lista de Producto es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto. Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto.»
(Schwaber & Sutherland, 2017, p. 16)
El Equipo Scrum es el que decide cómo y cuándo se hace el refinamiento consumiendo no más del 10% del tiempo del Sprint. En general los elementos de la Lista de Producto de orden más alto son más claros y detallados que los de menor orden. A medida que van subiendo en la lista se van realizando estimaciones más precisas y con mayor claridad y detalle.
Seguimiento del Progreso hacia los Objetivos
El PO controla el total de trabajo restante al menos cada Sprint Review, comparándolo con Sprints previos para predecir el tiempo que falta al objetivo. Existen varias prácticas de proyección de tendencias que se utilizan para predecir el progreso, y que han probado ser útiles, como los gráficos trabajo pendiente (Burn Down), trabajo completado (Burn Up) y el flujo acumulado (Cumulative Flow). De todas maneras esto no reemplaza al empiricismo y solamente lo que ha ocurrido puede tomarse para decidir acciones a futuro.
Sprint Backlog
La Pila del Sprint (Sprint Backlog) es el conjunto de elementos del Product Backlog que se van a desarrollar en el sprint más el plan para entrega del Incremento de producto para conseguir el Objetivo del Sprint.
la Pila del Sprint (Sprint Backlog) es un plan con un nivel de detalle suficiente como para que los cambios en el progreso se puedan entender en el Scrum Diario (Daily Scrum) e incluye, para asegurar la mejora continua, al menos una mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente anterior.
Solo el Equipo de Desarrollo (Development Team) puede cambiar su Pila del Sprint (Sprint Backlog) durante un Sprint: Cuando se requiere nuevo trabajo lo adiciona a la Pila del Sprint (Sprint Backlog) y su vez se eliminan los elementos que se vuelven innecesarios.
El Equipo de Desarrollo (Development Team) hace seguimiento del trabajo restante total al menos en cada Scrum Diario (Daily Scrum) para así poder proyectar la posibilidad de conseguir el objetivo del Sprint.
Incremento (Increment)
«El Incremento es la suma de todos los elementos de la Lista de Producto completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint el nuevo Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser utilizado y que cumple la Definición de ‘Terminado’ del Equipo Scrum. El incremento debe estar listo para utilizarse sin importar si el Dueño de Producto decide liberarlo o no.»
(Schwaber & Sutherland, 2017, p. 17)
Transparencia de los Artefactos
Scrum se basa en la transparencia.
«El Scrum Master debe trabajar con el Propietario del Producto (Product Owner), el Equipo de Desarrollo (Development Team) y otras partes involucradas para entender si los artefactos son completamente transparentes.»
(Schwaber & Sutherland, 2017, p. 17)
Esta transparencia permite tomar decisiones con bases sólidas, evitando así aumentar el riesgo de errores.
Definición de hecho (Done)
«Cuando un elemento de la Pila del Producto (Product Backlog) o un Incremento se describe como ‘Terminado’, todo el mundo debe entender lo que significa ‘Terminado’ (Done en inglés). Aunque esto puede variar significativamente para cada Equipo Scrum (Scrum Team), los miembros del equipo deben tener un entendimiento compartido de lo que significa que el trabajo esté completado para asegurar la transparencia.»
(Schwaber & Sutherland, 2017, p. 18)
Importante es resaltar la nota final de la Guía de Scrum™:
«Scrum es gratuito y se ofrece en esta guía. Los roles, eventos, artefactos, y reglas de Scrum son inmutables y aunque es posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum solo existe como un todo y funciona bien como contenedor para otras técnicas, metodologías y prácticas.
(Schwaber & Sutherland, 2017, p. 19)
En definitiva, Scrum es un framework ágil que podemos implementar no solo en equipos de software sino también donde se necesite desarrollar productos complejos en entornos VUCA (Volatility, Uncertatinty, Complexity, Ambiguity); lo que lo convierte en una herramienta extremamente útil para los tiempos actuales.
Referencias
1.- Scrum.org. Scrum.Org Página principal. Consultado el 17 de agosto de 2020. https://www.scrum.org/.
2.- Schwaber, K., Sutherland, J. (2017). La Guía de Scrum™ [Ebook]. Consultado el 17 Agosto 2020. https://www.scrumguides.org/index.html.
3.- Manifiesto por el Desarrollo Ágil de Software. Página principal. Consultado el 17 de agosto de 2020. http://agilemanifesto.org/iso/es/manifesto.html.
Si buscas un formador para realizar este curso u otra actividad formativa (webinar, workshops, bootcamps, etc.) en tu organización, me puedes ubicar a través de la página de contacto. Muchas gracias.
Si te ha gustado el artículo puedes ayudarme haciendo una donación con criptomonedas. Gracias!!!
Imágenes de Kate Baucherel y Gerd Altmann obtenidas en Pixabay