Scrum es una forma flexible de trabajar en un mundo que cambia rápidamente.
Desde mediados de los años noventa, el marco de trabajo del Scrum es conocido por facilitar que las personas aborden problemas complejos y cambiantes a través del tiempo, mientras les permite entregar productos con el máximo valor posible de una manera productiva y creativa.
El Scrum es usado frecuentemente en proyectos de tecnologías de la información, por lo que muchos de los sitios web que visitas o de las aplicaciones que utilizas, fueron construidas utilizando Scrum. Esta metodología no se limita al sector informático únicamente, también se ha usado para construir puentes, planear eventos masivos como conciertos, crear empresas o inclusive, construir naves espaciales como lo hace Spacex.
No son pocas las organizaciones que se vuelven Scrum sin conocer a fondo su historia, teoría o incluso la manera correcta de utilizarlo y esto lleva a un montón de frustraciones en los equipos de desarrollo y en las directivas, al incumplimiento con los clientes y usuarios finales y, en última instancia, al abandono de las metodologías ágiles por formas de trabajo más tradicionales.
A continuación prentendemos condensar los aspectos relevantes del Scrum como una forma sencilla de acercarse a este marco de trabajo.
Comencemos recorriendo un poco la historia del Scrum
El término Scrum fue utilizado por primera vez por Hirotaka Takeuchi e Ikujiro Nonaka en su artículo “El nuevo juego de desarrollo de nuevos productos”, publicado en 1986, en el que tomaron prestado el nombre del juego de rugby para enfatizar la importancia de trabajar en equipo en el desarrollo de productos complejos. Se trataba de un desarrollo de productos complejos en general, no solo de productos de software.
La investigación muestra que se logra un desempeño sobresaliente cuando los equipos son unidades pequeñas y autoorganizadas de personas, que se alimentan con objetivos desafiantes y no con tareas ejecutables. Los equipos solo pueden alcanzar la grandeza cuando se les da espacio para diseñar sus propias tácticas para dirigirse mejor hacia los objetivos compartidos.
El marco de referencia de Scrum (Scrum Framework) se basó en la investigación de Ken Schwaber y Tunde Babatunde en la Estación de Investigación DuPont y La Universidad de Delaware, quienes definieron al Scrum con las siguientes características:
1. Es liviano en cuanto a documentación y registro de actividades comparado con otros marcos de trabajo o metodologias.
2. Es fácil de entender, ya que sus conceptos básicos son simples.
3. Es difícil de llegar a dominar, debido a que solo la práctica constante permite a los equipos volverse “expertos” en él.
¿Qué no es Scrum?
Al principio el lenguaje y la terminología usada en Scrum puede parecer confusa, lo que lleva a malinterpretar cual es el espíritu detrás de este marco de trabajo. Por esta razón trataremos de aclarar algunas de las confusiones más comunes a continuación:
Scrum no es Agile.
Scrum (1995) es incluso anterior al Agile Manifesto (2001). Jeff Sutherland’s y Ken Schwaber fueron 2 de los 17 autores del manifiesto, y por lo tanto, Scrum se encuentra alineado con sus principios y valores.
Esto significa que, aunque Scrum es el marco ágil de trabajo más utilizado en el desarrollo de software en el mundo (según el Chaos Report de 2015), no es el único marco de trabajo dentro de Agile. De hecho, existen 42 marcos de trabajo que se consideran ágiles, dentro de los que se pueden encontrar Kamban, DevOps y desarrollo orientado a pruebas.
Scrum no es un proceso ni una metodología.
Scrum es un marco ágil de trabajo (Framework). Los procesos y las metodologías definen los mecanismos o procesos a seguir para el logro de un objetivo, lo que puede impedir la adaptación y el empirismo del propio equipo.
Scrum como Framework puede entenderse también como un contenedor para otras prácticas o métodos ágiles no contenidos en la guía. Esto le permite tomar prácticas de otros marcos de trabajo que el equipo pueda considerar de utilidad en su caso particular.
Scrum no esta orientado para gestionar proyectos.
La orientación del Scrum está en el desarrollo de productos de una manera eficiente y creativa con el máximo valor posible (product-oriented).
Este entendimiento es fundamental para poder aplicar correctamente el marco de trabajo y obtener todo su potencial, cambiando radicalmente el enfoque, poniendo el valor en las personas y sus interacciones sobre los procesos y las herramientas.
Esto significa que mientras que el equipo de desarrollo usa Scrum, las directivas deberían usar otras herramientas diferentes para poder administrar el proyecto de una manera eficiente y coherente.
Podríamos decir, entonces, que los roles, artefactos, eventos y reglas del Scrum son inmutables y que aunque es posible implementar solo partes, el resultado no será Scrum.
Teoría del Scrum
Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. A medida que se toman decisiones en un proyecto, se van obteniendo resultados positivos o negativos y este conocimiento adquirido se debe aplicar en la siguiente iteración de Scrum. Este es el enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo que define este marco de trabajo.
Los tres Pilares de Scrum
Scrum tiene tres pilares en los que se basa para poder operar correctamente:
- Transparencia
- Inspección
- Adaptación
La transparencia se trata de dar visibilidad a los aspectos significativos de los procesos a aquellos responsables de los resultados. Esto significa que no pueden haber “cajas negras” o información restringida dentro del equipo de desarrollo, ya que es responsabilidad de todo el equipo hacer que el proyecto sea un éxito o un fracaso.
La inspección se refiere a revisiones periódicas del avance del proyecto, buscando siempre problemas no contemplados al inicio, dificultades al interior del equipo y otras variables no deseadas.
Por último, la adaptación, que implica la capacidad de ajustar el proceso tan pronto como sea posible, al detectar alguna desviación o problema que afecte el resultado final.
Eventos en Scrum
Existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en el Scrum. Todos los eventos son bloques de tiempo (time-boxes), de tal modo que todos tienen una duración máxima.
Sprint
Es un bloque de tiempo de un mes o menos, durante el cual se crea un incremento de producto “Terminado”, utilizable y potencialmente desplegable. Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint previo.
La planeación del Sprint incluye al propietario del producto (Scrum Master ) y al equipo de desarrollo.
El objetivo es determinar cuáles de las tareas del Product Backlog (lista de tareas pendientes que deben ser desarrolladas para completar el proyecto) serán realizadas en la iteración o Sprint que está a punto de comenzar. Mientras que se determinan las tareas que se llevarán a cabo, el equipo de desarrollo y el Scrum Master se definen cómo se van a completar dichas tareas y qué miembros del equipo de desarrollo se encargarán de realizarlas. Al final de la reunión se obtiene el Objetivo del Sprint o Sprint Goal, que será siempre un mínimo producto viable, una funcionalidad completa que se pueda desplegar a producción y un Sprint Backlog, es decir, una lista de tareas específica para el Sprint, usualmente con cada tarea asignada a un miembro del equipo de desarrollo.
Daily Meetings
Tal como lo indica el nombre, son reuniones diarias que se realizan al inicio de la jornada, de corta duración y generalmente se hacen de pie, con el fin de hacerlas lo más cortas y concisas posibles.
En estas reuniones, cada miembro del equipo de desarrollo toca brevemente tres puntos importantes:
- ¿Qué hizo desde el último daily meeting?
- ¿Qué hará durante el día?
- ¿Ha visto o encontrado algún impedimento que le impida a él o al equipo cumplir con los objetivos del sprint?
El Daily Meeting tiene una duración máxima de 15 minutos, sin embargo, esto no impide que puedan realizarse reuniones posteriores para hablar sobre detalles, replanificar o adaptarse al resto del Sprint.
En cuanto a los asistentes, obligatoriamente debe estar el equipo de desarrollo, que es el encargado del Sprint Backlog y de la inspección de trabajo para lograr el cumplimiento del Sprint Goal.
Es opcional que el Scrum Master y el Product Owner estén presentes. El Scrum Master debe asegurarse de que el equipo de desarrollo tenga el Daily Scrum, de que su duración máxima sea de 15 minutos y que el equipo de desarrollo Scrum sea quien conduzca dicha reunión y el Product Owner siempre debe tener en cuenta que su participación es de oyente.
Sprint Review
Ocurre en el final del Sprint, con el fin de inspeccionar el incremento y adaptar el Product Backlog en caso de que sea necesario. Es una gran oportunidad para recibir feedback o retroalimentación sobre el desarrollo del producto.
Es una reunión informal y el objetivo principal del Sprint Review es brindar transparencia, tanto al equipo como al cliente.
Este evento es organizado por el Product Owner y es necesaria la presencia de todo el equipo de Scrum. El rol del Scrum Master es asegurar que el evento ocurra y que cumpla con los tiempos establecidos, además de asegurarse de la colaboración de todo el equipo.
Equipo
Scrum tiene tres roles principales:
Product owner o propietario del producto
Es el usuario clave que tiene la visión de la solución y provee su conocimiento del negocio y dirección al equipo para cada Sprint. Es el responsable de la gestión de la cartera de productos (Product Backlog), con el fin de lograr el resultado deseado de un producto.
Sus funciones son:
- Recoger y conocer los requisitos.
- Decidir que se desarrollará y que no.
- Definir buenas historias de usuario.
- Ordenar y priorizar el product backlog y asegurarse de que este sea visible para todos.
- Definir el mínimo producto viable.
El rol del Product Owner es ejercido por una persona y no por un comité, aunque en la práctica puede representar los deseos de éste y toda la organización debe respetar sus decisiones.
Team members
Los miembros del equipo, que deben ser entre 5 y 9 profesionales de varias disciplinas, comparten la responsabilidad de los resultados del sprint y son los encargados de entregar un incremento de producto “Terminado”, que potencialmente se podrá poner en producción al final de cada Sprint. Únicamente los miembros del equipo de desarrollo participan en la creación del incremento.
Se caracterizan por ser autoorganizados, multifuncionales, iguales entre sí, sin subgrupos internos y con responsabilidad compartida en el resultado de los sprints.
Scrum Master
Es el único responsable de que el marco de trabajo Scrum sea entendido y adoptado correctamente por todos los demás miembros de la organización.
Es un facilitador que se enfoca completamente en el proceso, se encarga de solucionar posibles conflictos al interior del equipo y del equipo con el Product Owner. Adicionalmente recopila información para el equipo de desarrollo y modera las reuniones realizadas dentro del proyecto.
Artefactos
Los artefactos del Scrum representan trabajo o valor en diversas formas y son útiles para proporcionar transparencia y oportunidades para la inspección y adaptación. Los artefactos definidos por Scrum están diseñados específicamente para maximizar la transparencia de la información clave, que es necesaria para asegurar que todos tengan el mismo entendimiento del artefacto. Entre estos artefactos están: el Product Backlog, el Sprint Backlog y los Incrementos.
Product Backlog
Es una lista ordenada de todo lo que podría ser necesario en el producto y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto incluyendo su contenido, disponibilidad y ordenación.
Una Lista de Producto nunca está completa, siempre podrán aparecer más requisitos que se incluirán a ella.
Sprint Backlog
Es el conjunto de elementos de la Lista de Producto seleccionados para el Sprint y el plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint.
Es una predicción hecha por el equipo de desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”.
Incremento
Se le llama incremento a 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”, en condiciones de ser utilizado y cumpliendo la definición de “Terminado” del equipo Scrum.
El incremento debe estar en condiciones de utilizarse sin importar si el Dueño de Producto decide liberarlo o no.
Conclusiones
Scrum es una forma poderosa de trabajar que brinda velocidad y energía a los proyectos en los que se aplica, permitiendo que la creatividad de los participantes ayude a crecer el producto final de manera sostenida y coherente con las situaciones cambiantes del mundo real.
Referencias:
- La Guía de SCRUM
- “Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust” – Ken Schwaber y Jeff Sutherland – John Wiley & Sons, 2012
- “The New New Product Development Game” – Hirotaka Takeuchi y Ikujiro Nonaka – Harvard Business Review, 1986. Consultado en 17 de Enero, 2021
- Agile Manifesto 2001. Consultado e1 17 de enero, 2021
