Cosas antes de empezar…
Muy brevemente…ya hemos abierto las inscripciones para nuestro nuevo programa de FORMACIÓN ONLINE LOWCOST DE VERANO sobre Técnicas Agiles, con 4 masterclass en Video…Asíncronas… sobre:
- Técnicas de Estimación,
- Creación de Historias de Usuario,
- Priorización del Product Backlog y/o
- Retrospectivas….
Con un 50% de DESCUENTO hasta el 30 de julio para los primeros 30 inscritos. Tienes toda la información aquí: Verano Ágil
Continuamos….
Puede parecer obvio decir, y no que por ello no haya que decirlo, que la cultura se come a las herramientas, por muy aparentemente Ágiles que éstas pudieran parecer.
Esta semana tuve una profunda e interesante conversación con Mr. NoBody (por si eres nuevo por aquí, es el nombre en clave, Fast&Furious, que uso para mantener anonimatos) y parte de su equipo sobre si la gestión que llevaban (en Jira) era Ágil o cascada (por mucho que su proyecto Jira fuera tipo Scrum).
Recordemos, hay tres cosas principales (luego hay más como las fases, Think vs Do, gestión por documentos, etc.) que identifican a un cascada:
- Tener muchos requisitos/items/historias
- Liberar versiones cada mucho tiempo
- Testing muy tarde y al final del ciclo
En el caso de Mr. NoBody y su equipo se daban las dos primeras.
Aquel día empezamos por el tamaño del Product Backlog. La del tamaño es de esas “de libro”, cuando veo uno grande (este tenía más de 100 items), 9 de cada 10 veces no falla… hay cascada, Lado Oscuro (ya dejé un hilo con bastante movimiento en Linkedin sobre este tema) y luego viene el debate de justificarlo.
Una de las características esencial de un ciclo de vida en cascada es especificar muchos requisitos mucho tiempo antes de empezar a incorporarlos en producto/servicio. Muchos requisitos, o items, o Historias, en un Product Backlog ya implican, de por sí, que algunos se van a empezar a incorporar al producto/servicio dentro de mucho.
La cosa se puede hacer aún más complicada si añadimos la segunda característica de un cascada: Liberar versiones cada mucho tiempo.
Como siempre os digo, no nos quedemos en las modas y tengamos claras las razones: ¿Qué problema tiene lo anterior?
- Que al separar tanto la especificación de supuestas necesidades de su incorporación real al producto/servicio veamos muy tarde… que no se puede hacer, que no es viable (desperdicio en la especificación).
- Que mucho de lo especificado no dé tiempo a crearlo o no tenga sentido llegado el momento (desperdicio en la especificación).
- Que al sacar versiones tan espaciadas en el tiempo, cuando llega la incorporación de los requisitos/ítems/historias al producto/servicio… veamos, ya muy tarde, que no sirven o no gustan a los usuarios, ya sabes, “el usuario sabe lo que quiere cuando lo ve” (desperdicio en la especificación y en la creación)
Las soluciones a los anteriores supongo están claras, son típicas de ciclos de vida Ágiles: Acercar mucho más el momento de especificar al momento de crear y, como implicación de lo anterior, especificar poco a poco y tomando como base productos que funcionan y se enseñan a usuarios (lo que vendría ser el Dual Track, te dejo vídeo y te dejo post).
Dicho lo anterior, no queda duda, di no al Lado Oscuro… ¿o si hay duda? Toda regla tiene su excepción (o matización, o adaptación).
¿Qué pasa si, como le ocurre a Mr. Nobody, el producto que creas se instala en muchos clientes (nada de cloud aquí o web, hay que ir a la “fábrica” a ponerlo) y sus muchos clientes no quieren oír nada de añadir mucha funcionalidad (no es una ventaja competitiva)? ¡Porque no todo el mundo hace apps!
Entonces, en este caso, NOS ESTÁ TOCANDO NEGOCIAR, y ver si, como yo le llamo, aunque no lleguemos a un ciclo de vida ágil… “lo podemos Agilizar”, porque siempre puedes…
- Aunque liberes en 6 meses, tener más versiones antes en pre-producción que se validen por usuarios beta.
- Acortar el tiempo entre la definición de requisitos/ítems/historias (el Discovery) y su implementación en producto (el Delivery)
Ah, y antes de terminar, todo lo anterior lo estamos negocindo, pero la otra gran área de la Agilidad, el Peopleware, los equipos Ágiles… creo que no acepta mucha negociación, aquí aplica igualmente.
Que la Agilidad te acompañe.
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