Retrospective: Retro Improvement Kata

El Improvement Kata es una forma sistemática de establecer objetivos de mejora medibles y trabajar de manera iterativa para lograrlos a través de bucles cortos de aprendizaje. Para aplicar el Improvement Kata, necesitas saber dónde estás y hacia dónde quieres ir. Las iteraciones pueden ser tus Sprints si trabajas con Scrum y las planeaciones de mejoras las realizarías en las sesiones de retrospectiva. Es una manera de mezclar retrospectivas con Improvement Kata.

Los pasos de una retrospectiva tipo Kata pueden ser los siguientes:

1. VISIÓN: alineación (formalizar una visión). inicia con la visión que nos guía..
2. DESAFÍO: desafíos o estado actual (AS IS): define las condiciones actuales o desafío.
1. Utiliza visualizaciones simples y claras para representar el estado actual del equipo o del proceso.
2. Identifica desafíos (Challange) como áreas de mejora y oportunidades basadas en la realidad actual.
3. META: meta o estado siguiente (TO BE): elige tu próximo objetivo o meta..
1. Establecer objetivo siguiente (Target Condition): define un objetivo específico y alcanzable para el próximo periodo o sprint; y asegúrate de que el objetivo esté alineado con la visión y las metas a largo plazo.
4. OBSTÁCULOS: Detecta obstácules (Obstacle) que impiden alcanzar los desafíos.
5. EXPERIMENTOS: Idea experimentos accionables (Experiment): con el objetivo en mente, realiza brainstorming sobre posibles acciones y experimentos concretos; y prioriza estos experimentos según su impacto y viabilidad.
1. Cierre de retrospectiva.
6. Ejecutar experimentos (luego de la retrospectiva): 
1. Implementa los experimentos planificados durante el periodo especificado.
2. Documenta los resultados y observaciones cuidadosamente.

Lienzo:

Recomendaciones

La mejora continua con Improvement Kata requiere más de una retrospectiva, ya que es un proceso continuo. Algunas recomendaciones son las siguientes:

1. La visión (Vision): la visión proporciona la dirección y los límites para la mejora. A menudo eso significa definir una visión que contenga las capacidades centrales que la definen.

2. Un Desafío (Challenge) es un subconjunto de la Visión:

1. Plazo de 2 a 6 meses.

2. Solo trabajas en un desafío a la vez.

3. Meta o una condición objetivo (Target Condition) es un subconjunto del desafío:

1. Plazo de 4 semanas.

2. Simplemente trabaja en una condición objetivo a la vez.

4. Obstáculos (Obstacles) es una cuestión específica que no nos permite alcanzar la Condición Objetivo:

1. Cronograma de varios experimentos.

2. Simplemente trabajas en un obstáculo a la vez.

5. Experimentos para superar obstáculos:

1. Plazo de uno a diez días.

2. Simplemente ejecuta un experimento a la vez.

Ejemplo de visión

La visión puede ser algo simple o algo más sofisticado.

Por ejemplo, para definir una visión para buscar mejoras conducentes hacia un ecosistema Agile, podemos definir una que contenga las capacidades centrales que definen lo ágil para la organización. Jesper Boeg define, en su libro (Level Up Agile With Toyota Kata), ocho capacidades que las organizaciones ágiles deberían esforzarse por establecer:

1. Alineación estratégica.
2. Equipos empoderados y autoorganizados.
3. Equipos estables de extremo a extremo con una asignación del 100%.
4. Siempre lanzable: todo el trabajo, en cualquier momento, completamente automatizado a pedido.
5. Pequeños lotes (MVP, MVF), siempre con un enfoque de afuera hacia adentro (desde la perspectiva del cliente).
6. Gestión visual: plena transparencia.
7. Retroalimentación continua cualitativa y cuantitativa del cliente y del usuario final.
8. Flujo uno a uno (Limitar el trabajo en progreso).

Una visión más simple es como la del siguiente ejemplo.

Ejemplo de resultado de retrospectiva

Visión: 

• Mejora Continua basada en Datos: En nuestra incansable búsqueda de excelencia técnica, nos comprometemos a mejorar continuamente basada en datos de nuestro desarrollo de software, reconociendo que el rendimiento de nuestros equipos es la esencia de nuestro éxito, y que las Four Keys Metrics, son nuestro faro guía para medir y perfeccionar nuestras prácticas.

Desafíos: 

• Transparencia y Medición Efectiva: La falta de visibilidad, datos, métricas significativas y la incapacidad para medir 4KM, dificultan saber cómo estamos basados en datos.

Metas (Target Condition): 

• Paneles de Métricas: Disponer de Paneles de Métricas basadas en 4KM y paneles de métricas de equipo, usando como fuente de datos Jira y GitHub.

Obstáculos:

• Necesidades de Educación y Capacitación: Los miembros del equipo pueden no estar familiarizados con la interpretación y uso efectivo de métricas como 4KM.
• Ausencia de Una Cultura de Transparencia: En entornos donde la cultura de transparencia no está arraigada, los equipos pueden ser reacios a compartir métricas públicamente.
• Malas prácticas en el uso de GitHub y Jira: Los equipos no tienen acuerdos comunes relacionados a flujos de trabajo, prácticas de actualización de Jira, integración de Jira con GitHub y mensajes en los commit a repositorios.
• Consenso en la Definición de Métricas Relevantes: Puede ser desafiante identificar las métricas más relevantes y significativas para el rendimiento del equipo además de Capacidad: Capacidad (en esfuerzo/tiempo) de personas para invertir en desarrollar herramienta de reportería de 4KM.

Experimentos:

• Capacitaciones 4KM y buenas prácticas Jira/GitHub.
• Configuraciones Jira y GitHub.
• Desarrollo de Dashboards de Jira basados en 4KM.

Referencias:

• Atlassian: Using Improvement Kata to support lean.
• https://danlebrero.com/2021/01/06/toyota-kata-in-software-development-continuous-improvement/
• https://www.youtube.com/watch?v=-InKsQQY9Vk&ab_channel=GOTOConferences
• InfoQ: Q&A on the Book Level up Agile with Toyota Kata.
• Level Up Agile With Toyota Kata.

Jira: Odiemos a Jira

 "¡Hey, parece que está de moda criticar a JIRA! 

Normalmente, no suelo ser el tipo de persona que defiende a capa y espada una tecnología en particular, ni siquiera si la adoro. Sin embargo, creo que es importante odiar las cosas por las razones correctas. Si es que, a fin de cuentas, JIRA sigue siendo simplemente la mejor herramienta para rastrear tareas personalizadas con flujos de trabajo a medida, y además permite realizar búsquedas y reportes súper potentes sobre ellas. Ahí está la clave: "a medida". Sí, hay un montón de plataformas que cobran lo mismo o menos que JIRA y te ofrecen un espacio chulo para tus proyectos, pero generalmente se les olvida una de las funciones de personalización o búsqueda que mencioné antes.

Pero, entonces… ¿Por qué se suele odiar a Jira?

Las razones más comunes que escucho para odiar a JIRA son:

• Es demasiado complicado.
• Paso más tiempo haciendo seguimiento de tickets que trabajando.

Odian al micromanagement

Si crees que JIRA es demasiado enredado, es porque alguien que lo configuró metió más estados en el flujo, más flujos, más validaciones, pos-funciones, pantallas y campos de los que realmente necesitas para tu trabajo. 

Una búsqueda rápida de "flujo de trabajo complicado en JIRA" nos da esta imagen de idalko.com, parece ser un grupo que ayuda a la gente con sus procesos empresariales. Esta es su manera de cómo NO se hace un flujo de trabajo.

Si tu flujo es así, no odias a JIRA, odias a tu gerente que metió todo eso para saber en qué están en cada momento del día o a tu organización que es muy burocrática y complicada, con procesos enredados y alguien configuró el enriedo de tu organización. 

A ver, JIRA es una herramienta genial para armar flujos como ese, pero no puede impedir que la gente lo use mal. JIRA es tan complicado como tú lo configures. Viene con flujos de trabajo bien sencillos y muy pocos campos en la página. En 5 minutos puedes estar listo para seguir tareas que van desde "Abierto" a "En progreso" y luego a "Cerrado". 

¡Vamos, eso no es pedir mucho! Cualquiera debería poder dar esa cantidad de información sobre su tarea. Aunque esto es útil para metodologías como GTD o para simples tareas, cuando trabajamos con software y con marcos de trabajo como Scrum o Kanban esa simplicidad es algo contraproducente y escueta. También he trabajado en empresas donde equipos tienen flujos y estados super simples y pasan un año y siguen sin hacer testing, demorándose en subir a producción meses y con pésimas prácticas de ingeniería de software. El flujo de trabajo debe servir para coordinarse y para entender el trabajo y mejorar. Según Scrum debe servir para transparencia, inspección, adaptación y mejorar. Y en Kanban debes reflejar tu flujo real de trabajo para encontrar cuellos de botella y mejorarlo. Lo difícil es encontrar un punto medio y simple.

Odian a sus no-gerente

El otro problema común es el no-gerente, el "gerente" que no habla contigo y no sabe mucho sobre lo que estás haciendo. Solo quieren echar un ojo a un tablero, ver todas las luces verdes y contarle a sus jefes que todo está bien. Este tipo de gerente te pide estimaciones detalladas de tiempo (deadline), 15 pasos en el flujo de trabajo y actualizaciones diarias. Claro, JIRA es una herramienta que puede hacer todo esto, pero no significa que deba hacerse. JIRA no reemplaza la necesidad de gerentes hábiles y líderes de equipo que realmente sepan qué está pasando, que confíen en sus equipos, que generen claridad, empoderamiento y faciliten el proceso.

Odian a cualquier gerente (a la transparencia)

Seamos sinceros: quizás no sea tu gerente, quizás seas tú. En algunos proyectos en los que he trabajado, el seguimiento de tareas no es precisamente bienvenido, pero también rechazan la agilidad (Agile).

Hay gente que prefiere que le asignen tareas, tener mucho tiempo para hacerlas, a su ritmo lento, y asegurarse de que nadie más sepa cómo hacer su trabajo, no sea que los reemplacen. 

Yo creo que siempre habrá trabajo para gente hábil y trabajadora. Las habilidades que necesitas pueden cambiar, pero siempre habrá trabajo por hacer. Enfoca tu tiempo en perfeccionar esas habilidades y en encontrar un buen lugar para trabajar, en lugar de tratar de proteger tu empleo actual escondiendo lo que haces.

Odian Aprender

Hay quienes odian a Jira porque no quieren aprender a usar herramientas nuevas. Probablemente esperaban que JIRA fuera como un botón mágico para manejar tus actividades o desarrollos. Quieren las funciones que ofrece, pero no quieren invertir tiempo en aprender a usar la herramienta. O peor aún, odian aprender y mejorar, y si tienen que dar transparencia de su trabajo y de cómo trabajan pueden quedar en evidencia, de que son persona de mentalidad fija y conformistas de su zona de confort, que puede ser desordenada y poco productiva. Entonces les molesta transparentar su forma de trabajar.

Buscar el equilibrio

Mi consejo es encontrar el punto medio: ni flujos muy simples que no sirven para mejorar ni coordinarse ni flujos super complicados; ni issues con descripción vacía y títulos que no dicen nada, ni issues que sean un documento de requerimiento detallado (exceso de documentación); tampoco ausencia de issues, ni el extremo de estar detallando toda tarea que se hace; ni NO reflejar esfuerzo, ni tampoco estar trackeando todos los días cada hora en que se ha consumido (micromanagement).

Pienso que un flujo de trabajo más simple que sirve para gestión, iniciativas, Scrum y Kanban es el siguiente: 

Para historias de trabajo de desarrollo de software me ha servido algo bien simple como: Backlog, Selected For Development, In Progress, Ready for Accept, Done, Closed. La separación de Done a Closed es para reflejar que puede haber un tiempo de incremento potenciablemente entregable (pasó una definición de terminado) a entregado (listo en producción). Sino el estado Closed es inecesario. O algún flujo semejante como el siguiente.

Cuando configures Jira y lo uses, piensa en lo siguiente:

• Aplica los valores y principios del manifiesto ágil, de Scrum o Kanban.
• Los flujos ni tan simples ni complicados, con estados grises al principio (pocos), estados azules en el medio y verdes al final (uno o pocos).
• En los flujos no agregar validaciones, ni pantallas emergentes ni pos-funciones. Solo alguna si es necesaria.
• No agregar muchso campos personalizados.

Jira es una plataforma inmensamente poderosa y, con un poco de trabajo y planificación, puedes asegurarte de que esté configurada exactamente como deseas. Como resultado, podrás desbloquear un enorme aumento en la productividad.

Referencia: 

https://jarvispowered.com/you-dont-hate-jira-you-hate-your-manager/

https://www.smartsheet.com/jira-workflow-best-practices

Retrospective: Check out o feedback final

 

Esta actividad permite identificar si nuestra reunión está causando el efecto esperado o si tiene puntos de mejora. Es una actividad de salida ocurre justo antes de que los participantes salgan de la reunión. Por lo general, recopila información sobre la reunión en sí: qué tan valiosa fue, cuánto se aprendió, qué tan valiosa fue la reunión, cualquier comentario específico o estado de ánimo de salida.

El resultado de la actividad de salida puede contener comentarios valiosos sobre la estructura y el contenido de la reunión. Considéralo cuando planifiques la próxima reunión.

Son actividades muy cortas. Piense en ello como un check-out de hotel efectivo, donde el huésped (participante) abandona el hotel rápidamente, con la sensación de ser escuchado y dando una valiosa retroalimentación al hotel.

A continuación te comparto algunos ejemplos:

¿Qué te pareció?

¿Cómo me voy?

Repeat/Avoid

Ejecutando la actividad:

Pida a los participantes que agreguen sus notas en consecuencia:

* ¿Qué debemos repetir?

* ¿Qué se debe evitar?

Agrupe las notas y discuta.

Esta es una actividad retrospectiva común para la recopilación de datos. Es una alternativa para mantener al equipo comprometido mientras cambia ligeramente el formato.

Referencias:

• https://www.funretrospectives.com/repeat-avoid/
• https://www.funretrospectives.com/category/check-out/

Agile Team: El rol Agile Team Leader o Líder de Equipo Ágil

Hay diferentes autores que proponen o hablan de "Agile Team Leader" como una idea de líder de equipo ágil más amplia que la figura de Scrum Master o roles semejantes que están atados a un framework en particular.

Por ejemplo Henrik Kniberg habla de "Líder de Equipos Ágiles" en el libro "The Agile Team Leader: A Practical Guide to Building High-Performing Teams", como un profesional que asume el rol de liderazgo en un equipo que trabaja bajo enfoques ágiles, como Scrum o Kanban. Este líder tiene la responsabilidad de guiar al equipo hacia la excelencia, promoviendo los valores y principios ágiles, y facilitando un entorno propicio para el alto rendimiento.

El líder de equipos ágiles no es un líder autoritario o jerárquico tradicional, sino alguien que actúa como un facilitador, un mentor y un defensor del equipo. Su objetivo principal es apoyar a los miembros del equipo en su desarrollo individual y colectivo, fomentando la colaboración, la autonomía y la mejora continua.

Este líder tiene la capacidad de influir en el equipo, pero su enfoque no es dar órdenes o imponer su voluntad, sino más bien empoderar a los miembros del equipo para que tomen decisiones y asuman responsabilidad. También se espera que el líder de equipos ágiles sea un ejemplo de los valores ágiles, como la transparencia, la adaptabilidad y el enfoque en el cliente.

En resumen, para Henrik Kniberg, un líder de equipos ágiles es alguien que dirige y guía al equipo de manera colaborativa y facilitadora, fomentando la autogestión, la innovación y la entrega de valor en un entorno ágil.

Por otro lado, la autora Lyssa Adkins habla de liderazgo ágil de equipos en su libro "Agile Team Leadership: A Practical Guide to Empowering Your Team and Achieving Results". Para ella un líder de equipos ágiles es alguien que se encarga de guiar, empoderar y apoyar a los equipos en la adopción y práctica de metodologías ágiles. Este líder se enfoca en fomentar un entorno de trabajo colaborativo, motivador y de alto rendimiento.

El líder de equipos ágiles es aquel que entiende y abraza los principios y valores ágiles, y los utiliza como base para influir positivamente en el equipo. Tiene la capacidad de inspirar y motivar a los miembros del equipo, ayudándolos a desarrollar su autogestión, toma de decisiones y colaboración efectiva.

Este tipo de líder se enfoca en facilitar la comunicación y la transparencia, promoviendo la confianza y la apertura en el equipo. Además, brinda soporte en la resolución de conflictos y en la gestión del cambio, asegurándose de que el equipo esté alineado con los objetivos del proyecto y de la organización.

Un líder de equipos ágiles también es un facilitador, coach y mentor para el equipo. Ayuda a identificar oportunidades de mejora, impulsa la experimentación y el aprendizaje continuo, y busca formas de optimizar el rendimiento y la productividad del equipo.

En resumen, Lyssa Adkins, un líder de equipos ágiles es aquel que se enfoca en liderar y empoderar a los equipos para que trabajen de manera efectiva, colaborativa y ágil, utilizando las prácticas y principios ágiles como guía para lograr resultados sobresalientes.

Líder de Equipo Ágil versus Agile frameworks

Cada marco de trabajo propone un rol que asume el liderazgo ágil de un equipo. El rol más conocido es el de Scrum Master, aunque también tenemos al Service Delivery Manager en Kanban, por ejemplo.

Si queremos abstraernos de la metodología ágil o marco de trabajo en particular, podemos usar el término Agile Team Leader (o Agile Team Lead). Es una buena opción para no inventar nombres nuevos. Ponerle nombre a los roles parece una tarea no trivial en los contextos de adopción ágil. Esta podría ser una opción.

Referencias:

• The Agile Team Leader: A Practical Guide to Building High-Performing Teams by Henrik Kniberg and Mattias Skarin
• Agile Team Leadership: A Practical Guide to Empowering Your Team and Achieving Results by Lyssa Adkins
• Agile Leadership: The Team-Centric Approach to Software Development by Jeff Patterson

Scrum: Las competencias del Srum Master

 ¡Atención, atención! ¿Quién es el Scrum Master? es un maestro de lo ágil que te enseñará cómo dominar el arte de Scrum. Este maestro del caos y la organización es el encargado en un equipo Scrum de establecer las reglas del juego según la Guía de Scrum. Su misión es asegurarse de que todos en el Scrum Team, y hasta la organización entera, entiendan tanto la teoría como la práctica de Scrum.

El Scrum Master es como un entrenador de fútbol que se asegura de que sigan las reglas del fútbol y ganen partidos. Su objetivo principal es hacer que el Scrum Team sea eficiente y efectivo, como una máquina bien engrasada para generar incrementos de producto dentro de un Sprint. ¿Cómo lo logra? Ayudando al equipo a mejorar sus prácticas dentro del marco de trabajo de Scrum. Es un líder de verdad, sirviendo al equipo y a la organización en general. Un auténtico facilitador del trabajo del equipo y del desarrollo de productos.

El Scrum Master tiene varias responsabilidades con el Scrum Team. Imagínalo como un guía de la agilidad que les muestra el camino hacia la autogestión y la multifuncionalidad. Los motiva a enfocarse en crear Increments de alto valor que cumplan con la Definición de Terminado. El ideal es que el equipo genere software funcionando dentro de cada Sprint, pasando por todas las etapas del desarrollo de software, y satisfaga necesidades de los clientes aportándole valor como también a la organización. Además, se encarga de eliminar cualquier obstáculo que se interponga en el camino del equipo. ¡Y eso no es todo! También se asegura de que todos los eventos de Scrum se lleven a cabo sin contratiempos y se mantengan dentro de los límites de tiempo recomendados.

Pero espera, ¡hay más! El Scrum Master también es el fiel servidor del Product Owner. Es como el asistente personal del dueño del producto. Le ayuda a definir objetivos claros y concisos, a gestionar el Product Backlog y a planificar empíricamente en un entorno complejo. ¡Una especie de gurú ágil para el éxito del producto!

Pero no acaba ahí. El Scrum Master también sirve a la organización en su conjunto. Es como el profesor, concientizador y divulgador de la agilidad. Lidera, capacita y guía a la organización en su adopción de Scrum. Planifica e implementa Scrum en todas las esquinas de la empresa. Ayuda a los empleados y a los interesados a comprender y aplicar el enfoque empírico en el trabajo complejo. ¡Es un experto en derribar las barreras entre los interesados y los Scrum Teams!

En resumen, el Scrum Master es el líder ágil maestro de Scrum que le enseña al equipo cómo jugar el juego de este marco de trabajo. Es el pegamento que mantiene unido al equipo, el aceite que hace que las ruedas del equipo y su proceso giren sin problemas y el mecánico para destrabar problemas. Sirve al equipo, al Product Owner y a la organización en general. Es el líder, el entrenador, el guía y el servidor. ¡El Scrum Master es todo eso y más!

La fuente principal de verdad de un Scrum Master es la Guía de Scrum (en Scrum.org).

Las ocho posturas del Scrum Master

Además de las responsabilidades que indica la guía de Scrum, Barry Overeem describe 8 competencias asociadas a este rol en su paper "The 8 Stances of a Scrum Master". Estas competencias se conocen como "Stances" en inglés, que se traduce como posturas o actitudes. Estas 8 posturas o competencias son:

1. Líder Servicial: actúa como líder Servicial, asegurándose de que el equipo Scrum tenga todo lo que necesita para tener éxito y liderando para maximizar sus resultados. El Scrum Master actúa como líder, guiando al equipo Scrum hacia el logro de sus objetivos y motivándolos para alcanzar la excelencia. El Scrum Master actúa como protector, asegurándose de que el equipo Scrum esté protegido de interferencias externas, tenga un ambiente seguro y mantenga foco en sus objetivos.
2. Facilitador: actúa como facilitador, ayudando al equipo Scrum a colaborar y trabajar de manera efectiva, moderando y facilitando los eventos de Scrum y reuniones de trabajo del equipo.
3. Removedor de Impedimentos: es responsable de identificar y eliminar cualquier obstáculo o impedimento que pueda estar afectando el progreso del equipo Scrum hacia el logro de sus objetivos. Un impedimento puede ser cualquier cosa que obstaculice el trabajo del equipo Scrum, como problemas de infraestructura, dificultades en el proceso, conflictos internos, falta de recursos o incluso problemas personales de los miembros del equipo. Es responsabilidad del Scrum Master identificar estos impedimentos y trabajar en estrecha colaboración con el equipo Scrum y otras partes interesadas para eliminarlos. El Scrum Master también es responsable de asegurarse de que los impedimentos no vuelvan a surgir en el futuro.
4. Agente de cambio: El Scrum Master actúa como agente de cambio, impulsando la mejora continua y fomentando la adopción de prácticas ágiles en la organización. Busca lograr la mejora continua del equipo, los procesos y el sistema de trabajo; además de entender las dinámicas organizacionales y participar en la planificación y liderazgo de iniciativas de cambio y transformación para lograr "Equipos estables y multidisciplinarios" que desarrollen productos o resultados de valor con "Calidad y Excelencia técnica".
5. Coach: actúa como coach, guiando al equipo Scrum en el uso efectivo de Scrum y ayudándoles a mejorar continuamente. Ayudar a las personas a identificar sus problemas y a buscar sus propias soluciones con un enfoque en la cultura, mentalidad y el comportamiento.
6. Mentor: actúa como mentor, compartiendo su experiencia y conocimiento en Scrum y en el dominio del producto y profesión. Dedicar, desde su avanzada experiencia, parte de su tiempo a realizar mentoring a profesionales de menor experiencia guiando, inspirando y ayudando en el desarrollo de la carrera profesional como también así recibir mentoreo para desarrollo propio.
7. Gestor (Manager): Gestionar de manera horizontal el proceso, la salud del equipo, los riesgos e impedimentos, y asegurar la mantención de una "integridad conceptual" de la administración del equipo, proyecto, ítems de trabajo, producto, desarrollo y entrega; además de monitorear el progreso, impacto en clientes y el éxito con el resto de los roles.
8. Formador (Teacher): Enseñar, educar, capacitar y guiar sobre Agile, marcos de trabajos, métodos, técnicas, habilidades y también perspectivas.

Lecturas recomendadas

Para ser formador (teacher) debemos nutrir nuestros conocimiento como práctica de mejora continua personal. En esta vía, si quiere aprender más sobre Scrum Master puede leer los siguientes libros:

• Scrum Mastery: From Good to Great Sprint after Sprint by Henrik Kniberg and Mattias Skarin. En este libro, los autores exploran el rol de Scrum Master y cómo llevarlo de bueno a excelente en cada sprint. Ofrece consejos prácticos basados en experiencias reales, junto con estrategias para enfrentar desafíos comunes y maximizar el valor entregado por el equipo Scrum. Es una lectura recomendada para aquellos que desean profundizar en el rol de Scrum Master y mejorar su desempeño.
• The Scrum Master Handbook: A Complete Guide to Scrum Mastering by Gunther Verheyen. Este libro es una guía completa sobre el rol de Scrum Master. Cubre todos los aspectos del Scrum Mastering, desde los fundamentos de Scrum hasta las habilidades de liderazgo, coaching y facilitación necesarias para un desempeño exitoso. Es un recurso valioso para aquellos que desean comprender en profundidad las responsabilidades y competencias clave del Scrum Master.
• Scrum Mastery: From Good to Great Servant Leadership de Geoff Watts: se centra en el desarrollo de habilidades de liderazgo y coaching para Scrum Masters. Proporciona consejos prácticos para ayudar a los Scrum Masters a convertirse en verdaderos líderes de servicio y maximizar el valor que aportan al equipo y a la organización.

También algunos libros en español:

• El Rol del Scrum Master: Líder servicial en Scrum (Scrum Profesional) by Joel Francia Huambachano. Proporciona una visión práctica de las responsabilidades y competencias necesarias para ser un Scrum Master eficaz. A través de ejemplos y consejos, el autor guía a los lectores sobre cómo desempeñar el rol con éxito y fomentar la adopción de Scrum en equipos y organizaciones.
• LLEGAR A SER UN SCRUM MASTER: Más allá de la teoría by Christopher J. Lee. Este libro se enfoca en el desarrollo personal y profesional del Scrum Master. Va más allá de la teoría básica de Scrum y se sumerge en las habilidades y capacidades que un Scrum Master necesita para tener éxito en su rol. El autor ofrece consejos prácticos, ejercicios y reflexiones para ayudar a los Scrum Masters a crecer en su práctica y convertirse en líderes efectivos dentro de los equipos ágiles.
• Scrum Mastery 2nd Ed (Spanish) by Henrik Kniberg and Mattias Skarin.

Referencias relacionadas:

• The 8 Stances of a Scrum Master. Scrum.org, © 2016 All Rights Reserved.
• Guía de Scrum (en Scrum.org)
• ¿Qué es un SCRUM MASTER?
• Posturas del Scrum Master.
• Las 8 Posturas do Scrum Master de Barry Overeem.

• Las 8 posturas del Scrum Master. URL: https://www.youtube.com/watch?v=oGBcRbCo-Ok&ab_channel=TheHouseofRouting

  Keynote: The 8 Stances of a Scrum Master - Barry Overeem CAS 2017. URL: https://www.youtube.com/watch?v=Ht-2-5MCdOA&t=808s&ab_channel=Autentia

• ¿QUÉ HACE un SCRUM MASTER? (Jeronimo): https://www.youtube.com/watch?v=jeVZrMxqSx0

• Cómo MEDIR a un SCRUM MASTER (Jeronimo): https://www.youtube.com/watch?v=cBNZIT3-4f8

• Cómo ser SCRUM MASTER: 6 consejos (Javier Garzás): https://www.youtube.com/watch?v=iyz3IEgG72k

• A funny Scrum Master movie with Jeff Sutherland: https://youtu.be/oheekef7oJk

• DARK Scrum Examples - 77 Antipatrones de Scrum: https://www.youtube.com/watch?v=oX_S65ti4F8

• ¿Qué hace un Scrum Master? Respuesta de Alejandro Posada. URL: https://www.youtube.com/watch?v=XeuOG3DCVwo

• Scrum org, The 8 Stances of a Scrum Master (PDF).

• Scrum.org, Myth 8: The Scrum Master is a Junior Agile Coach.

• Las 8 posturas del Scrum Master. URL: https://mamaqueesscrum.com/2022/01/03/claves-del-scrum-master-que-caracteristicas-tiene-el-rol-de-scrum-master/

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.

 

Scrum: ¿Qué hacer con Story Points del Carry Over?

 

¿Qué hacer con Story Points del Carry Over?

Este post lo escribo debido a que una capacitación que dicté actualmente me preguntaron esto: "¿que hacer con los story points del carry-over?". Cuando un equipo Scrum termina un Sprint y le queda una Historia de Usuario de Carry Over que estaba estimada en X story points y se quemaron solo N story points, quedando un remanente de X-N story points ¿Qué se recomienda hacer? 

Antes de comentar las estrategias recomendadas vamos a revisar algunas afirmaciones teóricas. Teóricamente se puede considerar lo siguiente:

1. El Velocity es una métrica utilizada en el marco de trabajo Scrum para medir la cantidad de trabajo que un equipo puede ‘completar’ durante un Sprint. Se calcula sumando el número total de story points ‘completados’ por el equipo en un Sprint determinado. El trabajo que no cumple con los criterios de aceptación del Product Owner o del cliente no se puede considerar como completo. Según Mike Cohn: "Velocity es la cantidad de trabajo completado por un equipo de desarrollo durante un sprint. Se mide en story points para las historias de usuario completadas. Velocity se utiliza para la planificación del sprint futuro, ya que proporciona una idea de la capacidad del equipo para completar trabajo en un sprint determinado". El velocity refleja trabajo completado, que cumple el Definition of Done, porque es un acercamiento a: “¿Cuánto Valor entregamos por Sprint?” (Jeff Sutherland); y valor es el trabajo completado (esfuerzo aceptado) no el quemado (esfuerzo realizado).

2. La estimación: es importante, teniendo en cuenta que el objetivo es proporcionar una guía para el trabajo a realizar y ser una medida para poder mejorar y no es una medida exacta del esfuerzo requerido. La estimación debe ser lo suficientemente precisa para ayudar al equipo a planificar el trabajo para el Sprint, pero también lo suficientemente flexible para permitir ajustes si es necesario.

3. El Velocity incluye historias terminadas para incluir una historia en el cálculo de Velocity, debe haber cumplido con todos los criterios del Definition of Done y haber sido aceptada por el Product Owner o el cliente.

4. El Velocity no incluye historias no terminadas. Las historias que no fueron aceptadas por no cumplir con los criterios del Definition of Done no deben incluirse en el cálculo de Velocity, incluso si tienen story points realizados.

5. El Carry Over: es una User Story Comprometida y No Aceptada por el Product Owner por no cumplir el Definition of Done.

6. El Carry Over NO es un conjunto de Puntos de una User Story no terminados en el Sprint; los puntos de historia son los que están asociados a una historia Carry Over.

7. Los Story points quemados de la historia no completada no se consideran trabajo completado y no se reflejarán en el incremento del producto entregado al final del Sprint debido a que la historia no cumple el DOD entonces sus Story Points quemados tampoco se consideran terminado. Deben ser considerados como trabajo incompleto en el Sprint actual y no deben incluirse en el cálculo del Velocity.

8. Los Story points quemados de la historia no completada son parte del Capacity del Sprint pero no del Velocity.

9. Historias NO Aceptadas vuelven al Backlog para poder ser evaluadas en una próxima planning. Según Mike Cohn: “Cuando un elemento de la cartera de productos no se termina al final de un sprint ágil, técnicamente debería volver a colocarse en la cartera de productos. El trabajo nunca se mueve automáticamente de un sprint al siguiente”.

10. En la próxima reunión de Planning del equipo, los story points que se quemaron en la historia no aceptada se deben tener en cuenta como un trabajo incompleto en el Sprint anterior y no se deben contar en el Velocity del Sprint actual. Solo se cuenta el remanente o el re-estimado.

11. Los story points remanentes de la historia no aceptada se deben estimar nuevamente en el siguiente Sprint. Sin embargo, si el equipo siente que ya comprende mejor la historia y tiene más información para estimarla con mayor precisión, pueden ajustar la estimación original de la historia y estimar lo que les queda por hacer.

12. En la próxima reunión de Planning del equipo, los story points remanentes de la Historia de Usuario que quedaron sin quemar en el Sprint anterior deben ser incluidos en la estimación del trabajo a realizar para el siguiente Sprint planificado.

13. Hay una distinción entre "velocidad" (puntos de historia de historias completadas según la estimación original) y "capacidad de trabajo" (puntos de historia quemadas según la estimación revisada).

Discho lo anterior, ahora sí veamos las estrategias principales.

Estrategia 1: Registrar puntos quemados y arrastrar remanentes

Siguiendo la teoría, la primera estrategia es registrar los puntos quemados versus los completados. En el siguiente ejemplo podemos ver que en el Sprint 2 se comprometió una historia de estimada en 3 story points, que no fue aceptada. Por eso no se contaron los puntos quemados como velocity, pero como se quemó un story points este sí se contó como capacity. Para el Sprint 3 se incluye la misma historia, pero se comprometen los story points que faltaron quemar.

De este modo se puede ver que los story points quemados de una historia que es carry over se pierden para el velocity, aunque sí se contabilizan para el capacity.

Esta estrategia requiere disciplina del Scrum Master registrando los valores de puntos comprometidos, quemados y completados y hacer los cálculos apropiados. También requiere que el equipo estime cuántos puntos quemaron del total estimado, algo bastante subjetivo y que requiere disciplina.

Estrategia 2: sin puntos quemados y acarrear remanentes

Siguiendo la teoría, tenemos una segunda estrategia: no registrar puntos quemados. La estrategia 2 es que los puntos quemados del total estimado no se registran, en consecuencia no haremos distinción entre velocity y capacity. Solo usaremos el velocity y si una historia es carry over no se cuentan los puntos quemados, se cuenta cero (y se mueve al Backlog para próximo Sprint). Y luego en próximo Sprint se re-estima sólo el trabajo remanente de la historia (se desestiman los puntos del trabajo ya realizado).

Aquí se puede decir que los puntos quemados parecen perderse, porque no se tienen en cuenta para el velocity. Este velocity es un velocity más efectivo que refleja los puntos que el equipo realmente termina independientemente de los que quema. Igual cumple la teoría, solo que la gestión es más simple. 

Bajo ambas estrategias, podríamos querer guardar la “estimación original” (o estimación total) para no perder la información de cuánto realmente pesó la historia, para estimaciones futuras. Ya que las historias carry-over pueden ser re-estimadas en las re-planificaciones.

Estrategia 3: sin puntos quemados y acarrear puntos totales

Tenemos una tercera estrategia: no registrar puntos quemados y acarrear el total de puntos. La estrategia 3 es que los puntos quemados del total estimado no se registran, en consecuencia no haremos distinción entre velocity y capacity. Solo usaremos el velocity; y si una historia es carry-over no se cuentan los puntos quemados, se cuenta cero (y se mueve al Backlog para próximo Sprint). Y luego, en el próximo Sprint se re-estima toda la historia (incluyendo el trabajo hecho) y se considera el puntaje total en el Sprint nuevo. Esto no sigue la teoría, porque no tendremos un velocity real, los puntos entregados, si la historia acarreada de carry over se termina, estarán en este último Sprint y eso no refleja ni el capacity ni el velocity real del Sprint. Aunque si solo prestamos atención, al momento de estimar, al ‘velocity promedio’, tendremos una aproximación al capacity promedio. Es decir que el average velocity es una aproximación de la capacity que podría tener el equipo. Esta estrategia, aunque no respeta la teoría, también es simple de implementar.

Pueden haber otras estrategias, aunque estas tres son las más usadas. Muchas veces recomiendo la estrategia 2, por simplicidad y respetar la teoría; aunque hay personas que sienten que pierden puntos. Y la estrategia 2 es incómoda para un equipo que está muy centrado en el output.

Carry Over en Jira

En Jira, la estrategía por defecto y la más simple es la estrategia 2 y 3: no registrar puntos quemados.

• Generalmente en Jira, en las configuraciones por defecto, se estima en Story Points y “Los issues (Historias de usuario) consumirán su valor de Story Points al finalizar” (al pasar a Done).

• Si una historia de carry over se compromete en el próximo sprint sin modificar los story points y se termina el sprint con la historia aceptada, Jira contabilizará el total de la estimación original.

• Jira, por defecto, no diferencia entre el trabajo realizado en diferentes sprints para una misma historia de usuario. Si la historia de carry over se completa en el siguiente sprint, Jira considerará la estimación total de la historia de usuario para calcular el Velocity del sprint en el Sprint que se ha completado la historia.

• Las Historias Carry Over no suman puntos para el velocity, solo sumarán en el Sprint que se termine (que pase a Done).

• El ‘Sprint Report’ o ‘Informe de Sprint’ le mostrará las historias no completadas en cada Sprint, estas son el Carry Over.

• El Burndown Chart de Story Points decrecerá solo a medida en que las historias vayan completando (Done).

• Depende si usamos la estrategia 2 o la 3, si decidimos descontar puntos quemados y acarrear remanente o acarrear todos los puntos.

• Las historias que fueron Carry Over quedan con su campo Sprint con los Sprint en que estuvieron.

Referencias:

• MEASURING SCRUM: ESSENTIAL METRICS FOR HYPER PRODUCTIVE TEAMS" de los autores Jeff Sutherland y Scott Downey de Scrum Inc.

• Mike Cohn define la Velocity de Scrum en su libro "Agile Estimating and Planning", publicado en 2005.

• "Scrum: A Pocket Guide" de Gunther Verheyen: Este libro es una introducción clara y concisa a Scrum y sus principios. Verheyen explica cómo se utiliza la Velocity en Scrum para medir la capacidad del equipo y cómo el Carry Over puede afectar la planificación del Sprint.