El enfoque Ágil se está convirtiendo cada vez más en un tema de discusión entre equipos de la más diversa naturaleza, y no son pocos los que se plantean esta cuestión.
El Dr. Sutherland (2016), uno de los padres de scrum firma al respecto que:
“hemos descubierto que Scrum puede duplicar la producción de cualquier cosa, no importa si se trata de ventas, marketing, software, finanzas. Funciona en todas partes».
Tomando en consideración esta afirmación, y en base a mi experiencia, en este post exploraremos algunas ideas que podrían ayudarnos a transmitir la Agilidad al mundo de los proyectos que están más allá del desarrollo de software.
- Describir el alcance del proyecto a través del Backlog de Producto.
Una sencilla manera de comenzar es definiendo el alcance del proyecto en base a Épicas.
Las Épicas describen a grandes rasgos el alcance del producto o servicio objeto del proyecto; aquello que debe contener el entregable (output) objeto del proyecto, sea un CRM, una construcción, un ensayo clínico, una novela, etc.
Si consideramos el objeto del proyecto, independientemente de que sea un producto o servicio, como un libro, las Épicas serían los capítulos de dicho libro.
En un paso posterior, desglosaremos las Épicas en Historias de Usuario (User Stories, US), para definir con mayor precisión el alcance de los requisitos del proyecto.
La mayoría de enfoques y marcos de trabajo Ágiles, incluyen un rol responsable de priorizar y gestionar el Backlog de Producto. Por ejemplo, en scrum se habla del Product Owner o Dueño del Producto, mientras que otros, como Kanban, no establecen ninguna obligación al respecto.
En un entorno fuera del desarrollo de software, estas responsabilidades podrían recaer sobre el gerente o el responsable de una cuenta (cliente), o sobre el Project Manager.
Con las US podemos armar el Backlog de Producto, que es el elemento de gestión central de todo modelo Ágil.
Este artefacto, reúne todas las US del proyecto, es decir, el desglose de todos los “capítulos” de nuestro libro (Épicas). Es sobre este producto de gestión, donde se priorizan y se actualizan constantemente todos los requisitos que forman parte del proyecto, mayoritariamente en formato de US.
- Describir los elementos del Backlog de Producto en base a US
Las US nos permitirán establecer los requisitos del proyecto desde el punto de vista del usuario, y redactarlos siempre empleando un lenguaje sencillo y cotidiano.
¿Qué necesita o qué puede hacer el usuario que antes no podía hacer?
En el caso de un proyecto “empresarial”, las US podrían sustituirse por cifras u objetivos de negocio.
Por ejemplo, un aumento concreto en las ventas de un determinado producto o servicio que se espera lograr a través de una nueva campaña de ventas.
- Lograr resultados rápidos en periodos cortos de tiempo
En los entornos Ágiles el concepto time box es de vital importancia.
Hace referencia una cantidad máxima de tiempo, que en ningún caso puede excederse, y que se utiliza para planificar y ejecutar el trabajo del equipo.
En scrum se conocen como sprints, y respecto de un enfoque de gestión tradicional, se podrían asimilar a las fases de gestión de un proyecto.
El trabajo que el equipo decide ejecutar en un sprint o iteración (nombre genérico que reciben estos marcos temporales en el contexto Ágil), se plantea en una reunión de planificación.
En esta reunión, el equipo decide en base a su capacidad de trabajo cuántos elementos del Backlog de Producto puede acabar, y cómo se organizarán para ejecutarlos.
Es fundamental que los elementos entregados al final de un sprint o iteración, sean medibles y comprobables.
Las iteraciones deben ser los más cortas posibles, siempre y cuándo su tamaño sea suficiente para genera valor.
Trabajando en base a iteraciones o sprints cortos, se minimiza el riesgo de desperdiciar recursos, para los casos en que la dirección del desarrollo del producto/servicio no sea la adecuada. Además, trabajando en base a intervalos cortos se favorece la curva de aprendizaje.
- Seguimiento diario
¿Cómo se coordinan los equipos diarios? ¿Cómo se lleva el seguimiento del proyecto?
Los equipos Ágiles de trabajo se reúnen a diario para informar al resto de los miembros del equipo acerca del progreso y los desafíos que se encuentran en la ejecución del proyecto.
En scrum esta reunión se conoce como scrum diario o daily scum. En otros marcos o métodos de trabajo Ágiles se conoce como “reunión de pie”. Cómo su nombre indica es una breve reunión de pie, que como el resto de eventos de scrum debe cumplir con el concepto time box.
- Mejora continua
La retrospectiva es una de las prácticas claves de scrum.
Se trata de un evento que tiene lugar al final de la iteración, el último evento del sprint en scrum. Durante esta reunión el equipo aprovecha para examinar cómo ha funcionado el sprint y plantear pequeñas mejoras que se pondrán en marcha durante la próxima iteración con el propósito de mejorar de manera continua la forma de trabajo del equipo.
Al respecto, es fundamental que las reuniones de retrospectiva comiencen revisando las mejores puestas en práctica en la reunión anterior, y se decida sobre si las mismas deben o no continuar en marcha.
Otra forma de enfocar el trabajo de la mejora continua del equipo, es través de un Backlog de Mejora.
Desde un enfoque Ágil, y en el entorno del marco de trabajo scrum lo errores no son realmente un problema, sino que presentan la oportunidad de trabajar de manera aún más eficiente en el próximo sprint.
Consideraciones finales
Tanto la Agilidad como scrum, la manera más habitual de poner en práctica la Agilidad, se fundamentan en unos valores. Coraje, foco, compromiso, respeto y apertura, son los valores que cualquier equipo scrum necesita y deben tomar en consideración para iniciar con ciertas garantías de éxito un proceso de transformación Ágil.
Referencias bibliográficas:
Agilemanifesto.org <https://agilemanifesto.org/iso/es/manifesto.html> [Consulta 02/07/2019]
Openviewpartners (2016) <https://openviewpartners.com/blog/scrum-for-non-technical-teams> [Consulta 01/07/2019]
Scrum.org < https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf> [Consulta 02/07/2019]
Social Contact