Extracto del libro de Santi García La resiliencia de las organizaciones

Scrum es un método de trabajo pensado para gestionar proyectos complejos que parte de un doble presupuesto: a) que en un contexto de cambio las necesidades y expectativas de los clientes son muy volátiles, y b) que en un proyecto complejo casi inevitablemente se plantearán desafíos imprevisibles. Es decir, partiendo de que el problema al que el proyecto trata de dar respuesta no es posible definirlo completamente desde el principio, el método Scrum se enfoca en maximizar la capacidad del equipo para avanzar rápido, responder a cambios en los requerimientos de clientes o usuarios y adaptarse a la evolución de las tecnologías y los mercados.

Este método es producto del trabajo que durante los años noventa llevaron a cabo, primero en paralelo y posteriormente de forma conjunta, Ken Schwaber, Jeff Sutherland y otros entusiastas del uso de métodos ligeros e iterativos para el desarrollo de nuevos productos. Este trabajo se plasmaría en sus contribuciones al Manifiesto Agile en 2001, y en la difusión del Scrum a nivel mundial.

Los dos aspectos más distintivos del método tienen que ver, en primer lugar, con los roles en que se dividen las responsabilidades de los miembros de los equipos que realizan los proyectos y, en segundo lugar, con la forma en que se gestionan los flujos de trabajo. Respecto a la primera cuestión, en el método Scrum, los equipos de proyecto disfrutan de un alto nivel de autogestión, persiguen un único objetivo —el objetivo de producto— y son multifuncionales. Dentro de ellos se diferencian tres roles principales:

El propietario de producto (product owner), responsable de los resultados de negocio del proyecto. Es quien representa la voz del cliente y demás stakeholders del producto ante el equipo, y quien representa al equipo frente a estas partes interesadas. Es también quien define el producto en términos de resultados para el cliente o usuario, y quien prioriza los trabajos.

Los desarrolladores (developers), una categoría que no solo incluye a programadores de software sino a cualquier persona que desempeñe un papel de desarrollo o soporte del sistema o producto. Los desarrolladores están empoderados y se organizan ellos mismos. De hecho, el propietario de producto no les dice cómo deben llegar a una solución técnica, sino que busca consenso entre los miembros del equipo. Respecto a la relación de los desarrolladores con los clientes, aunque todo el trabajo debe llegarles a través del propietario de producto, se les anima a que interactúen con los clientes para que la retroalimentación sea lo más directa y rápida posible.

El scrum master, cuya principal responsabilidad es facilitar el trabajo a los miembros del equipo, liberándoles de distracciones, asegurando que conocen y cumplen la metodología de trabajo y los principios sobre la que esta se basa, y ayudándoles a crecer y a desarrollarse.

Respecto a la forma en que se organizan los flujos de trabajo, podemos distinguir varias actividades características:

Los sprints son la unidad básica de trabajo. Se trata de un esfuerzo colectivo de una duración fijada de antemano (habitualmente entre dos y cuatro semanas). El sprint arranca con una sesión de planificación en la que se establece el objetivo (lo que el equipo entregará al cliente siguiendo las prioridades que ha marcado el propietario del producto) y se documenta el trabajo a realizar en una lista de tareas pendientes denominada backlog.

Durante el sprint, a diario el equipo realiza un scrum, una reunión de una duración máxima de 15 minutos, en la que todos los miembros del equipo suelen permanecer de pie y en la que revisan los progresos realizados e identifican los obstáculos a que se enfrentan. (Aprovecho para aclarar que scrum es la palabra inglesa con que se designa lo que en castellano conocemos por melé, la jugada de rugby en la que varios jugadores de cada equipo se entrelazan para volver a poner en juego el balón).

Al final de cada sprint el equipo comparte el trabajo realizado con las partes interesadas, y estas le proporcionan retroalimentación. Para los propietarios de producto estas sesiones de revisión de sprint son una gran oportunidad para revisar la lista de tareas pendientes (backlog). La duración recomendada para estas sesiones es de una hora de revisión por cada semana que haya durado el sprint.

Asimismo, el equipo mantiene una sesión de retrospectiva para extraer aprendizajes de lo sucedido durante el sprint. En esta reunión interna, cuya duración recomendada es de una hora y media por cada dos semanas que haya durado el sprint, el equipo reflexiona sobre las cosas que han salido bien durante el sprint, lo que no ha salido bien, y lo que, a partir de esos aprendizajes, podrían hacer diferente en el siguiente sprint.

Otra actividad destacable del método, aunque no es un evento concreto sino parte del flujo diario de trabajo, es el refinamiento de la lista de tareas pendientes. Esta actividad, que se recomienda ocupe hasta el 10% de la capacidad del equipo, tiene como objetivo asegurar la calidad de los elementos del backlog que se incorporan al sprint y hacerlos más claros y ejecutables para los desarrolladores.

Esto es, en grandes líneas, en lo que consiste el método Scrum, uno de los denominados métodos ágiles que un número cada vez mayor de empresas utilizan para gestionar sus proyectos. Sin embargo, desde la perspectiva de este libro, tal vez lo más relevante sea entender por qué y en qué circunstancias surgieron estos métodos.

Estos métodos iterativos o ágiles, nacidos en el sector del desarrollo de software, surgieron como una alternativa a los métodos en cascada (waterfall) que se utilizaban tradicionalmente para gestionar proyectos en este campo. En los proyectos gestionados en cascada se toman los requerimientos del cliente al inicio del proyecto y el producto solo se entrega a este una vez que todo el trabajo del proyecto ha sido terminado. Es entonces cuando el cliente lo prueba y lo acepta o no.

El problema surge en entornos en cambio continuo, en los que la tecnología avanza muy rápido y las necesidades de clientes y usuarios pueden variar en respuesta a cambios en el entorno. En estos escenarios, el método tradicional en cascada puede llevar a que, cuando el cliente recibe el producto tras meses de desarrollo, los avances tecnológicos lo hayan dejado obsoleto, o ya no sea una prioridad para sus destinatarios. De ahí la idea de dividir los proyectos en ciclos iterativos e incrementales, como los sprints del método Scrum, en los que el equipo aprende a medida que introduce modificaciones en el diseño, añade nuevas funcionalidades y recibe retroalimentación de las partes interesadas que, con estos nuevos métodos, no tienen que esperar a la finalización del proyecto para recibir un producto

operativo. ¿Te acuerdas del concepto de producto mínimo viable de la metodología Lean Startup? Pues esa es la idea