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.

Una típica pregunta es que si pierdo storypoints y afecto al velocity real. La verdad que importa más la velocidad promedio, y lo que no se cuenta en un sprint se cuenta en otro, y se compensan para la velocidad promedio. La velocidad promedio se suele calcular en 3 Sprint o en 6 sprints e indica, más aproximadamente, la capacidad de entregar valor del equipo en un sprint.

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.

Lean Start-Up: El MVP

¿Qué es un MVP?

El MVP ('Minimum Viable Product') es la versión mínima de un producto que permite a un equipo recopilar la máxima cantidad de aprendizaje validado sobre un conjunto de clientes con el menor esfuerzo posible. Es decir que su objetivo es aprender lo máximo posible con el menor esfuerzo y costo, y en función de los resultados obtenidos, pivotar o perseverar en la dirección inicial. 

El MVP puede ser un prototipo, una versión beta o incluso una simple presentación de diapositivas que simula el producto.

El MVP es un producto con suficientes características (Features) para satisfacer a los clientes iniciales (Early Adopter), y proporcionar retroalimentación para el desarrollo futuro. (Ries, Eric (3 de agosto de 2009, «Minimum Viable Product: a guide»).

El MVP no es una parte de un producto o una entrega parcial del producto, es algo que representa a todo el producto aunque no sea el producto final.

El MVP no necesita ser un producto terminado porque no es el producto final. El MVP suele obviar los detalles, el mejor diseño final y hasta puede no ser de buena calidad. Esto sucede porque tampoco se prueba con todo el universo de clientes, solo se prueba con una parte pequeña de usuarios o clientes tempranos para hacer el ajuste entre problema y solución.

La idea principal del MVP es hacer un ajuste entre problema y solución llamado “Problem-Solution Fit“. Es decir, antes de invertir meses o años de esfuerzo en la construcción de un producto, el primer paso es determinar si vale la pena hacer este producto (Ash Maurya, Running Lean). 

Errores típicos al hacer un MVP

Hay varios errores comunes que las empresas cometen al tratar de crear un Minimum Viable Product (MVP). Aquí te menciono algunos de ellos:

• Crear un producto demasiado complejo: Al tratar de ofrecer una solución completa y acabada, las empresas a menudo terminan creando un MVP que es demasiado complejo y costoso de desarrollar. Esto puede hacer que el proceso de retroalimentación sea más difícil y menos útil.
• No enfocarse en las necesidades del cliente: El MVP debe ser diseñado para satisfacer las necesidades del cliente, no las del equipo de desarrollo. Si la empresa no se enfoca en las necesidades reales del cliente, es probable que el MVP no reciba la retroalimentación adecuada.
• No definir claramente la hipótesis que se quiere probar: Si la empresa no tiene una hipótesis clara sobre su modelo de negocio, es probable que el MVP se convierta en un experimento sin dirección clara.
• No medir los resultados correctamente: Es importante definir las métricas clave para medir el éxito del MVP. Si la empresa no tiene un plan claro de medición, es difícil determinar si el MVP fue exitoso o no.
• No estar dispuesto a pivotar: Si los resultados del MVP indican que la hipótesis original estaba equivocada, la empresa debe estar dispuesta a pivotar y cambiar de dirección. Si no lo hace, puede terminar invirtiendo más tiempo y dinero en una solución que no funciona.

En resumen, para crear un MVP exitoso, las empresas deben centrarse en las necesidades del cliente, definir claramente la hipótesis que quieren probar, medir los resultados correctamente y estar dispuestas a pivotar si es necesario.

¿Es solo un MVP?

Generalmente se acepta que para desarrollar un producto con Lean Start-up se realiza solo un MVP y el resto de entregas ya es la evolución incremental del producto. Sin embargo, no es necesario construir solo un Minimum Viable Product (MVP). De hecho, en algunos casos, puede ser necesario construir varios MVPs para obtener suficiente retroalimentación del mercado y refinar la idea del negocio.

En la metodología Lean Start-up, el desarrollo de un producto es un proceso iterativo que implica, de ser necesario, la construcción de múltiples MVPs. Cada MVP se utiliza para validar una hipótesis clave sobre el negocio, y la retroalimentación obtenida de cada MVP se utiliza para mejorar la idea del negocio y guiar el desarrollo del siguiente MVP.

La construcción de varios MVPs también ayuda a los emprendedores a reducir el riesgo y el costo de desarrollar un producto completo antes de recibir retroalimentación del mercado. En lugar de invertir todo el tiempo y el dinero en un producto que puede no ser exitoso, la metodología Lean Start-up promueve un enfoque de prueba y error más rápido y económico.

De hecho, hay autores como Caroli que promueven la construcción de varios MVP.

En resumen, la construcción de varios MVPs es una parte integral del proceso de desarrollo de un producto con la metodología Lean Start-up. Cada MVP se utiliza para validar una hipótesis clave sobre el negocio y la retroalimentación obtenida se utiliza para guiar el desarrollo del siguiente MVP. Una vez que se loogra el ajuste entre problema y solución, generalmente, ya se desarrolla el producto de manera evolitiva e incremental donde también se pivotea y persevera hasta que el producto alcanza una madurez suficiente.

¿Cuándo hacemos el MVP en nuestro flujo de desarrollo de productos?

En un flujo de trabajo típico, el Minimum Viable Product (MVP) se ubicaría en una etapa temprana del proceso de desarrollo de un producto o negocio. 

El proceso típico de desarrollo de un producto en la metodología Lean Start-up comienza con la identificación de una necesidad o problema del cliente, seguido de la formulación de una hipótesis sobre cómo se puede resolver este problema y generar valor para el cliente. El siguiente paso es la construcción del MVP para validar esta hipótesis con la menor cantidad de recursos posibles. Y el proceso se repite.

En framework como SAFe, primero hay una etapa de inicio de una oportunidad entrando a un embudo de portafolio (funnel), luego una ideación definiendo la iniciativa de producto y creando una hipótesis en un portfolio EPIC (Reviewing), luego se define y se analiza un MVP (analyzing) para pasar al backlog de portafolio (portfolio backlog), recién allí se comienza la construcción del MVP (MVP Implementing), se pivotea o persevera, y si se persevera se sigue construyendo el producto de manera incremental (Implementing Persevere) y evolutiva, hasta que merece salir del portafolio (Done). 

En general una menera en que me gusta verlo es como muestra el siguiente flujo de desarrollo de producto:

¡Saludos y buena vida!

Referencias:

• ¿Qué es el método Lean Startup? Definición, pasos y ejemplos.
• "The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses", Eric Ries.
• Caroli.org: MVP examples.

Retrospective: Retro SICA (Situación-Impacto-Causas-Acciones)

Técnica SICA para retrospectiva

¿Quieres hacer una retrospectiva más orientada a resolver problemas concretos y generar opciones de mejoras? ¿Te has encontrado alguna vez frente a un problema complejo que no sabes como comenzar a resolver? ¿Te gustaría tener una forma más efectiva de abordar los problemas y encontrar soluciones viables o la causa raíz? Si es así, te recomendamos probar la técnica SICA (Situación-Impacto-Causas-Acciones).

La retro SICA que propongo es una técnica utilizada en la investigación y el análisis de datos para comprender un problema y llegar a una solución. Esta técnica se utiliza comúnmente en la resolución de problemas y en el análisis de casos.

Idealmente la retrospectiva iniciará con los acuerdos, alguna dinámica rompe hielo y revisión de métricas y experimentos pasados para pasar a una dinámica central de resolución de problemas, que a continuación detallo los pasos, para finalmente cerrar con algún feedback, reconocimientos y cierre de la reunión.

A continuación se detalla cada paso de la técnica SICA en la dinámica central de resolución de problemas:

1. Situación: En este paso, de hallazgo, se describe la "situación problema" actual y se define el problema. Se deben identificar los hechos relevantes y se debe describir la situación de forma clara y concisa.
2. Impacto: ¿El problema qué impacto genera? se describen los impactos negativos del problema o las consecuencias negativas que genera la situación.
3. Causas: En este paso, se identifican las complicaciones o factores causales que están contribuyendo al problema y de las causas detectadas se busca la causa raíz. Se consideran los factores internos y externos que están afectando la situación. Se pueden usar diferentes técnicas como los "5 por qué" (Diagrama de Pez Ishikawa, causal loop, etc.).
4. Acciones: En este paso, se buscan "acciones de mejora", "acciones de solución" o iniciativas de mejora en función de las causas. Se deben considerar las posibles acciones/soluciones y se deben evaluar sus ventajas y desventajas. Se debe seleccionar la mejor solución y se deben identificar los pasos necesarios para implementarla. En este paso, se pueden formular preguntas para comprender mejor el problema y las complicaciones identificadas. Las preguntas deben ser específicas y orientadas a la resolución del problema como; ¿Qué se puede hacer para (mejorar, reducir, aumentar, eliminar, mitigar, etc) ...? También se pueden redactar hipótesis de solución: "Creemos que si hacemos A resultará en B".

Al seguir estos cuatro pasos, como parte central de la retrospectiva, se puede comprender mejor una situación y llegar a una solución efectiva. La técnica se enfoca en la identificación del problema, la identificación de los factores que contribuyen al problema, la formulación de preguntas específicas y la búsqueda de soluciones efectivas. De estas soluciones vamos a legir cuál es la más efectiva para priorizar y ejectutar posteriormente de la retrospectiva como experimento de mejora.

EJEMPLO 1: Plomería de mi hogar

1. Paso 1: Situación. En una casa, se ha detectado una filtración de agua en la tubería de la cocina, causando una acumulación de humedad en el suelo y la aparición de manchas de humedad en la pared cercana.
2. Paso 2: Impacto. La filtración de agua está dañando la estructura de la casa, causando posibles problemas de moho y deterioro de la pintura en la pared. Además, el desperdicio de agua debido a la fuga podría aumentar los costos de la factura de agua.
3. Paso 3: Causas. Las causas identificadas de la filtración de agua incluyen una junta defectuosa o desgastada en la tubería de la cocina y una posible obstrucción en la tubería.
4. Paso 4: Acciones. Para abordar el problema, se proponen las siguientes acciones:

• Inspeccionar y reparar la junta defectuosa o desgastada en la tubería de la cocina para detener la filtración de agua.
• Realizar una limpieza y desobstrucción de la tubería para asegurar un flujo adecuado del agua y prevenir futuras filtraciones.

EJEMPLO 2: Daily Scrum con problemas

• Situación problema: El equipo de desarrollo de software comenzó a utilizar el marco de trabajo Scrum para desarrollar un producto. Sin embargo, la Daily Scrum, una reunión diaria de 15 minutos para que el equipo sincronice sus actividades, está durando más tiempo del recomendado. A veces llega a durar más de 40 minutos.
• Impacto: El equipo ve a la daily como poco productiva, se pierde tiempo y el equipo no está coordinado.
• Causas: Se han identificado varias complicaciones que pueden estar contribuyendo a que la Daily Scrum dure más de 15 minutos, como: 
• la falta de estructura en la reunión, 
• la discusión de temas irrelevantes, 
• la falta de control del tiempo a la hora de hablar,
• la falta de un moderador/facilitador,
• el uso del espacio para intentar resolver los problemas que se presentan.
• Acciones de mejora: ¿Qué se puede hacer para respetar el timebox de la Daily Scrum y hacer que la reunión sea más efectiva? La opciones de mejora pueden ser:
• establecer una estructura clara para la reunión, como hacer que cada miembro del equipo hable solo sobre lo que hizo ayer, lo que hará hoy y si hay algún obstáculo en su camino que frena el objetivo del Sprint. 
• designar a un facilitador (el Scrum Master) para la reunión que tenga la tarea de mantener el foco en los temas relevantes y asegurarse de que todos los miembros del equipo tengan la oportunidad de hablar en la reunión.
• el facilitador podría recordar al equipo la importancia de respetar el tiempo de los demás miembros del equipo y mantenerse dentro de los límites de tiempo de 15 minutos. 
• el equipo podría revisar la lista de temas a discutir antes de la reunión para asegurarse de que los temas irrelevantes no se aborden en la reunión diaria. 

EJEMPLO 3: Caidas de un sitio web

1. Paso 1: Situación. El sitio web de una empresa de comercio electrónico ha estado experimentando tiempo de inactividad frecuente y bajo rendimiento en las últimas semanas.
2. Paso 2: Impacto. Esto ha llevado a la pérdida de clientes, ingresos y la insatisfacción general de los usuarios.
3. Paso 3: Causas. Las causas identificadas incluyen implementaciones no controladas, monitoreo insuficiente, capacidad inadecuada de la infraestructura y falta de dueños de la infraestructura. Actualmente la causa raíz es la falta de un equipo experimentado y experto que facilite DevOps.
4. Paso 4: Acciones. Para abordar los problemas, se propone lo siguiente:
• Establecer despliegues automatizados y controlados para garantizar cambios estables en el sitio web.
• Implementar un sistema de monitoreo proactivo para detectar problemas antes de que afecten a los usuarios.
• Escalar horizontalmente la infraestructura para manejar picos de tráfico.
• Mejorar la colaboración y comunicación entre los equipos de desarrollo y operaciones.
• Se armrá un equipo SRE que se encargará de implementar estas acciones y medirá su efectividad para mejorar la confiabilidad y el rendimiento del sitio web.

Esta retro SICA está basada en la técnica SCQA (Situation, Complication, Question, Answer) y puede ser usada para cualquier reunión de resolución de problemas o mejora continua.

Saludos, espero te sea útil esta estructura de retrospectiva.

Retrospective: Retrospectiva Doble Diamante

Retrospectiva Doble Diamante

En este nuevo post del blog vamos a hablar sobre el modelo del doble diamante para aplicarlo como estructura de retrospectivas. Se trata de un modelo que permite desarrollar y proponer soluciones a problemas a menudo complejos.

El modelo del doble diamante es un marco de diseño ideado por el Consejo Británico en 2005, posteriormente actualizado en 2015. Esta herramienta aporta una metodología aplicable tanto por diseñadores como no diseñadores y nos servirá para estructurar nuestras retrospectivas. Su objetivo es procesar la información obtenida en el pasado y en el equipo para encontrar soluciones a problemas complejos, generando así mejoras o acciones de mejora.

La estructura de la Retrospectiva doble diamante es la siguiente: 

1. INICIAR: Inicio y preparación.
• Introducción.
• Acuerdos de reunión de trabajo. 
• Dinámica rompe-hielo. 
2. INVESTIGAR POBLEMA:
• Recordar el pasado: recabar datos y acciones pasadas y en curso. Revisar y actualizar el Kaizen Board.
• Brainstorming. generación de dolores y/o problemas en un tablero: problemas, problemas seleccionados, ideas, ideas seleccionadas. Para disparar problemas puede usar preguntas como las siguientes: ¿Que nos impide "satisfacer al cliente mediante la entrega temprana y continua de software (funcionando) con valor... frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible... en torno a individuos motivados, desarrollo sostenible y excelencia técnica"? ¿Qué impide alcanzar nuestros objetivos? ¿Qué impide que seamos eficases y eficientes? ¿Qué problemas u oportunidades de mejora vimos en nuestro trabajo?
• Reflexión: generar entendimiento profundo y análisis de problemas.
• Selección de problemas a resolver. 
3. IDEAR SOLUCIÓN: Decidir qué hacer mediante síntesis y actualización o generación de acciones de mejora, responsables y plan general.
• Generar ideas: ¿qué podemos hacer para resolver el problema o avanzar en su solución?
• Converger y seleccionar ideas.
4. CERRAR: Cerrar la reunión.
• Agradecimientos si es necesario (Kudos),
• Feedback de la sesión.
• guardar información.
• cierre.

Al finalizar la retrospectiva no es necesario tener exactamente la solución, con tener ideas de solución y una planificación inicial con responsable se puede trabajar en la solución en otras sesiones de resolución de problemas fuera de la retrospectiva. Hay que considerar al proceso doble diamante como iterativo.

A continuación otra gráfica del modelo.

Al final, las idesa generadas y seleccionadas serán ingresadas a un Kaizen Board. Un Kaizen board bien simple es el típico tablero kanban de tres columnas: 'todo, in progress, done'. También puede usar un tablero que refleje el ciclo 'plan-do-check-act'.

O se puede crear un tablero según las necesidades o creatividad propia. El siguiente es bien simple:

En las tarjetas de mejora se puede cargar la siguiente información:

• Problema: <descripción del problema que mitiga, resuelve o avanza en resolver>
• Accionable de Mejora: <accionable de mejora o solución del problema>
• Cómo: <¿Cómo se resolvera o se hará?>
• Cuándo: <tiempo>
• Responsable: <persona que hara seguimiento o guardián del accionable mejora>

Si usa Planner o tableros físicos puedes usar tarjetas como la indicada. En caso de usar Jira (RTC, etc.) puedes menejar issues de tipo 'Problem' y otros de 'Action Item' y relacionarlos. O directamente manejar items de tipo Problem (o Mejora) y como sub-task sumar los accionables. Esto lo sigiero porque muchas veces sucede que con los accionables se puede perder de vista el problema en sí y avanzar en accionables superfluos o intrascendentes y no se resuelven los problemas de raíz o problemas reales que el equipo y la organización tienen. Lo importante no es solo generar mejoras y aprendizajes, sino el resolver problemas reales que impiden que un equipo sea ágil y que maximice la entrega de valor de manera eficaz y eficiente. Un antipatrón de las retrospectivas es que no generen mejoras o que no resuelvan ningún problema.

Con esta estructura se invita a centrarse en buscar resolver problemas verdaderamente importantes generando soluciones ostensibles. En buen Scrum Master o un Facilitador de Equipos Ágiles debe ser un buen facilitador de resolución de problemas que impiden la promesa Agile: 

"satisfacer al cliente

mediante la entrega temprana y continua de software (funcionando) con valor...frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible... en torno a individuos motivados, desarrollo sostenible y excelencia técnica".

Esta estructura se puede aplicar con las dinámicas que quieras. A continuación te comparto algunas dinámicas de Retrospectivas:

1. Retrospectiva: Acuerdo de reunión de equipo.

2. Retro Team Mood - Estado de ánimo del equipo.

3. Retro Team Morale.

4. RETRO básica de tres columnas.

5. RETRO básica variante de 3 columnas.

6. Retro del Barco.

7. La estrella de mar.

8. RETRO Stop-Start.

9. Retro de las 3 casa.

10. Retro SWOT & RICE.

11. Retrospectiva sobre valores ágiles.

12. Retro por temas de mejora.

13. Medir el Cognitive Loadometer al inicio de una Retro.

14. RETRO Tuckman Reloaded.

15. RETRO de la Isla.

16. Retro Técnica.

17. Lean Development Software Canvas.

18. Futurespectiva: Lienzo de Situación Problema.

19. Retro Roles.

20. Root Cause Analysis.

21. Ishikawa Fishbone Diagram.

22. Retro 1-2-4-ALL.

23. Impacto vs. capacidad.

24. RETRO-URNA.

25. Retro PCPS.

Espero te sirva. Saludos.

Referencias:

• ChE Problem Solving: The Double Diamond Approach.
• http://intranet.procolombia.co/sites/default/files/enlaces/files/doble_diamante_2da_edicion_boletin_1.pdf
• Fase retrospectiva doble-diamante.
• Cómo usar el modelo del doble diamante para impulsar innovación en diseño.

Libro: El Mítico Hombre-Mes

El autor Frederick Brooks en su libro "The Mythical Man-Month" (1975), aborda muchos de los problemas comunes en el desarrollo de software y en los ámbitos de trabajo relacionados con él. Brooks identifica varias falacias que suelen existir en estos entornos, que son:

Falacia del optimismo de creer que todo irá bien: “todo irá bien, es decir, que cada tarea tomará solo el tiempo que ‘debería’ tomar” según lo planificado y se suele planificar considerando que todo irá bien, que lo que se pensó que se debería hacer es lo que realmente se hace, que se estimó lo correcto, que la gente estima bien, no se enferma ni se muere ni que existen las crisis económicas. Brooks argumenta que los desarrolladores y gerentes de proyectos tienden a ser optimistas por naturaleza y tienden a subestimar la cantidad de tiempo y recursos que se necesitan para completar una tarea de software. Esto a menudo lleva a que se establezcan plazos poco realistas y se ignoren los posibles retrasos y problemas técnicos que pueden surgir durante el desarrollo.

Promesas condescendientes: Creer que las estimaciones derivadas de deseos son cumplibles es una falacia. Los cronogramas falsos para coincidir con la fecha deseada del cliente es mucho más común en nuestra disciplina que en cualquier otra parte de la ingeniería.

Falacia de la programación: La idea de que la programación es la principal tarea en el desarrollo de software y que todo lo demás es secundario. Esto lleva a la falsa idea de que “La productividad se mide en horas de programación”. No se puede estimar el esfuerzo total de un proyecto estimando el tiempo de codificación y extrapolándolo a las demás tareas. Tampoco sirve extrapolar la construcción de pequeños sistemas a proyectos de sistemas más complejos. El incremento en el esfuerzo es una potencia del tamaño del proyecto. Tampoco se puede medir la productividad en horas de programación. Hay estudios que dicen que los programadores sólo dedican el 50% de su tiempo a la programación y el resto a otras tareas. Cuando se asigna ese otro 50% a programar más código se termina generando carry-over por sobrecarga y se hace más ineficiente el trabajo del equipo.

Falacia del hombre-mes: La creencia de que se puede acelerar el desarrollo de un proyecto de software simplemente agregando más programadores al equipo. Esta falacia está relacionada a “Medir recursos humanos en función de hora y personas”, el hombre mes. Como si el progreso variara, igual que el costo, como el producto del número de hombres y el número de meses, considerando que las personas y los meses son intercambiables. Como si se pudiera tener un parto en un mes asignando nueve mujeres como recursos humanos. 

Falacia de la panacea: La creencia de que existe una única solución perfecta para cualquier problema de software, y que es posible encontrarla con suficiente tiempo y esfuerzo.

Falacia del segundo sistema: La creencia de que, tras completar un primer sistema, el desarrollo del segundo sistema será más fácil y rápido, porque se tiene más experiencia.

Falacia de la depuración: La creencia de que la depuración de software es un proceso sistemático y predecible que se puede planificar y ejecutar con facilidad.

Promediar la productividad individual: Se suele creer que los desarrolladores pueden rendir individualmente con poca variabilidad. Sin embargo, los rendimientos son muy dispares,10:1 en mediciones de productividad y un increíble 5:1 en velocidad.

Los equipos grandes son productivos: La falacia de “con más personas se produce más”. Sin embargo en informática no es realmente así o por lo menos no para todo proyecto. Lo ideal del pequeño equipo fuerte, por común el consenso no debería exceder las 10 personas. Por eficiencia e “integridad conceptual”, uno prefiere unas pocas mentes buenas haciendo diseño y construcción.

El testing no es importante: Hay un pensamiento recurrente en el desarrollo de software: ”sabemos que la calidad es importante, pero cuesta tiempo y dinero —demasiado tiempo y dinero— lograr el nivel de calidad en el software que en realidad queremos”. Por lo general se subestima el testing estimando y dedicando poco esfuerzo y que a la larga trae costos por mala calidad, deuda técnica, poca mantenibilidad e impacto negativo en el negocio. De todos modos hacer testing es costoso y se piensa que no hacerlo reduce costos. Pues, merece la pena construir código de apoyo para la depuración, que puede llegar a ser el 50% del código a depurar, es costoso. Pero no hacer testing es más costoso.

Brooks argumenta que estas falacias son peligrosas y que los gerentes de proyectos y los desarrolladores de software deben ser conscientes de ellas para evitar cometer errores costosos y perjudicar el éxito del proyecto o la organización.

Este artículo es una interpretación realizada en mi lectura, por lo que recomiendo leer el libro y sacar sus propias conclusiones.

Referencias:

https://www.gestionenti.com/post/el-adi%C3%B3s-a-un-grande-se-nos-fue-frederick-p-brooks

http://tratandodeentenderlo.blogspot.com/2011/03/mythical-man-month.html