Cuando me junto con algunos equipos, que trabajan en Ágil, etc., en ocasiones, la vida es así, hablamos sobre la eficiencia de su proceso. Hay otras ocasiones en las que hablamos de cultura Ágil, de equipo, de deuda técnica, de TDD, etc., pero, en este caso, este post, es una reflexión (otra más) sobre el tema eficiencia del proceso Ágil.
Hay cosas que aunque las escribamos miles de veces, estén en muchos libros, foros, conferencias, etc., para ciertos equipos no terminan de calar. Y una de ellas es esa de que «el software funcionando es la medida principal de progreso» (creo que no es necesario citar la fuente).
Y si no entendéis lo anterior, y aunque lo que voy a decir parezca una obviedad (sin serlo), pues haréis cosas que no están alineadas con hacer el máximo de historias funcionando al final del Sprint (no voy a entrar por enésima vez a explicar que hay que hacerlo sin meter deuda técnica, que otra cosa es el valor, que si ritmo sostenible, bla, bla , bla, para eso tienes post como 3 cosas que debes entender sobre la velocidad ágil o como por qué muchos piensan que hablar de velocidad no es Ágil).
Ya ni te cuento lo importante que tiene que ser para el Scrum Master entender, saber y hacer ver todo esto (más que hacer «happy» dinámicas de retros sin saber para qué).
Si no tenéis en la cabeza que hay que terminar el máximo de historias que aportan valor al incremento (o, mejor dicho, historias que tienen alta probabilidad de aportar valor, pero esto es otra historia), pues, pueden pasar cosas como, por ejemplo…
- Que nadie esté preocupado porque las Historias tengan un «time box» (una estimación de tiempo ideal, para entendernos) para que, una vez superado, hagamos algo, pensemos, levantemos una alerta, gritemos ¡ayuda! y evitemos tiempos indefinidos para terminar las historias (lo que provoca que se hagan menos historias en el Sprint).
- Que el «echar muchas horas» se vea como algo bueno, e incluso el «objetivo» para estar comprometidos con el Sprint (cuando el objetivo es acabar historias funcionando puestas en el incremento, típicamente en producción o preproducción), en vez de buscar estrategias para echar menos horas y terminar más cosas. Porque echar horas no necesariamente es lo mismo que ser eficiente (hay un post de hace 5 años que habla de esto, el de horas en la oficina vs ideas y conocimiento aportado).
- Que en los Dailys NO sea habitual hablar de qué historias ya han excedido el tiempo razonable que se suponía debían tardar y que, por ello, provocarán que terminemos menos «software funcionando». E, incluso, que ni se cuente el exceso de tiempo que llevan ciertas historias.
Y, así, otras tantas.
Interiorizalo, la eficiencia del proceso Ágil (otra cosa es la eficacia), es el número de historias que terminamos funcionando (normalmente en producción o preproducción, y, obviamente, testeadas). La eficiencia no es las horas que trabajamos.
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.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Me gusta que dos de las tres consecuencias negativas que anticipas tengan que ver con el control (entendido como comparación entre expectativa y realidad) del tiempo incurrido en algunas historias de usuario.
Siempre me confunde tu visión sobre el #noestimates, puesto que parece que lo describas como el escenario ideal, pero me resulta difícil compaginar este #noestimates con el control del tiempo incurrido en las historias que se complican o se estiran como un chicle.