¿Por qué falla Scrum a pesar de tener los roles puestos y hacer los eventos?
Por: Vanessa Amaya
Con frecuencia me buscan para decirme que Scrum no les funciona, que ya capacitaron a los Product Owners, a los Scrum Masters y a los Developers, que hacen los eventos de Sprint Planning, Daily Meeting, Sprint Review y Retrospectiva además de llevar los artefactos que requiere este marco de trabajo y que no les funciona.
Las razones que pueden estar relacionadas a esta situación que he encontrado con más frecuencia son las siguientes:
En las responsabilidades de los roles falla la facilitación del ENTENDIMIENTO entre los involucrados.
Se cambian los nombres de los roles pero se sigue operando igual.
Se llevan a cabo los eventos pero de manera superficial.
No se cambia la manera de programar / desarrollar el producto/servicio/proceso
No se cambia en lo absoluto la manera de recibir y analizar requerimientos.
Para este blog me voy a enfocar en el último punto de los antes mencionados.
Cambia la forma pero no cambia el fondo.
Cuando hacemos cambios en las responsabilidades, eventos y artefactos de los equipos, inevitablemente van a chocar con la realidad que los rodea y la primera de estar realidades es: LA DEMANDA DE REQUERIMIENTOS, ya que son éstos los que forman el Product Backlog, los que se mueven en el marco de trabajo transformándose en soluciones.
Cuando traemos arrastrando prácticas donde los análisis y las especificaciones son a alto nivel y se ven los proyectos con un solo bloque, este bloque puede estar lleno de imprecisiones y falta de claridad hacia aquellos que van a desarrollar / hacer realidad el entregable. La agilidad nos pide hacer entregas de valor frecuentes y esa frecuencia es posible al DIMENSIONAR de manera diferente los requerimientos e identificando con claridad el valor de cada uno de ellos.
Conciencia sobre la capacidad.
Si no tengo dimensionados los requerimientos, clasificados y priorizados, los Sprint Planning van a ser muy inefectivos y vamos a terminar diciendo que sí a todos y transformando el proceso analítico en una adivinanza o subasta al mejor postor del tiempo que nos puede tomar.
Scrum no tiene prácticas pero puede ser un excelente contenedor de prácticas y yo generalmente me enfoco con los equipos con los que trabajo en las prácticas relacionadas al dimensionamiento de requerimientos ya que la conciencia sobre la capacidad y el entendimiento de la demanda traen resultados de alto valor. A este contenedor, las prácticas implemento están relacionadas a Business Analysis (en su versión agilizada), Kanban y Visual Thinking para: organizar, agrupar y estructurar.
¿La Estructura se lleva con la Agilidad?
¡Claro que sí! La agilidad es un conjunto de disciplinas y contiene relaciones entre responsabilidades, eventos, prácticas y artefactos que mantienen entre sí las partes orientadas a la generación de valor y eso es tener estructura.
Las partes que se toman como insumo principal para la generación de valor son LOS REQUERIMIENTOS que en la agilidad están CENTRADOS EN LOS CLIENTES/USUARIOS FINALES así que si cambiamos y mejoramos las prácticas alrededor de la identificación, especificación, dimensionamiento y priorización de requerimientos, vamos a impactar directamente en la raíz de muchas de nuestras problemáticas.
Conclusión.
Las responsabilidades y los eventos de Scrum tienen como centro el producto y las personas. El producto se alimenta de requerimientos y las interacciones de las personas giran alrededor de ellos también. Son la esencia para el planning y para la generación de valor. Si cambiamos todo pero no cambiamos lo que envuelve a esta esencia tan importante, los cambios se manifestarán con mayor dificultad.
Cuando nuestras prácticas de dimensionamiento de requerimientos son efectivas nos ayudan a:
Diferenciar aquello que es importante.
Ayudarnos a tener un lenguaje común.
Entender el origen de los problemas y desafíos.
Modular la complejidad.
Nota: Si el problema en tu equipo Scrum está más relacionado a las responsabilidades, te dejo el siguiente Blog al respecto:
“Responsabilidades y actividades en un equipo Scrum: cuando se falla en la claridad”