¿Viste esos momentos en los que estamos profundamente inmersos en la resolución de un problema técnico en un proyecto?
Muchos de estos momentos son importantes ya que comunmente nos ofrecen grandes desafíos intelectuales, y una vez resueltos nos brindan momentos de gran satisfacción para nuestro sistema mental de recompensas. Siendo que muchas veces, especialmente cuando se trata de un proyecto solo, realmente no hay otra forma, tenemos que tener esta actitud heroica para ser "asesinos de problemas" en el proyecto, lleve el tiempo que fuese necesario (en minutos, horas o días), y a cualquier costo, al final sino las cosas no caminan.
Sin embargo, si el escenario es de interés para un trabajo en equipo, ¿cuál es el costo para el proyecto cuando se producen estas situaciones? La otra pregunta interesante surge cuando hay una resolución heroica e individual de esos problemas, ¿cuál es el daño al intercambio de conocimientos para la organización?
Ahora imaginá cómo trabajar estos temas en una línea de producción en una fábrica (de cualquier cosa, coches, muebles, comida, etc.) Dado que las instalaciones de ese tipo suelen trabajar con medidas de tiempo en minutos (incluso segundos), tratan de medir el impacto negativo del costo, del plazo o la calidad si se produce algún problema en algún punto de la línea de producción y que el mismo sea escondido (lease no comunicado).
Por supuesto, en el desarrollo software la visión cambia bastante, más con bases en estos cuestionamientos. Les ofrezco este breve texto, que tiene como objetivo elucidar cómo podemos utilizar con efectividad la gestión ágil y ajustar la remoción de obstáculos en nuestros proyectos desarrollo de software.
En este contexto, asumimos que la clave para que las soluciones sean efectivas dentro de un equipo, es tener una forma de comunicación simple y asertiva, a fin de facilitar el proceso de descubrimiento de problemas y tener los medios para impulsar la solución adecuada al problema que fuera descubierto.
Es importante entender que un concepto básico que influencio la forma actual de gestionar los impedimentos en las metodologías ágiles, es la herramienta Andon, propuesta y utilizada por TPS (Sistema de Producción Toyota), que consiste en algún medio físico basado en un sistema de cables o luces, para que sea posible una advertencia visual de alto impacto, cuando hay algún problema en cualquier parte del proceso de producción.
El dispositivo físico en sí es relativamente simple, pero detrás de esta herramienta existen importantes actitudes que realmente añaden valor al proceso, cuando son apoyados por Andon, por ejemplo:
- Dentro de TPS, hay una fuerte cultura de buffers (amortiguadores) para absorber posibles desviaciones oriundas de la resolución de problemas en la línea de producción.
- Inspecciones en la fuente e inspección del 100% - Los controles de calidad no son realizadas por muestreo de lotes, sino que se verifica unitariamente cada etapa del proceso, es decir, es muy pequeño el margen de que algún problema no sea detectado antes de que el producto es retirado por siguiente operación.
- La cultura de detener y resolver - Cuando hay un problema en la línea de producción por mas simple que puede ser, muy probablemente la calidad se verá afectada negativamente, por lo que la cultura TPS estimula que la línea de producción no se lleve adelante, hasta que se resuelva el problema.
- La cultura de prevención de las reincidencias es otro motor que impulsa TPS, o sea, soluciones paliativas no son bienvenidas, en función que las mismas impacten negativamente la calidad del producto que será entregado.
- Eliminar el desperdicio - En este punto, el razonamiento es simple, ya que mientras más eficiente y eficaz, fuera la solución aplicada, menos desperdicios son generados por el problema en cuestión.
- Por supuesto, hay una estructura muy eficaz de personas con capacidad analítica y creativa para resolver efectivamente el problema en el menor tiempo posible.
Claro, hay otros detalles que fascinan a cualquier persona interesada en cuestiones de ingeniería de producción, sin embargo, me gustaría concentrarme en el concepto principal y mostrar la aplicabilidad de la misma en el contexto del desarrollo de software.
Aunque el mecanismo por el cual podemos obtener un Andon en el área de desarrollo (por ejemplo, utilizar una tarjeta con un color diferente para un impedimento) es potencialmente más simple que el Andon original de TPS, su aplicación en los equipos de desarrollo es mucho más compleja porque, como ya se ha mencionado en el artículo Vencendo o Estado de Negação na Sprint Retrospective existen algunos mecanismos de nuestra compleja mente humana, que nos impiden transparentar nuestros problemas y nuestras limitaciones, esto se debe a una reacción de defensa de nuestra imagen que vista por otras personas, siempre tiene que ser lo más perfecta posible.
Aunque resulta dificil romper con este mecanismo de defensa, la práctica de la eliminación de los impedimentos fue potenciada y se hizo popular en el desarrollo de software, a través de las ideas de Scrum, donde se ha convertido en fundamental para el trabajo del ScrumMaster que los impedimentos sean manifestados y expresados en algún medio (por ejemplo, el cuadro de Kanban) y en algún momento (por ejemplo, la Reunión Diaria), para que así su remoción sea realizada de la forma más eficiente y eficaz posible.
Observe que nuestro Andon es mucho más subjetivo (basado en actitudes) que el físico, porque, como uno de los pilares de la actividad del ScrumMaster es ser un "líder servidor" a través de la facilitación y coaching, es parte de su día a día ayudar al equipo a remover los impedimentos, por lo tanto es esencial que el mismo estimule a los miembros en las reuniones y a través de las herramientas adecuadas, a que cualquier impedimento sea manifestado.
Concluyo el texto, reforzando la idea de que la esencia de un Andon (manifestar un impedimento) dentro de un proyecto de desarrollo de software, va más allá de simplemente utilizar una herramienta visual (tarjetas de Kanban de colores diferentes) para exponer los impedimentos, pues es vital que sea quebrada de alguna manera la naturaleza humana de esconder las propias imperfecciones y asumir que no somos un "superhombre" inmune a los errores y capaz de resolver por nosotros mismos todo y cualquier tipo de problema, sino que somos seres limitados (en alguna cosa) y a menudo necesitamos de ayuda para resolver algún tema, porque como dijo el Antiguo Guerrero (Chacrinha), "quien no se manifiesta se joroba".
