¿Qué pasa cuando un equipo de Scrum se enfrenta a un impedimento? Pues se crea un gran problema que se tiene que resolver en corto plazo. Si deseas saber cómo identificarlos, sigue leyendo.

¿Qué es un impedimento?

Los impedimentos son esos problemas que surgen en el desarrollo de un proyecto y que hacen que todo se retrase, se complique o fracasen, por ejemplo, que se caiga el servidor, que se pierda el código fuente o que el cliente cambie de opinión frecuentemente.

Para evitar que los impedimentos arruinen el sprint, el equipo de scrum debe identificarlos lo antes posible y buscar soluciones creativas y eficientes. El Scrum Master es el encargado de facilitar este proceso y de eliminar los obstáculos que se interpongan en el camino. Pero no es el único responsable: todos los miembros del equipo deben colaborar y comunicarse para superar los impedimentos y lograr el objetivo del sprint.

¿Son inevitables los impedimentos?

La respuesta simple es sí. ¿Porque? Scrum es utilizado para resolver problemas complejos y de alta incertidumbre, por lo que los impedimentos son parte de la complejidad y la incertidumbre. Los impedimentos son inevitables, pero no insuperables, además crean oportunidades para mejorar. Piensa que son parte del desafío de hacer scrum y pueden ser superados. Los impedimentos se pueden aprovechar para mejorar la autogestión del equipo, la creatividad, la inteligencia colectiva y la experiencia de cada uno de los profesionales que participan en el proceso.

Distintos tipos de impedimentos

Los impedimentos pueden ser internos o externos al equipo, pueden surgir en cualquier momento del sprint. Por eso, es importante identificarlos y comunicarlos lo antes posible, para que el equipo pueda actuar y resolverlos en corto plazo. Entre los impedimentos externos podemos mencionar cualquier situación que no se origina en el proyecto como terremoto, huracanes, pandemias, situaciones políticas o actividades que impactan al proyecto como falta de presupuesto, cambio en la gerencia, etc. Entre los impedimentos internos podemos mencionar:

• No tener claro el objetivo del Sprint. El equipo se da cuenta que las actividades que están realizando, no están enfocadas a alcanzar el objetivo del Sprint, en consecuencia, el objetivo puede no alcanzarse y se necesite otro Sprint para intentar entregarlo.
• Falta de apoyo del Product Owner. El Product Owner se ausenta en el Sprint, los desarrolladores tienen dudas sobre los elementos que trabajan, causando atrasos en las entregas del Sprint.
• Situaciones técnicas. Los Sprints duran días, si es el primer Sprint y se espera que el incremento lo va a utilizar el usuario final, contar con el equipo listo, los ambientes y permisos son requeridos en corto plazo.
• Desempeño del equipo. Los desarrolladores pueden afrontar obstáculos como ser recién contratados, no tener experiencia en Scrum, no son especialistas en el área que están trabajando, etc.
• Falta de autogestión. Los desarrolladores están acostumbrados que alguien les asigne el trabajo y les diga que hacer, es el resultado de la falta de autogestión. Esto genera varios problemas en el rendimiento del equipo, esa persona que le dice que hacer a los desarrolladores forma a ser un cuello de botella.
• Exceso de reuniones. Los desarrolladores participan en reuniones para resolver dudas o aportar en temas que no tienen relación con el Sprint.
• Creación de informes para la gestión de proyecto. Aunque en el enfoque ágil se prefiere unl producto funcionando a una documentación extensiva, en algunas organizaciones, exigen todavía este tipo de documentación. El Scrum Master, el Product Owner u otro rol, se les asigna la responsabilidad de crear reportes de estado y esto les lleva a solicitar información puntual a los desarrolladores. Esto es en sí un obstáculo para alcanzar sus objetivos.
• Ausencia de despliegues continuos y pruebas automatizadas. Al durar poco tiempo los Sprints, por ejemplo 2 semanas, implicaría que el usuario recibiría al mes por lo menos 2 incrementos, esto hace necesario que incrementos sean entregados correctamente. Si los desarrolladores lo realizan de manera manual, la probabilidad de fallas de calidad por compilación se incrementa, esto se reduce con despliegues continuos y pruebas automatizadas.
• Bloqueo del flujo de trabajo para entregar el incremento. El flujo para trabajar un elemento del Sprint Backlog debe ser continuo, dejarlo a la mitad para trabajar otro no es la mejor práctica. El objetivo es disminuir el desperdicio de trabajo, si hay situaciones que impidan terminar el trabajo, el que notará el atraso y se quejará será el usuario.
• Elementos del Sprint Backlog sean ambiguos. Si los elementos a trabajar son ambiguos, puede hacer que los desarrollos puedan ampliarse, en consecuencia, los desarrolladores puedan perder el control de la entrega. Entre más detallado sea, habrá mayor control del desarrollo a realizar, además, puede originar en nuevos elementos para el Product Backlog.
• Cada desarrollador trabaja varios elementos a la vez. Trabajar varios temas a la vez no es la mejor estrategia, lo que hace es atrasar las entregas, puede que estén en varias cosas a la vez, pero no lo terminan.
• Resistencia al cambio por parte de los usuarios o del equipo. Aplicar Scrum no es fácil porque rompe paradigmas establecidos en las organizaciones, habrá resistencia al cambio, por ello, es necesario trabajar con las personas para que puedan aprovechar al máximo Scrum.

La lista puede seguir, a situaciones complejas e inciertas, aparecerán impedimentos que probablemente no nos habríamos imaginado. El Scrum Master debe ayudar al equipo a definir un plan para eliminar los impedimentos, y facilitar la comunicación con los interesados (personas que son afectados o que pueden afectar al proyecto) y otros equipos. El objetivo es que el equipo pueda trabajar de forma eficiente y alcanzar el objetivo del Sprint con calidad.

Acerca del autor:

Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.

Imagen: Creador de imágenes de Bing