Durante el evento de Inspect & Adapt hay una parte reservada a la retrospectiva y al workshop Problem-Solving.
Este Workshop se inicia tras hacer aflorar los problemas sistémicos o más importantes del tren, para lo cual podemos utilizar la dinámica que creamos más adecuada.
Con él encontraremos dónde están nuestros mayores problemas y qué acción podremos realizar para intentar resolverlo, acción que puede trasladarse al backlog de LACE para su seguimiento.
¿Qué personas participan en este Workshop?
Pueden estar tanto en la retrospectiva como en el Workshop todos los miembros del tren, incluyendo además a los Business Onwers, Clientes y Managers. Cierto es que esto hay veces que es complicado y lo que se puede realizar es contar con representantes de los diferentes roles y equipos al disponer de visiones diferentes.
Para favorecer la localización de soluciones se recomienda, con la ayuda del facilitador, crear grupos de trabajo que no coincidan con los equipos del tren, para cada problema a tratar de manera que se junte a personas afectadas con personas motivadas.
¿Quién lo facilita y cuánto dura?
Normalmente lo facilita el RTE pudiendo ser ayudado por un SPC en los primeros Workshops. La duración será la que necesitemos para encontrar las causas raíces y las mejores soluciones a la problemática que tengamos. Hay veces que esta sesión se puede extender hasta 4 horas.
Durante la retrospectiva se obtiene el conjunto de problemas que se ha decidido resolver. Es recomendable que no haya más problemas que grupos dado que cada equipo deberá trabajar sobre uno de ellos.
Se utiliza el Diagrama Causa-Efecto o Diagrama de Pez donde en la cabeza se pone el problema a resolver. Después, por cada una de las categorías de Personas, Procesos, Herramientas, Programa y Entorno (u otras si se estiman más oportunas), se deben poner las posibles causas.
Para identificar las causas raíz hemos de registrar en cada una de las categorías posibles causas que originen el problema tratado. Apuntaremos las causas encontradas en la espina del pez que corresponda y después preguntaremos “¿porqué pasa esa situación identificada?” hasta 5 veces por cada una.
¿Y para qué preguntamos tantas veces porqué?
Muchas veces el origen de un problema no está donde inicialmente creemos. Hay un ejemplo que solemos poner en los cursos muy ilustrativo. La piedra con la que está hecho el monumento del presidente de Estados Unidos Thomas Jefferson se deterioraba muy rápido y repararla es muy costoso. Por ello, el responsable de ese trabajo decide parar y buscar la causa raíz. El primer motivo aparente que detectan es que utilizan pulverizadores muy potentes para limpiar la piedra cada 2 semanas por los excrementos de un alto número de aves que hay en la zona. Para solucionarlo, los operarios colocaron una red que los pájaros aprendieron a rodear. Por lo tanto, recurrieron a los 5 porqués:
Si, como en este caso, se encuentra la causa raíz del problema antes de llegar a los 5 porqués podemos parar.
La solución fue reducir el tiempo de iluminación del monumento y los insectos se redujeron en un 90% teniendo como consecuencia final tener que limpiar menos veces el monumento y por tanto ejercer un menor desgaste de la piedra.
Como habéis visto en el ejemplo, la solución final está muy poco relacionada con el problema aparente inicial ya que otra opción podría haber sido cambiar de pulverizadores con el coste que hubiera supuesto y, sin embargo, el problema no se hubiera resuelto. Por tanto, esta técnica nos puede descubrir que el origen está lejos de donde se produce el problema.
Volviendo a la dinámica del Diagrama Causa-Efecto, una vez tengamos identificada la causa raíz en cada una de las categorías elegiremos cuál es la que más contribuye al problema planteado. Para esta selección se puede utilizar la técnica que más nos guste, pero una técnica sencilla y rápida es la votación acumulada donde cada miembro dispone de 5 votos que puede distribuir como quiera.
Tras seleccionar la causa raíz que más contribuye a generar el problema propuesto haremos un Brainstorming para buscar posibles soluciones que después podremos combinar, refinar, etc. hasta obtener la o las acciones que incluiremos en el Program Backlog.
Recordad que esta es sólo una propuesta para buscar soluciones y acciones que mejoren y engranen todas las piezas que hagan funcionar el tren como un reloj suizo. Y, por tanto, si en vuestro contexto es necesario o interesante hacer alguna variante o crear una dinámica nueva probadlo y aprended.
Los cursos recomendados para saber son: