Vamos hoy con un tema tan de base como poco claro en el mundo real, altamente importante e impactante, que tenéis que tener SÚPER CLARO para ir por el camino de la luz Ágil: que deberíamos planificar que se haga en un Sprint/Iteración/»trozo» de tiempo (por si usas Kanban) y voy a dejar para otro post… cómo deberíamos luchar y esperar que termine un Sprint/Iteración/»trozo» de tiempo (si es Kanban).
Antes de que se me pase, ESTA ES LA ÚLTIMA SEMANA, y últimas plazas, para ser parte del 
AGILE TRANSFORMATION PROGRAM 2022,
aquí está la WEB, una formación única (y yo sabes que esto no lo digo por decir y queda bien, sino pregunta a los alumnos del año pasado) en Agilidad, online, desde cero, recorriendo todas las áreas, en la que tú pones el horario durante 3 meses con dedicación moderada, pero con soporte, directos y reuniones «one to one» conmigo. Y sin tonterías, esta es una formación para aprender y desde experiencias reales, no para sacarse un sello.
Volviendo… en un ciclo de vida Ágil, buscamos tener cuanto antes «Working Software (o solutions, si no es software)», es decir versiones operativas (que no necesariamente liberables, aunque queremos liberar cuanto antes, recuerda MVP, dejo vídeo), con la idea de aprender del mundo real, inspección adaptación, verificar que es viable hacerlo y que aporta a los usuarios, porque los usuarios saben lo que quieren cuando ven algo funcionando, etc.
Y cuando digo buscamos tener CUANTO ANTES «Working Software» es COMO MUCHO al final del Sprint/Iteración/»trozo (ojo al como mucho, que NO es al final del Sprint, es durante, cuanto antes).
Entonces, según esto…
¿Qué sería deseable que se planificara como entrada a un Sprint/Iteración/»trozo» de tiempo?
Es obvio en este punto decir que… cosas que incrementen funcionalmente al final del Sprint/Iteración/Trozo de tiempo el Working Software/Solution. Y aquí sería interesante clasificar que pueden ser alguno de los siguientes.
- Algo que aporta Valor al usuario mediante el aumento funcional, o mejora percibida por él, del producto Working Software/Solution. Lo que nos deja dos los opciones
- Resolver un problema en el producto que le está afectando
- Una aumento funcional (añadir algo nuevo que al producto/servicio)
El caso a) manifiesta resolver una ineficiencia introducida con anterioridad que puede ser de máxima prioridad pero que no debe ver con buenos ojos nuestro proceso, por ello, al final del Sprint debéis diferenciar cuantos errores habéis resuelto de cuantas funcionalidades introducidas, siendo los errores…. INEFICIENCIAS. Por eso hay que diferenciar incremento funcional, de error, siendo el error desperdicio.
Y no es lo mismo eficiencia del proceso que velocidad. A este tema le dedico un buen rato en el AGILE TRANSFORMATION PROGRAM, y habrá más post en el blog y si queréis le dedico un post en el futuro.
En lo que refiere al caso b), que es lo más deseable que cope el Sprint/Iteración, es difícil saber a priori, de hecho es imposible, es más, solo podemos suponerlo, porque no sabemos lo que aporta Valor hasta que algo está en el producto y lo contrastamos con usuarios reales, pensar de otra manera sería una contradicción «Ágil» (de esto habla el Hypothesis Driven), por ello lo correcto sería hablar de «Algo que tiene ALTAS PROBABILIDADES de aportar valor al usuario mediante el aumento funcional del producto Working Software/Solution».
Lo que si que tenemos que tener claro, IMPORTANTE, es que aun no sabiendo si le aportará Valor (le gustará, lo comprará, le resolverá un problema, etc.), tenemos que buscar introducir en el Sprint/Iteración/Trozo de Tiempo cosas DE ALTA PROBABLIDAD:
- Funcionalidades, además, priorizadas.
Lo cual, IMPORTANTE OTRA VEZ, deja fuera cosas de baja probabilidad, como aquellas que no puede ver, es decir TAREAS:
- Diseños, pruebas, análisis, informes, papeles de uso interno, desarrollos parciales, etc.
¿Son necesarios todos los anteriores? Probablemente sí, quizá no, puede que si pero en un menor número o en menos tiempo, o quizá no, pero, en cualquier caso, deberían colgar de FUNCIONALIDADES que si tienen alta probabilidad de aportar Valor, hasta el punto de que, como pasó antes con los errores, deberíamos separar el número de Tareas realizadas en el Sprint/Iteración/Trozo de tiempo de los incrementos funcionales… y las tareas no incrementan por si solas el Working Software/Solution (de hecho, no puedo hacer demo de ellas al usuario REAL).
Consejo añadido de todo esto: mide la eficiencia (o lo bueno que ha sido el Sprint/Iteración/Trozo de tiempo, si la terminología te produce confusión) SÓLO en nuevas Funcionalidades convertidas en Working Software al final del Sprint/Iteración/Trozo de tiempo, todo lo demás son cosas Oscuras, Sospechosas o no concluyentes.
Que la Agilidad te acompañe Rebelde ágil.
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