Flujo de entrega ágil: Entrega siempre a tiempo en 3 pasos
Si se pregunta a la mayoría de los gerentes sobre la “seguridad psicológica” o la “visión” (más información en: seguridad psicologica ) de sus equipos ágiles de desarrollo de software, están de acuerdo en que estas cosas son importantes, pero… Cuando el cliente señala la urgencia o se acerca la fecha límite, todas estas variables “más blandas” suelen dejarse de lado. A los gerentes les preocupa principalmente un flujo de entrega ágil que funcione de manera predecible de su equipo ágil.
Si echas un vistazo a nuestro blog Echometer ( a nuestro blog ) has estado mirando, sabes que nuestro contenido se enfoca más en mejorar las “habilidades blandas” de los equipos y organizaciones. Los tomadores de decisiones a menudo subestiman esto. Pero no los Scrum Masters y los Agile Coaches.
Lo que, a mi juicio, los Scrum Masters y los Agile Coaches subestiman a su vez es la concentración en la mejora del flujo de entrega; básicamente, lo que quieren los gerentes. En la publicación de hoy, describo una técnica simple para aumentar significativamente la probabilidad de entregar a tiempo y dentro del presupuesto una y otra vez.
Paso 1 en relación con tu Flujo de Entrega Ágil
Me refiero a supervisar el flujo de entrega Ágil de tus tareas. Si haces unas pocas cosas bien, podrás obtener resultados mucho más predecibles. Incluso tus gráficos de dispersión del tiempo de ciclo o tu simulación Monte Carlo para calcular las estimaciones del proyecto podrían finalmente indicar predicciones válidas en lugar de estar completamente fuera de lugar (leer más: 9 Métricas ágiles para los responsables de la toma de decisiones ).
El primer síntoma a combatir es que hay tareas que tardan sólo unos días desde “Programadas” hasta “Completadas”, y luego hay tareas que tardan más de un mes. Para contrarrestarlo, debes asegurarte de que una tarea contenga siempre la versión entregable más pequeña posible de la función deseada. Sin campanas ni silbatos que no sean necesarios para la petición principal del cliente. Básicamente una MVT, Tarea Mínima Viable. Esto no significa que haga que todas las tareas sean pequeñas. Pero debería ayudarte a llegar a una fase en la que las tareas te lleven como mucho unas semanas, en lugar de meses.
Segundo paso en relación con tu Flujo de Entrega Ágil: WIP en lugar de Velocidad
Muchos Scrum Masters o Kanban Coaches creen que, para una medición válida de la velocidad, etc., es importante el “dimensionamiento correcto” de las tareas o los elementos de trabajo, en el que todos los elementos de trabajo tienen aproximadamente el mismo tamaño. Solo entonces los Story Points (necesarios para medir la velocidad) son útiles para medir la velocidad, porque se parecen más a una unidad de tiempo comparable.
Pero esto es erróneo: ni siquiera es necesario que las tareas tengan un tamaño similar. No deberías suponerlo, porque es demasiado difícil controlar las estimaciones del Punto de Historia. Lo único que puedes controlar es cuántas tareas nuevas empiezas.
Por lo tanto, haz lo siguiente para ser predecible: supervisa la tasa de “tareas recién iniciadas” en comparación con la tasa de “tareas completadas”. Estos dos deben estar en equilibrio. En otras palabras: la tasa de “entrada” y la tasa de “salida” de las tareas deben ser lo más cercanas posible entre sí, idealmente incluso coincidir.
Un ejemplo: el comportamiento típico en los equipos de desarrollo de software es que, en cuanto se bloquea una tarea, se inicia un nuevo elemento de trabajo. Esto lleva a que muchas tareas estén abiertas pero inacabadas, lo que hace mucho más complicado volver a desbloquearlas todas.
Si, en cambio, te aseguras de que por cada tarea iniciada haya también una tarea completada, será más fácil desbloquear las pocas tareas enfocadas en la Daily. Vuestro rendimiento será más calculable en general, y el equipo estará más satisfecho porque vuestro superior y vuestros clientes están más satisfechos.
Algunos “síntomas positivos” de un flujo de entrega ágil saludable
En la práctica, esto daría lugar a los siguientes comportamientos:
-
- No empezamos nuevas tareas cuando todavía hay muchas cosas en curso.
-
- Nos centramos en terminar lo que hemos empezado antes de empezar cosas nuevas.
-
- La antigüedad de las tareas nunca va más allá de unas pocas semanas.
-
- Si no hay una buena razón, siempre trabajamos en la tarea más antigua.
Los límites WIP (trabajo en curso) también ayudan en este sentido, aunque a menudo no son suficientes. Una vez que el equipo aprenda a centrarse en terminar las tareas en lugar de empezar otras nuevas, estaréis mejor que la mayoría de los equipos.
Cuando utilizas correctamente el Flujo de Entrega Ágil
Crear expectativas claras: De esta forma sigues sin poder controlar si una tarea lleva dos o tres días. Pero al menos te aseguras de que tu equipo no esté trabajando en tantas tareas que las de 2-3 días acaben llevándote un mes.
¿Cuánto mejor estaría tu equipo si supiera que básicamente todas las obligaciones de entrega se cumplirán en unas pocas semanas? Esto supone, por supuesto, que pongas en práctica todas las cosas mencionadas anteriormente: Establecer MVT, un límite estricto de WIP y el compromiso de no reiniciar las tareas hasta que se haya completado otra tarea.
Paso 3: Empieza a mejorar el Flujo de Entrega Ágil
En teoría, sabes lo que tienes que hacer. ¿Cuál es la mejor manera de empezar en la práctica? Creando conciencia y “disposición al cambio” en el equipo. En el mejor de los casos, a través de la autorreflexión.
Tienes que ser transparente con estas cifras y comprobarlas regularmente para ver si la proporción entre tareas iniciadas y completadas está equilibrada. Podría formar parte de tu retrospectiva profundizar un poco más y reflexionar sobre por qué las cifras no estaban equilibradas en el último ciclo.
Puedo recomendarte que discutas los comportamientos que he mencionado con nuestra herramienta de retrospectiva ágil Echometer en tu retrospectiva (leer más: 7 Herramientas retrospectivas en comparación ). Incluso podrías hacer que esto formara parte de tus acuerdos de trabajo o de tu chequeo médico periódico para concienciarte haciendo las preguntas con regularidad.
Las siguientes preguntas son nuestra plantilla de retrospectiva para la “entrega ágil” (más información en: 22 plantillas divertidas para retrospectivas ágiles ). Empezamos con unas cuantas afirmaciones de chequeo y preguntamos al equipo si tienden a estar de acuerdo o en desacuerdo. Después, hay algunas preguntas abiertas:
Retrospectiva de la entrega ágil
Puntos del chequeo médico
Hacemos las cosas muy rápido. Sin esperas, sin retrasos.
Podemos estimar exactamente lo que podemos entregar en un ciclo determinado.
Nuestros resultados del sprint no requieren ninguna revisión después del sprint para ser entregados.
Limitamos nuestro “trabajo en curso” para estar centrados en todo momento.
Preguntas abiertas
¿Cuándo ha funcionado realmente bien nuestra forma de trabajar?
¿Cuál es el mayor potencial de mejora para que los paquetes de trabajo pasen más rápidamente por nuestros procesos (eliminar tiempos de espera, mejorar los procesos)?
¿Cuáles fueron los ejemplos recientes de un incremento que no funcionó/no se pudo entregar al final del sprint?
¿Cuándo nuestra forma de trabajar ha conducido a un flujo de trabajo subóptimo? (por ejemplo, directrices poco claras, inadecuadas o no seguidas)
Como puedes imaginar, el último punto del Health Check (comprobar la causa) ya implica una medida potencial, algo que puedes probar durante uno o dos sprints ágiles para ver si podría ayudaros: la limitación del número de tareas con el estado “Work in Progress”.
Sentar las bases: Establecer acuerdos para el trabajo en equipo
¿Tienes la sensación de que tu equipo aún no está preparado para este tipo de reflexión? En este caso, primero debes reflexionar sobre el “buen trabajo” en general y luego establecer algunas reglas básicas, los llamados acuerdos de trabajo o Working Agreements. La siguiente plantilla de taller puede ayudaros con esto. Puedes realizarla como una forma especial de retrospectiva al comienzo de un proyecto o como un taller adicional.
Primero, debes tener una idea de cuán de acuerdo se siente implícitamente tu equipo; consulta el elemento de Health Check para esto. Luego debes verificar esto prácticamente con algunas preguntas abiertas. Cada miembro del equipo debe terminar la oración (ver más preguntas) con tantas respuestas como se le ocurran:
Retrospectiva de los compromisos del equipo
Puntos del chequeo médico
En mi equipo tenemos una comprensión común de lo que es un 'buen trabajo'.
Preguntas abiertas
Afrontar las prioridades conflictivas: "Si observo prioridades conflictivas, entonces...".
Comunicar los bloqueos: ‘Si me atasco en una tarea, lo comparto con …’
Afrontar los conflictos: ‘Si observo que surge un conflicto en nuestro equipo, entonces …’
Después de recopilar las respuestas, por supuesto, debes intentar encontrar patrones y acordar acuerdos concretos sobre cómo os gustaría colaborar en el futuro, al menos temporalmente como un experimento.
Una alternativa interesante y creativa
Si estos métodos de retrospectiva te parecen demasiado “áridos”, hay otro método de retrospectiva que se centra en reflexionar sobre la calidad del resultado de tu equipo ( Métodos retrospectivos Fun 54 se puede encontrar aquí ): La Retrospectiva de los “Tres Cerditos”. Es una alternativa sencilla para empezar a reflexionar y mejorar tu rendimiento, basada en el cuento de los tres cerditos que construyeron casas con distintos materiales.
Preguntas abiertas de respuesta
Casa de paja: ¿Qué hemos construido que solo se mantiene unido, pero que podría volcarse en cualquier momento? 🌱
House of Sticks: ¿Qué hemos construido que es relativamente estable pero que aún tiene margen de mejora? 🪵
House of Stone: ¿Qué hemos construido que sea sólido como una roca? 🪨
Conclusión: flujo de entrega ágil
No importa cómo empieces, lo más importante es empezar desde el principio. Los equipos que vigilan activamente su Flujo de Entrega Ágil son los mejores equipos.
Por cierto, muchas de las ideas que encuentras aquí también están bien resumidas en el podcast “Agile Bites”, que recomiendo encarecidamente (al podcast: Mordiscos Ágiles).
¡Diviértete desarrollando tu equipo!