Scrum: Entendiendo los Lead Times en el Sprint de Scrum

Queridos Scrum Masters, en la búsqueda de la mejora continua y la optimización de los procesos de desarrollo de software, es fundamental comprender los diferentes Lead Times y su impacto en la eficiencia de entrega. En este artículo, exploraremos los conceptos clave de Development Lead Time, Delivery Lead Time y QA Lead Time, y cómo pueden contribuir a acelerar el ciclo de desarrollo y despliegue en producción. ¡Vamos a sumergirnos!

El Lead Time y sus puntos límites

Primero revisemos de qué hablamos con Lead Time. Una definición Lean de "Lead Time es la cantidad total de tiempo que pasa desde que se recibe una solicitud de un cliente hasta que se entrega el producto o servicio solicitado. Incluye el tiempo de espera, el tiempo de procesamiento y el tiempo de transporte o entrega". Podemos ver esa definición como Lead Time Total de todo el proceso de desarrollo de features. Esa definición en Scrum no nos es tan útil, porque desde que un ítem entra al bácklog, se refina y se planifica puede pasar mucho tiempo y suele ser muy irregular. Otra definición que podemos usar, desde el punto de vista de un equipo Scrum, es que el Lead Time es el tiempo que transcurre desde que se compromete un trabajo para hacerse (no cuando comienza el trabajo) hasta que se completa el trabajo. Una vez que se compromete a entregar el trabajo (que en un equipo Scrum se da en la planning), el reloj de su tiempo de entrega comienza a correr.

Aquí hay una gran diferencia entre el momento en que el cliente da una solicitud (o se genera un nuevo ítem de backlog) y el momento en que el equipo se compromete a entregarla (Sprint Backlog en planning). No són la misma cosa. No debe comprometerse a entregar una solicitud en el momento en que llega. Si no es crítico, el elemento de trabajo debe pasar por su proceso Upstream (generación, priorización y refinamiento) antes de realizar su compromiso final (Sprint Backlog). Piense en su proceso Upstream (desde el punto de vista de equipo) como un embudo: no todos los elementos de trabajo pasarán, habrá elementos en los que se comprometa a trabajar ahora, otros que deje para más adelante y otro tipo que descartará por completo. 

No comprometa entregar un elemento de trabajo hasta que haya seleccionado ese elemento de trabajo para su próxima iteración. Y deje de corre el tiempo del Lead Time en el momento en que su trabajo llega a la columna "Terminado/Done", el 'delivery-point'. O sea que depende, en gran medida, de su Definition-Of-Done que permite pasar un ítem por el delivery-point.

En un equipo Scrum, los Lead Times que más nos importa son los que se encuentran después del punto de compromiso (commitment-point) hasta el punto de entrega (delivery-point).

Los tres Lead-Times más importantes en desarrollo

Para empezar, el Development Lead Time se refiere al tiempo que transcurre desde que se compromete e inicia el trabajo en una historia o requerimiento específico hasta que se completa el desarrollo del código necesario para implementar ese cambio. Incluye todas las etapas de desarrollo, como el diseño, la codificación, las pruebas unitarias y las pruebas de integración en el entorno de desarrollo. El "Development Lead Time" se enfoca en el proceso interno del equipo de desarrollo y mide su eficiencia en la implementación de cambios. En general, se considera que el Development Lead Time incluye todas las etapas desde el inicio del trabajo en la tarea hasta que el código está listo para ser entregado a las pruebas.

Por otro lado, Delivery Lead Time básico abarca desde su punto de compromiso hasta su punto de entrega. A nivel de ingeniería de software abarca, no solo el desarrollo, sino también las etapas posteriores, como las pruebas de integración en ambientes de QA y staging, la aprobación del producto, el despliegue en producción y la verificación en producción. Idealmente mide el tiempo total que lleva entregar un cambio en producción y ponerlo a disposición de los usuarios finales. 

La definición de "product delivery lead time" que se da en el libro "Accelerate" incluye el tiempo que lleva desde que se realiza la codificación hasta que se implementa en producción. En el contexto de medición del delivery lead time, se considera el momento en que se realiza el commit como el punto de partida para medir el tiempo que tarda el cambio en llegar a producción. A este "product delivery lead time" también lo podemos llamar "product delivery lead time" o "DevOps Delivery Lead Time".

Finalmente, el QA Lead Time: o "Quality Assurance Lead Time", se refiere al tiempo que transcurre desde que un cambio o desarrollo de software se considera listo para ser sometido a pruebas de calidad hasta que se completan dichas pruebas.

Los Lead-Times en el Sprint

Integrar eficientemente el Development Lead Time y el QA Lead Time dentro de un Sprint de Scrum es fundamental para lograr un proceso de desarrollo de software efectivo y generar un incremento de producto potencialmente entregable. Aunque el "santo grial" de Scrum es integrar los tres Lead Times, incluyendo el Delivery Lead Time, y que el Delivery Lead Time sea el Product Delivery Time, porque solo así es como se genera incremento de producto, entregado al usuario, dentro de un Sprint.

Aquí te presento algunas razones por las que esta integración es necesaria:

1. Entregas frecuentes y valor temprano: Al optimizar el tiempo de desarrollo, pruebas y entrega, el equipo puede realizar entregas frecuentes de funcionalidades al final de cada Sprint. Esto permite que el cliente o usuario final obtenga valor temprano y realimentación oportuna sobre el producto. Además, las entregas frecuentes también ayudan a identificar y corregir posibles problemas más rápidamente.
2. Adaptación y flexibilidad: Al integrar los tiempos de desarrollo y pruebas dentro del Sprint, el equipo tiene la oportunidad de evaluar continuamente el progreso y realizar ajustes si es necesario. Si se descubren problemas o desafíos durante las pruebas, el equipo tiene la posibilidad de adaptarse y tomar medidas correctivas para garantizar la calidad y la entrega exitosa.
3. Reducción de desperdicio: Integrar eficientemente el Development Lead Time y el QA Lead Time ayuda a eliminar actividades innecesarias y a reducir el desperdicio en el proceso de desarrollo. Al tener una colaboración estrecha entre los roles de desarrollo y QA, o desarrolladores fullstack y "t-shaped person" que desarrollan y hacen QA se evitan retrasos y se optimiza la utilización de recursos, lo que a su vez mejora la eficiencia general del equipo.
4. Transparencia y visibilidad: Al generar un incremento de producto potencialmente entregable al final de cada Sprint, o en el mejor de los casos un incremento entregado, se brinda transparencia y visibilidad tanto al equipo como a los stakeholders. Esto les permite evaluar y verificar el progreso realizado y proporciona una base sólida para la toma de decisiones informadas. La transparencia también promueve una comunicación abierta y una mayor confianza entre todos los involucrados para inspección y adaptación constante.
5. Mejora continua: Al medir y monitorear estos Lead Times, el equipo puede identificar oportunidades de mejora y establecer metas realistas para optimizar el proceso de desarrollo. Esto fomenta la mentalidad de mejora continua y permite al equipo implementar cambios y prácticas que impulsen la eficiencia y la calidad del producto.

En resumen, integrar eficientemente el Development Lead Time, el QA Lead Time y el Delivery Lead Time dentro de un Sprint de Scrum y generar un producto potencialmente entregable es esencial para lograr entregas frecuentes, adaptabilidad, reducción de desperdicio, transparencia y mejora continua. Esto asegura que el equipo de desarrollo esté enfocado en entregar valor de manera constante y satisfacer las necesidades del cliente o usuario final de manera efectiva.

Antipatrones

Siempre que queremos hacer algo bien podemos hacerlo mal. Los antipatrones son soluciones o prácticas contraproducentes que pueden generar problemas e impedir buenas prácticas, el buen desarrollo de software y la adopción del marco de trabajo. Identificar y evitar estos antipatrones es fundamental para lograr un desarrollo eficiente y de calidad.

Hay algunos antipatrones en Scrum que impiden integrar eficientemente el Development Lead Time, el QA Lead Time y el Delivery Lead Time dentro de un Sprint. Por ejemplo los siguientes:

• Scrumfall o Scrummerfall: Este antipatrón se refiere a la combinación de Scrum y Waterfall en un enfoque híbrido o en un Scrum cosmético. En este caso, el equipo puede realizar los eventos de Scrum, pero aún sigue una secuencia de desarrollo en cascada: desarrollan en un Sprint, hacen pruebas y certifican en el sprint siguiente y despliegan en otro. De esta manera es imposible terminar una historia de usuario que cumpla criterios INVEST dentro de un Sprint y cumplir un Definition of Done de calidad. Esto puede afectar la integración eficiente de los tiempos de desarrollo, pruebas y entrega en el Sprint.
• The Offshore Blender: Este antipatrón se refiere a la integración de un equipo offshore u outsourcing sin una comunicación ni colaboración efectiva entre los miembros del equipo. También cuando existe una falta de alineación entre la empresa cliente (que quiere adoptar Agile/Scrum) y el proveedor de Outsourcing (que no es Agile/Scrum) en términos de metodología de desarrollo.  Ocurre cuando, por ejemplo, un equipo externo hace el desarrollo, y el QA lo hace otro equipo interno de la organización. Esto puede afectar la integración eficiente de los tiempos de desarrollo, pruebas y entrega en el Sprint.
• Silos Work: Si hay un conocimiento limitado o exclusivo dentro de ciertos roles o equipos independientes, que trabajan en silos, puede haber una dependencia excesiva en individuos específicos para realizar tareas críticas. La existencia de silos, además, por lo general tiene aparejada burocracia. Esto puede provocar cuellos de botella y retrasos en el proceso de desarrollo, ya que los miembros del equipo no pueden trabajar de manera colaborativa, fluida y autónoma. Esto ocurre cuando un equipo hace el desarrollo, otro el QA y/o un tercero el despliegue a producción (o aprobaciones burocráticas).
• Little automation: la falta de automatización de pruebas puede llevar mucho tiempo realizar pruebas exhaustivas de manera manual. Esto puede aumentar el QA Lead Time y retrasar la entrega de software de calidad. La falta de automatización también puede aumentar el riesgo de errores y problemas de calidad.
• Poor Definition-Of-Done: una definición de "Done" pobre o/y su incumplimiento es un antipatrón común. Si el equipo no tiene una definición clara y consensuada de "Done" para cada elemento de trabajo, puede haber ambigüedad sobre cuándo se considera que una historia está completada. Tener un DOD pobre, por ejemplo uno que se limita a pasar solo historias que tienen los criterios de aceptación cumplidos pero deja fuera los requisitos de QA, peploy y delivery, es una manera de auto-mentirse o puentear la excelencia técnica y evadir la finalidad del Timebox y el DOD. Esto puede dificultar la integración y la entrega oportuna, ya que pueden surgir discrepancias sobre el nivel de calidad y finalización del trabajo.

Pueden haber muchos otros antipatrones que puedes investigar. 

Es importante que los Scrum Master y los equipos de Scrum reconozcan estos antipatrones (y otros) y trabajen en conjunto para superarlos. Al fomentar una cultura de colaboración, transparencia, automatización y mejora continua, se pueden eliminar estos obstáculos y lograr una integración eficiente de los tiempos de desarrollo, pruebas y entrega dentro de los Sprints de Scrum.

Referencias:

1. Nicole Forsgren, Jez Humble y Gene Kim: En el libro "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations".
2. Jez Humble y David Farley: En el libro "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation".
3. "The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations" por Gene Kim, Jez Humble, Patrick Debois y John Willis. 
4. "Testing in DevOps: A Guide for Software Testers and Anyone Involved in Software Delivery" por Katrina Clokie. 
5. Sonya Siderova, Lead time vs cycle time in kanban.

 

Agile Delivery: ¿Cómo podemos medir la productividad de nuestros equipos ágiles?

Una vez que se ponen en marcha un conjunto de equipos ágiles de desarrollo de software algún Gerente TI o un Delivery Manager suele hacer la siguiente pregunta: ¿Cómo podemos medir la productividad de los equipos ágiles? Y la respuesta rápida que surge es con la velocidad. Y aquí se puede complicar todo. Permítame aclarar que tanto las palabras productividad como velocidad son riesgosas de malas interpretaciones. Antes de usar la palabra productividad es preferible usar la palabra rendimiento o prestancia: es decir “performance”. Y cuando hablamos de velocidad, es preferible no pensar en velocidad como cantidad de entrega (cantidad de historias o cantidad de story points), sino como la rapidez de entrega (tiempo de entrega).

Métricas Agile

Un equipo ágil de alto rendimiento entrega software de calidad, funcionando en producción, de valor al cliente y a la compañía, en forma rápida. La velocidad está asociada a llegar rápido al cliente con funcionalidades de calidad y con valor. Aumentar la velocidad sirve para recibir feedback rápido del cliente, poder mejorar la propuesta de valor y adaptarse rápido. El rendimiento de un equipo, desde la perspectiva técnica de TI o DevOps, incluye esto. Bien, dicho esto… ¿Qué medimos? ¿Qué métricas de rendimiento podemos usar? 

Four Key Metrics o DORA Metrics

Nicole Forsgren, Jez Humble and Gene Kim nos ofrecen una buena respuesta en su libro Accelerate. Ofrecen una definición concreta y cuantificable del rendimiento de TI. Con cuatro métricas es posible comparar empíricamente, contrastar, clasificar y, posteriormente, mejorar el rendimiento de su equipo, de su tribu o área de desarrollo de software.

• Lead Time for Changes: el 'tiempo de entrega' (o Delibery Leat Time) es el tiempo que se tarda en pasar un ítem de requerimiento de cliente (historia de usuario) a inicio, hasta que está desarrollado y terminado (pasa el DoD). El reloj comienza, en un tablero kanban, cuando un elemento se mueve de la acumulación a cualquiera de los estados de "trabajo en progreso" y finaliza cuando el trabajo cumple con su definición interna de terminado DoD (por ejemplo, implementado y verificado en producción). El usado en DevOps es el Lead Time for Changes ("time it takes for work to be implemented, tested, and delivered"). El libro dice que se mide desde el primer commit de código hasta que se despliega en producción (“We measured product delivery lead time as the time it takes to go from code committed to code successfully running in production”). La parte de delivery del lead time —el tiempo que toma el trabajo ser implementado, probado y entregado—es más fácil medir.
• Deployment Frequency: la frecuencia de despliegue o Deployment Frequency es para medir la frecuencia con que se despliega en producción y conduce a que los lotes sean más pequeños (historias pequeñas), a hacer eficiente el pipeline de despliegue, mejorar el flujo de trabajo. Es probable que si la frecuencia aumenta entonces la performance también. 
• Mean Time to Restore (MTTR): (tiempo medio de restauración o Time to Restore Service) tiene más sentido medir la rapidez con que los equipos se recuperan de la falla que la frecuencia con la que ocurren. Un equipo performante es ágil para recuperarse de fallos. Aquí el reloj comienza cuando se produce una interrupción del servicio en producción y el reloj termina cuando se resuelve la interrupción. 
• Change Fail Percentage: (porcentaje de fallos de cambios o Change Failure Rate) una medida proxy de la calidad en todo el proceso es medir cuánto se falla en hacer cambios. Aquí se combinan dos contadores: uno para implementaciones y otro para fallas. El contador de KPI de Deployment Frequency se puede reutilizar para este caso. El segundo contador aumenta cada vez que se produce un fallo posterior (HOTFIX, OPCONS, roll back/forward, or patches, etc.). La tasa de fallas es la suma de fallas dividida por la suma de implementaciones en una ventana de tiempo dada. Mi consejo es que este KPI es reactivo, se correlaciona con la calidad pero a posteriori. Recomiendo usar además alguna métrica proactiva como: deuda técnica acumulada (Accumulated Technical Debt).

Por último, cabe aclarar que medir debería ser en función de mejorar y tener KPIs o métricas de rendimiento nos ayuda a eso, a mejorar. Sirve para mejorar el sistema de desarrollo de software o TI. Como dijo Jurgen Appelo: ¡Gestiona el Sistema y no a la gente! Por último hay que considerar que las métricas o KPIs se usan en función de metas, objetivos y propósitos. Los KPI solos y por si solos no sirve de mucho.

Referencias:

• The 4 KPIs Behind High-Performance IT May 31, 2018 By Adam Hawkins. 
• Accelerate – The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Gene Kim, Jez Humble, and Nicole Forsgren).
• Book Review: Accelerate.
• Measuring DevOps Success with Four Key Metrics.
• Article: ACCELERATE: SOFTWARE DELIVERY PERFORMANCE.
• Atlassian: DevOps metrics.
• Dora metrics.

Agile Delivery: No es buena idea medir la productividad de los equipos con Velocity en Story Points

¿Cómo medimos la productividad TI de nuestros equipos ágiles? ¿Y si usamos Velocity? Y, como nuestros equipos trabajan con Scrum… ¿Si usamos Story Points? mmmmm... ¡NO! Usar puntos de historia o días ideales para medir la productividad es una muy mala idea (es como medir líneas de código). Claro que parece lo más fácil, pero será definitivamente una fórmula para el desastre. Vamos a hacer que los equipos bajen su rendimiento. ¿Por qué? Por lo siguiente: 

1. Generará inflación y engaño: Hará que los equipos comiencen a inflar gradualmente el significado de un punto, perjudicando su estimación y degradando su trabajo. Recordemos que los puntos de historia son valores relativos, como una moneda, como el dólar. Si nos van a premiar por entregar más pesos, el equipo va a sentirse motivado y presionado para entregar los mismos dólares pero más pesos. Van a generar inflación. Quiere decir que un equipo inteligente, se dará cuenta de que si inflan gradualmente sus estimaciones en el transcurso de un año, alcanzarán su objetivo o incluso lo superarán, SIN entregar más valor a la organización. 
2. Sacará el foco metodológico de Scrum: El aumento de la velocidad no es el objetivo de scrum, sino que es entregar software funcionando, valioso y de alta calidad al cliente de una manera sostenible. Querer entregar más puntos les saca el foco. Puede hacer también que comiencen a contabilizar puntos por cualquier cosas: por hotfix, por spikes, por trabajos de research, etc. 
3. Disminuye la calidad: por la presión o necesidad de aumentar la velocidad los equipos harán concesiones para completar las historias adicionales necesarias para obtener los números más altos. Por entregar más dejarán de prestar atención a la calidad. Introducirán deuda técnica. Es decir que la calidad sufrirá inevitablemente cuando se toman este tipo de decisiones. Puede influenciar a bajar la vara de la definición de Terminado DoD para poder liberar puntos más fáciles. 
4. Frena el aprendizaje: Si el equipo de scrum aprende algo nuevo sobre una historia, la velocidad puede subir o bajar dramáticamente. Los Story Points varían durante la madurez del equipo. El equipo no debe alterar el trabajo de aprendizaje hecho al estimar honestamente. Al motivar la velocidad por puntos de historia se penaliza el fallo, lo cual degrada el aprendizaje. El equipo no querrá fallar. Una estimación puede estar muy lejos de la realidad, es una ESTIMACIÓN. Fallar estimando sirve para aprender. Por otro lado el equipo no va a querer dejar tiempo para investigar o innovar, ya que ese tiempo lo pueden gastar en hacer puntos. 
5. Generar competencia entre equipos en vez de colaboración: Cuando se miden puntos se suele caer en un intento de normalizar la velocidad entre varios equipos de scrum. Esto también es una muy mala idea. Esto puede hacer que los equipos se peleen por los puntos y a veces no quieran colaborar en puntos de otros equipos. Es una comparación sin sentido ya que los equipos de scrum tienen diferentes habilidades, objetivos, herramientas y enfoques para estimar el trabajo. Los Story Points son una métrica interna del equipo que le sirve para mejorar y autogestionar su trabajo. 
6. Puede generar culto, miedos y odios a Scrum: hay equipos que podrían usar el Método Kanban en vez de Scrum y no usar Story Points y ellos se verían afectados. Y otros pueden llegar a odiar Scrum si lo ven como herramienta de presión y estrés.

Por último, recomiendo reflexionar acerca de... ¿Por qué queremos medir la productividad de los equipos? McGregor nos decía con su Teoría X que hay gerentes o subgerentes que piensan que: “a los empleados no les gusta el trabajo, hay que obligarlos, controlarlos, amenazarlos o incentivarlos para conseguir metas”. Esta idea puede llevar a medir y controlar a la gente. En cambio, en agilidad no es esa la idea. Jurgen Appelo nos dice en Management 3.0 que: debemos gestionar al sistema no a la gente. Sumando la Teoría Y (de McGregor) a gerentes, debemos asegurar las personas correctas, liderar, formar, desarrollar competencias, hacer crecer la estructura, facilitar el trabajo, generar condiciones, asegurar infraestructura y facilitar recursos para que los equipos desarrollen software de calidad y de valor. Las personas se dirigen y se autocontrolan si están comprometidas con los objetivos. Los desarrolladores se pueden convertir en personas que desarrollen productos extraordinarios, en equipos de alto rendimiento; si tienen la libertad de desarrollar su potencial y las condiciones necesarias para desarrollar un propósito.

O sea, finalizando, la premisa es: “gestionar el Sistema y no a la gente”. Y si gestionamos el sistema de desarrollo de software de los equipos, entonces necesitaremos medir rendimiento de nuestro sistema de desarrollo de software compuesto por nuestros equipos y su infraestructura. Para eso desde el punto de vista de NEGOCIO deberíamos usar KPIs de negocio que indique la entrega de valor; y para la perspectiva DELIVERY TI (tecnología) son recomendables otras métricas de Performance, no Velocity con Story Points.
En próximas notas recomendaré KPIs de Performance.

Saludos.

Referencias:

• Should Companies Measure Productivity in Story Points / Ideal Days?
• SCRUM: VELOCITY MEASURES STORY POINTS, NOT PRODUCTIVITY.
• Is It a Good Idea to Establish a Common Baseline for Story Points?
• Jurgen Appelo - ManageMent 3.0 - Leading agile Developers, Developing agile Leaders.
• Douglas McGregor (1960), “El lado humano de las organizaciones”.

DevOps: Qué es DevOps

Se ha desarrollado el primer evento de Latam para DevOps, “Dev Ops Journey Latam” y mi equipo ha participado en este gran espacio para compartir conocimientos y experiencias.

 

¿De qué se trató el evento? ...compartir conocimientos relacionados a DevOps. Pero, para entenderlo hay que saber de qué se habla cuando se dice DevOps:

¿Qué es DevOps?

La integración a escala para que una Software Factory sea ágil y lleve adelante uno de sus principios, el Continuous Delivery, es lo que se denomina DevOps. DevOps es la integración de Ingeniería de Desarrollo de Software con la Ingeniería de Operaciones, que es todo el soporte IT y de plataforma para posibilitar que el proceso de desarrollo sea ágil, haciendo entregas frecuentes de calidad y logrando la colaboración entre el personal de desarrollo y el personal de operaciones a lo largo de todas las etapas del ciclo de vida de producción de software. DevOps es una parte central del agilismo en la entrega de software eficiente.

En palabras de James Betteley:

 “DevOps para mí es sobre la forma en que los equipos trabajan juntos colaborando para extraer un mayor valor de negocio y producir una solución de mayor calidad, trabajando como un equipo capacitado, y sin culpar a otros...” (James Betteley, What Is DevOpScrum?, DZone, 2016)

Una manera de integrar Operaciones con Desarrollo es mediante el uso de herramientas compartidas, misma cultura, comunidades en común, procesos ágiles compartidos, comunicación estandarizada, etcétera. Algo crucial en una organización madura es la automatización máxima en procesos de Continuous Integration, Continuous Delivery gestión del conocimiento y comunicación. En esta vía la gestión de riesgos y de impedimentos es importante herramienta de integración y cohesión para agilizar los procesos y detectar problemas en forma colaborativa.


Referencias:

• Implementación: http://agilismoeningenieriadesoftware.blogspot.com.ar/2016/12/scrum-gestion-agil-de-riesgos.html
• Modelo: http://agilismoeningenieriadesoftware.blogspot.com.ar/2016/10/scrum-gestion-agil-de-riesgos.html
• Encontrarás toda la información de las charlas en el sitio https://devopsjourney.it.lan.com
• What Is DevOpScrum?, DZone, 2016: https://dzone.com/users/912573/jamesbetteley.html.