jueves, 30 de marzo de 2023

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.








lunes, 13 de marzo de 2023

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:









jueves, 2 de marzo de 2023

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