Hay ideas que aún no estando literalmente en el manifiesto Ágil «compilan» muy bien con una cultural Ágil. Ideas como el «divide y vencerás», ya sabes: lo complicado, difícil, riesgoso, crítico, etc., trátalo en descomposiciones lo más pequeñas posibles (ejemplo de ello son las Historias de Usuario y el Product Backlog).
O ideas como aquella de que lo que «más duele», lo complicado, difícil, riesgoso, crítico, etc., es mejor hacerlo cuanto antes y muchas veces (ejemplo, la integración continua, el Test-Driven y frecuente, etc.).
Ideas como el «divide y vencerás» o que «lo que más duele hazlo antes y muchas veces» buscan enfrentarse a los problemas cuanto antes y cuando aún la solución es manejable, frente a dejar las cosas para luego, para el final y encontrarse con un monstruo difícil de gestionar (como pasaba, por ejemplo, en los tiempos de las grandes integraciones al final «del proyecto»).
La propia idea de «Sprint» es un ejemplo más de «lo que más duele hazlo antes y muchas veces» y de «divide y vencerás» aplicado al tiempo, frente a las antiguas, y grandes, fases de los antiguos proyectos. El Sprint, al ser corto y frecuente, permite la inspección y adaptación continua.
Pero, aún así, el propio Sprint, aún siendo típicamente de unas semanas, puede llegar a ser grande para reconducir una mala estimación, problemas en el alcance acordado del Sprint, en el objetivo del mismo, etc.
De nuevo, hay ideas que refuerzan el «divide y vencerás» y el «lo que más duele hazlo antes y muchas veces» incluso dentro del propio Sprint, un ejemplo es el Swarming (te dejo dos post, el importante y desconocido Swarming, “flujo continuo de una sola pieza” o One-Piece Continuous Flow y el secreto de los Dailys en equipos de alto rendimiento), terminar Historias cuanto antes frente a empezar con todas las Historias.
Y, en línea con lo anterior, con esto de mejorar la gestión de los Sprints, hay una idea que quiero destacar, resaltar su importancia y a la vez manifestar el gran olvido que sufre: dentro de un Sprint, y cuánto antes, hay que saber si vamos bien o mal. Suena aparentemente fácil, razonable, suena a «lo que más duele hazlo, o conócelo, antes y muchas veces» y a «divide y vencerás» ¿no?
Saber cuanto antes cómo vamos es, por ejemplo, saber si vamos a cumplir el compromiso del Sprint, las Historias, o Items, que, de manera auto-organizada, el equipo técnico se comprometió a hacer. Saber cuanto antes si hay un problema de estimación, o un gran riesgo no detectado, o una Historia atascada, etc., permite tomar decisiones lo más pronto posible.
Pues, siendo lógico, y Ágil, lo increíble es el número de equipos que no saben si van a llegar al compromiso del Sprint hasta que se acerca su final. Y que no han pensado en una manera de saber cómo va «la cosa» sin esperar a lo obvio… el final del Sprint.
Aunque en pocos equipos, también he visto decenas de maneras de ingeniárselas para saber cómo vamos en el Sprint lo antes posible. Cada uno se ha buscado la suya. Cada manera depende de cómo sean tus Historias de Usuario (¿Por qué las Historias de Usuario deben ser lo más pequeñas posible?), de cómo se estime, si en Puntos Historia por complejidad, o por tiempo, o usando frutas, etc.
En cualquier caso, busca una manera de saber cómo va el Sprint, cómo va cada historia, si llegamos, cuanto antes… eso suena más Ágil que esperar al último día del Sprint.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024