El iceberg de los problemas
En el día a día de un equipo ágil, nos topamos constantemente con obstáculos. A menudo usamos términos como "bloqueo" e "impedimento" de forma intercambiable, pero entender sus diferencias es crucial para una gestión y una remoción efectiva de impedimentos. Además, si no llegamos a la "causa raíz", solo estaremos apagando incendios superficialmente.
1. Bloqueos
Un bloqueo es una situación actual que detiene completamente el progreso inmediato de un artículo de trabajo (historia de usuario o tarea) . Es una barrera infranqueable que impide que el equipo o un miembro del equipo avance en su tarea. El trabajo se detiene "aquí y ahora".
Características:
Detiene el progreso: El trabajo no puede continuar.
Actual y directo: Es un problema presente y concreto.
Alta visibilidad: Suele ser obvio que el trabajo está parado.
Ejemplos comunes:
Fallas del entorno técnico: El entorno de desarrollo está caído.
Dependencia de otro equipo/miembro: Necesita la entrega de un componente crítico de otro equipo para continuar su tarea, y esa entrega no está disponible.
Errores graves de ACL o seguridad: No tienes los permisos necesarios para acceder a un recurso vital para tu trabajo.
Recurso no disponible: El servidor de pruebas está caído y nadie puede trabajar en él.
2. Impedimentos
Un impedimento es un obstáculo o dificultad que ralentiza o dificulta el progreso del equipo o de las tareas , pero no necesariamente las detiene por completo. Puede ser una fricción, una ineficiencia o un problema recurrente. Los bloqueos son un tipo de impedimento, pero no todos los impedimentos son bloqueos.
Características:
Ralentiza/dificulta: No necesariamente detiene por completo.
Puede ser recurrente: A menudo son problemas sistémicos.
Más amplio que un bloqueo: Puede afectar a varias tareas o al flujo general del equipo.
Ejemplos comunes:
Reuniones improvisadas/excesivas: Consumen tiempo valioso y rompen el foco del equipo.
Falta de habilidades necesarias: El equipo carece de una habilidad específica para una tarea, lo que los ralentiza.
Problemas de hardware/software (sistema lento, fallas de internet): Dificultan la productividad, pero no la desconectada por completo.
Cambios frecuentes en los requisitos: Obligan a retrabajo y rompen el flujo.
Malentendidos entre miembros del equipo: Generan fricciones y comunicación ineficiente.
Presión por parte de la dirección: Puede llevar a atajos o crunch mode .
No saber hacer una "Solicitud de cambio" para desplegar en producción: Ralentiza el despliegue.
No tener un entorno de pruebas habilitado que suelen ser pedidos a un equipo de DevOps o Infraestructura: Si bien es un cuello de botella, el trabajo puede avanzar en otras áreas mientras se espera.
Equipo desmotivado: Impacta la productividad general.
3. Riesgos
Un riesgo es un evento o condición incierta que, si ocurre, tendrá un efecto positivo (oportunidad) o negativo (amenaza) en los objetivos del proyecto o del producto. No ha sucedido aún; es una posibilidad futura.
Características:
Incierto: Puede ocurrir o no.
Futuro: No es un problema presente, sino potencial.
Potencial de impacto: Si se materializa, tendrá consecuencias.
Ejemplos comunes:
Complejidades que no pudieron preverse con antelación: Existe la posibilidad de que una funcionalidad sea más compleja de lo estimado.
Dependencia futura de software de terceros: Existe el riesgo de que una librería externa necesaria no esté lista a tiempo.
Miembro del equipo enfermo (planeado): Saber que un experto clave estará de vacaciones en el futuro crea un riesgo de capacidad.
Arquitecturas deficientes (potenciales): La arquitectura actual no puede escalar a futuro, lo que es un riesgo para el crecimiento.
4. Causas Raíz
Una causa raíz es el origen o la razón fundamental de un problema (bloqueo, impedimento, riesgo materializado) . Es el factor subyacente que, si se elimina, previene la recurrencia del problema o reduce su impacto. No es el síntoma, sino la razón más profunda por la que aparece el síntoma.
Características:
Origen del problema: Es la causa fundamental.
Profundo: No es superficial, requiere información.
Eliminación evita recurrencia: Abordarla previene futuros problemas.
Ejemplos:
Falta de Seguridad Psicológica en el ambiente de trabajo.
Una API Legacy : Existe una API Legacy que tiene alta probabilidad de fallar por usar tecnologías obsolteas y arquitectura monolítica y con deudas técnicas que no soporta la sobrecarga de peticiones.
El rol de los líderes:
Hay roles que tienen como parte de su función la remoción de impedimentos. El Scrum Master, por ejemplo, es el principal responsable de ayudar al Equipo Scrum y a la organización a abordar los bloqueos e impedimentos que dificultan el progreso y la adopción de agilidad. Esto incluye no solo eliminarlos, sino también identificar los riesgos antes de que se materialicen y, principalmente, llegar a las causas raíz para implementar mejoras sistémicas. Sin esta claridad, los equipos se limitan a "apagar incendios" sin resolver los problemas de fondo.
Otros roles y cualquier líder ágil debería pensar sistémicamente para mejorar la organización solucionando los problemas de causa raíz. Una herramienta del pensamiento sistémico es el Iceberg del pensamiento sistémico.
El iceberg del pensamiento sistémico es un modelo de pensamiento útil para los líderes que abordan problemas insolubles que parecen no desaparecer. Parte del desafío reside en lo que el modelo denominado "eventos": problemas superficiales que están constantemente presentes, que en esencia sirven para apagar incendios, pero que nunca abordan las verdaderas causas.
Referencias:
No hay comentarios:
Publicar un comentario