Me cuenta nuestra Ms NoBody protagonista de hoy que tienen en su empresa un Product Backlog con unas 700 «cosas» (supuestamente Historias de Usuario).
Y que a la vez tienen un gran problema con los usuarios, porque cuando ven las funcionalidades implementadas en el producto (y las ven cada muchos meses)… rechazan la mayoría.
Y, por el problema anterior, nuestra Ms NoBody entiende que hay que trabajar aún más y más en detallar, revisar, priorizar, pulir, etc. (venga a echarles horas y horas), ese Product Backlog.
¿Qué os dice la anterior situación querid@s Rebeldes Ágiles? Pues sí, efectivamente, que estamos frente a un caso de Cascadermitis o síndrome del ciclo de vida en cascada autoimpuesto (también llamado Lado Oscuro).
Volvamos al principio
A ver, una de las grandes debilidades del cascada (dejo vídeo abajo) estaba en las grandes especificaciones de requisitos que se hacían de manera predictiva pensando que, dentro de mucho, una vez implementadas, eso sería lo que querría el cliente… y luego era que no. Que no quería eso (incluso aunque lo hubiera pedido).
Cuando tienes un Backlog gigante, por mucho Jira que tengas, y por mucho que le llames Historias a lo que hay dentro… estás exactamente en el caso anterior.
Es obvio decir que a Backlog más grande más «historias» habrá ahí abajo del Backlog que de implementarse se implementarán dentro de mucho (dicho desde otro punto de vista, un caso claro de desperdicio por tiempos de espera, como te contaba en el vídeo de abajo hace tiempo).
¿Y cuál fue la solución Ágil a todo esto? Pues tirar del viejo principio que nos enseñó la programación… el usuario sabe lo que quiere cuando lo ve. Entonces que lo vea, y que lo vea antes y de manera muy frecuente y que lo vea en producto real (no papel).
Y de ahí lo de escribe poco y habla más con el usuario y enséñale cosas operativas.
Y de ahí lo del ciclo de vida iterativo e incremental, y el working software (va post), y todo eso.
Hay que crear conversaciones frecuentes con el usuario, no Backlogs gigantes en Jira que nos fuercen a lo contrario
Los Backlog gigantes os llevan por el Lado Oscuro. Os desenfocan del verdadero problema, os hace centraros en perfeccionar un Backlog repleto de cosas que probablemente el cliente no quiera en vez de centraros en detectar lo que realmente el cliente quiere, hablando con él a la vez que se le enseñan versiones (muchas versiones).
De hecho… ¿no se creó en concepto de historia de usuario para conversar con los usuarios? Pues claro que sí. Entonces… ¿para qué creáis Backlog gigantes que provocan hablar menos con el usuario?
No olvidemos que cada Historia es «una promesa de conversación«.
Terminando
Todo lo que no aporta es desperdicio, y un Backlog grande es mucho desperdicio, con el problema derivado de la ingente cantidad de desperdicio en ordenarlo, gestionarlo, contarlo, hacerlo que implica.
En el título puse que con más de 20 cosas en el Backlog estamos frente a desperdicio. No sé si son 20, 15 o 25, lo que quiero que pienses es que debe haber pocas cosas. Las del Sprint presente, las del siguiente y poco más.
No dudéis en esto Product Owners o quien sea… borrar ahora sin que os tiemble la mano de la Historia número «20» en adelante de cualquier Backlog (hazle un Marie Kondo a los Jira). Si lo que había era importante ya saldrá de nuevo en el futuro, cuando le llegue su verdadera hora (y sino usa Epics en vez de Historias, que para eso están). Borrar todo eso, además, os va a llevar a trabajar en Dual Track.
Venga, que la Agilidad te acompañe, que mañana es viernes y termina Wandavisión.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Buenísimo Javier!!!
Me quedo con la frase de hazle un Marie Kondo al Jira! Jejej Y 100% de acuerdo con todo lo que dices!
Me muero con el hazle un Marie Kondo a los Jira… lo he visto en muchas empresas… un backlog que es imposible de priorizar y ordenar por la cantidad jajjaajaj
Conoces o recomendas un buen curso de Jira en español? Gracias por la nota!