Introducción a la resolución de problemas con Scrum

Introducción a la resolución de problemas con Scrum

Scrum y las metodologías ágiles apuestan de forma clara por la mejora continua. En el camino hacia la agilidad se necesita eliminarlos impedimentos que nos vamos encontrando. Conseguir crear flujos de trabajo dinámicos nos sirve para una mejor transmisión de la información. La mejora continua es indispensable para el buen funcionamiento de un equipo o de una organización.

El aprendizaje colectivo dentro de la organización se impulsa mediante la resolución continua de problemas. Cuando se utiliza la metodología Scrum, el Scrum Máster es la persona encargada de facilitarla. El Scrum Máster también se denomina agente del cambio por este motivo. Entre sus responsabilidades destacan el facilitar la eliminación de los impedimentos y crear las dinámicas necesarias en las reuniones retrospectivas. Necesitamos sacar a la luz los problemas del equipo.

Sólo cuando un problema se hace visible podemos empezar a trabajar para solucionarlo.

Para poder tomar decisiones correctas debemos tener visibilidad del día a día. Cualquier equipo tiene la obligación de analizar los problemas y proponer soluciones. Para analizar un problema no podemos hacerlo de forma superficial, sino que debemos encontrar el verdadero origen, la raíz del problema. Para ello es indispensable:

  • Contar con el feedback de quien se encuentra con los impedimentos en el terreno de juego.
  • Conocer en primera persona el trabajo que se realiza.

La reunión retrospectiva es la dinámica que propone Scrum para potenciar la mejora continua dentro del equipo. En algunos casos empezar a crear esta dinámica puede ser complicado. Descubre como crear una dinámica para la mejora continua con reuniones retrospectivas muy productivas.

Los 5 "por qués" para encontrar la raíz del problema

Sakashi Toyoda, fundador de Toyota Industries y miembro del Sistema de Producción de Toyota (Toyota Production System, TPS), desarrolló el concepto de los 5 "por qués". Se trata de una técnica que consiste en preguntar 5 veces el "por qué" de un problema en el momento en que aparece. De esta forma se consigue llegar a su origen y se puede plantear una solución que impida que vuelva a ocurrir.

Se trata de una técnica de preguntas iterativas. Cada respuesta a la pregunta anterior forma parte de la pregunta siguiente. El número 5 se estima como el número de iteraciones que típicamente se requieren para conseguir conocer la raíz del problema.

No todos los problemas cuentan con un sólo origen. Es lógico que cuando apliquemos la técnica de los 5 "por qués" estemos en este caso. Para descubrir todas las causas que generan un problema necesitamos iterar entre todas las respuestas que se puedan dar a una pregunta. Y así sucesivamente. Imaginemos gráficamente la secuencia de preguntas y respuestas, si iteramos sobre una única respuesta estamos dibujando una línea, mientras que si iteramos sobre distintas respuestas hacemos un árbol.

En la técnica de los 5 "por qués" no se impone cuantas líneas deben ser exploradas. Estamos ante un método que, aunque se aplique de forma muy cuidadosa, sus resultados siempre dependen del conocimiento, la persistencia y la motivación de las personas involucradas. Si quieres saber cómo motivar a tu equipo puedes leer este post acerca la motivación de equipos en Toyota o este otro sobre cómo motivar a un equipo gracias a la metodología Scrum.

Un ejemplo clásico de los 5 porqués es el siguiente:

  • El vehículo no arranca.
  • ¿Por qué? La batería está muerta.
  • ¿Por qué? El alternador no está funcionando.
  • ¿Por qué? la correa del alternador se ha roto.
  • ¿Por qué? La correa del alternador fue mucho más allá de su vida de servicio útil y no se sustituye.
  • ¿Por qué? El vehículo no se mantiene de acuerdo al recomendado programa de servicio.

Este método está pensando para ser usado por equipos expertos. Es una herramienta muy poderosa para encontrar las causas reales de los problemas. Aún así esta técnica cuenta con algunas limitaciones que debemos tener presente en su uso:

  • Tendencia inevitable de detenerse en algún síntoma sin llegar al nivel más bajo del origen.
  • Incapacidad de ir más allá de los conocimientos actuales.
  • Dificultad en preguntarse el correcto "por qué".
  • Resultados no repetibles, distintas personas llegarán a respuestas distintas.
  • Intento de aislar una sola raíz a problemas con múltiples causas.

En la metodología Scrum se apuesta por una dinámica de reuniones con objetivos muy concretos para maximizar la productividad del equipo. Si quieres conocer cómo hacer reuniones más productivas gracias a Scrum puedes leer este post. La técnica de los 5 "por qués" nos puede ser muy útil en la reunión retrospectiva, dónde debemos seleccionar un problema a solucionar en la siguiente iteración.

Impedimentos clásicos en Scrum

Los impedimentos son inherentes al desarrollo de cualquier producto o implementación de un proyecto. Los impedimentos irán apareciendo y será la obligación del equipo eliminarlos y superarlos con éxito. Un impedimento puede ser provocado por una mala dirección, definición o planificación del proyecto. Así mismo también existen impedimentos que son imponderables, pueden suceder en cualquier momento. El equipo tiene la responsabilidad de estar atento en su trabajo y detectar cuanto antes cualquier impedimento que se pueda encontrar. 

Aquí no se buscan culpables, se buscan soluciones.

Algunos de los impedimentos típicos que cualquier equipo se puede encontrar son:

  • Reuniones continuas o muy largas
  • Enfermedad de un miembro del equipo
  • Actualización de hardware o software
  • Dependencias de otros equipos
  • Backlog poco concreto o no priorizado
  • Builds que fallan
  • Proveedores poco confiables

No todos los problemas son causados por terceros. El equipo también puede estar generándose impedimentos de una forma involuntaria. Por ejemplo cuando nos encontramos ante una mala implantación de la metodología Scrum generaremos algunos impedimentos que deberemos afrontar. Algunas veces nos encontraremos ante problemas arraigados en la cultura del equipo, superar estos problemas endémicos se convertirá en una de las grandes bazas para la implantación de la metodología.

Podemos destacar estos impedimentos debidos a una pobre implantación de Scrum:

  • Cambiar con frecuencia los equipos de trabajo
  • Sobreestimar la cantidad de puntos a hacer en cada sprint
  • Tener demasiado trabajo en la columna del DOING.
  • Inadecuada previsión del tiempo destinado a interrupciones
  • Desconocer la motivación de una historia de usuario

Si detectamos un impedimento el Scrum Máster debe facilitar que se afronte de inmediato. Cuanto más tardemos en tratar este impedimento más fácil será que se convierta en un problema. El Scrum Máster es la persona encargada de dar luz a los impedimentos y a ayudar a generar un flujo de trabajo ágil. Lee este post para entender como el Scrum Máster actúa de agente del cambio.

Resolución continua de los problemas

La resolución continua de los problemas impulsa el aprendizaje organizativo. Es indispensable identificar sus causas y evitar que vuelvan a pasar. Recuerdas lo de que "el hombre es el único animal que tropieza dos veces en una misma piedra?".

Analizar - Reflexionar - Comunicar

Ésta es la apuesta de Toyota. Bajo esta secuencia de acciones se considera la mejora continua. Cuando se encuentra una solución a un problema y se da por valida, es necesario entrar en un proceso de estandarización sobre esa solución. Con un estándard documentado conseguimos que el conocimiento fluya por toda la organización. Se trata de garantizar que este problema no vuelva a ocurrir.

El Sistema de Producción de Toyota está formado por 14 principios. Puedes leer este post resumen del Modelo Toyota para entender como pueden ayudarte sus principios en la mejora continua usando la metodología Scrum. Los tres últimos principios hacen referencia a la resolución de problemas. A continuación veremos una breve introducción de cada uno de estos tres principios para entender cómo nos puede ayudar la cultura de Toyota en nuestro trabajo en equipo.

Principio 12: Vaya a verlo por sí mismo para comprender a fondo la situación (genchi genbutsu)

Cuando nos encontramos delante de un problema es importante pensar y hablar en base a unos datos e informaciones verificadas, comprovadas y contrastadas. Para ello es importante ir al lugar de los hechos y comfirmar la información por uno mismo. Debemos sacar ventaja de la sabiduría y experiencia de otros para enviar, recoger o debatir la información. Para aprofundizar en este principio puedes leer este post acerca genchi genbutsu.

Ir y comfirmar los hechos por uno mismo es tan importante como responsabilizarse de la infromación que se da a otros.

Principio 13: Tome decisiones por consenso lentamente, considerando concienzudamente todas las opciones, impleméntelas rápidamente

Este principio se puede explicar con una comparación. Todos sabemos que las comparaciones son odiosas, pero nos puede servir para entender que significa tomar decisiones lentamente e implementarlar muy rápido.

Si suponemos un proyecto tipo de un año, la mayoría de las empresas americanas o europeas tardarán unos tres meses en la planificación. A continuación empezará su implementación. A partir de este momento se irán encontrando problemas y dedicarán el resto del año a desarrollar el proyecto y a solucionar los problemas que vayan saliendo.

Ante el mismo proyecto, Toyota invertirá de nueve a diez meses en la planificación. A continuación implementará la solución a pequeña escala, como si de un piloto se tratara. Antes de final de año estará totalmente implementado y prácticamente sin ningún problema pendiente.

Con esta introducción puede parecer que este principio puede chocar con algunos principios ágiles. Puedes leer este post para entender la paradoja entre el principio 13 del método Toyota y las metodologías ágiles.

Principio 14: Conviértase en una organización que aprenda mediante la reflexión constante (hansei) y la mejora continua (kaizen)

Uno de los mejores cumplidos que podríamos realizar a una empresa de hoy en día  es que sea una verdadera organización que aprende. Una organización que aprende es una organización que aprende a aprender. No se trata sólo de adoptar y desarrollar nuevos negocios, habilidades o técnicas. Una organización que aprende implanta un segundo nivel de aprendizaje para aprender nuevas habilidades, conocimientos o capacidades.

A palabras de Peter Senge, en su libro "La quinta disciplina" (1990), define a una organización que aprende como un lugar:

"... donde las personas amplían contínuamente su capacidad para crear los resultados que de verdad quieren, donde se alimentan patrones de pensamiento nuevos y expansivos, donde la aspiración colectiva es libre y donde se está contínuamente aprendiendo cómo aprender juntos."

Debemos tratar los problemas como una oportunidad para aprender. En lugar de culpar a las personas, las organizaciones deben tomar decisiones correctivas y distribuir el conocimiento sobre todas sus experiencias. Puedes leer este post acerca de cómo convertirse en una organización que aprende.

Conclusiones

Un problema debe ser abordado cuanto antes posible. Scrum nos ofrece las herramientas para hacer aflorar los problemas. Si no tratamos un problema de inmediato, tardaremos más tiempo en el futuro en arreglarlo. Nos podemos encontrar que a veces esperamos demasiado en declarar una emergencia. Si nos encotramos en esta situación el principipal perjudicado es el propio equipo, puesto que deberá afrontar su resolución con un margen inferior de tiempo.

El Scrum Máster tiene entre sus objetivos impedir que el equipo tenga que destinar demasiado tiempo en la resolución de problemas. Él se responsabiliza de hacer visibles los problemas y de crear las dinámicas para buscar su solución. Dos de las reuniones que propone Scrum nos ayudan de forma directa en la resolución de problemas.

La daily es una herramienta perfecta para detectar los impedimentos con los que se está encontrando el equipo. El Scrum Máster no puede permitir que un impedimento se convierta en un problema. La reunión retrospectiva nos permite identificar el obstáculo más grande con el que se ha encontrado el equipo durante el sprint acabado de terminar. Para poder trabajar en la eliminación de tal impedimento se necesita conocer su origen y así impedir que vuelva a ocurrir.

Conocer la raíz del problema nos permite tomar mejores decisiones.

Si un impedimento persiste en el tiempo empezará a generar ciertas dinámicas negativas dentro del equipo. De algún modo, aunque sea inconscientemente, existirá una conciencia colectiva de tal impedimento. Se trata de una situación verdaremente mala, que afectará negativamente a la productividad del equipo. Cuando un impedimento se enquista, se convierte en un problema. Cuando un problema perdura en el tiempo, puede que sea necesario romper la dinámica anterior. Para generar una nueva dinámica debemos conocer la raíz del problema y proponerla en base a este conocimiento.

Cuando queremos cambiar una dinámica o solucionar un problema debemos decidir lentamente. No sólo lentamente sino por concenso. Debemos debatir abiertamente todas las opciones posibles y buscar cuales se pueden adaptar mejor a las necesidades y cultura de la organización. El proceso de implementación debe ser rápido y seguro.

La estandarización es la mejor comunicación de la solución de un problema. Si crear los procesos correctos obtendrás los resultados correctos. Cuando apliques una solución válida debe formar parte de la estandarización de procesos de la organización. De este modo se consigue transmitir la información a todo el colectivo.

Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!

También te puede interesar...
Pitu Sabadí
Pitu Sabadí
TDD and Agile enthusiast - CEO at Pease Networks

CEO en Please Networks. Fullstack developer y believer en la vida real. Me gusta el trabajo en equipo y conseguir objetivos colectivos. Desarrollando con PHP y AngularJS. AWS para la infraestructura. Amante del agile y el TDD. Training Cloud y Scrumízate mis proyectos personales.