¿Te ha pasado que tienes problemas en obtener resultados en un proyecto ágil y no sabes porque sucede si estas siguiendo al pie de la letra lo que indica el marco de trabajo que estás utilizando? Si deseas saber algunas razones del porque fallan, sigue leyendo y lo sabrás.

Algunos creen que el utilizar un enfoque ágil es simplemente utilizarlo como una receta y esperar que dé resultados, he escuchado que es más simple que el enfoque tradicional como tener menor documentación, no hay jefes o no establecer una planificación desde el inicio el proyecto. Creen que estas características de por sí son las causas del fracaso de éste enfoque. Ojalá que así fuera de sencillo, tengo la duda si lo dicen como una manera de vender el enfoque ágil o sencillamente no saben el trabajo que implica, es más, requiere más esfuerzo y conocimiento este tipo de enfoque, ya te explicaré porqué.

Factores que debes tomar en cuenta

Todo proyecto es único debido al contexto de este. Sin embargo, algunos factores que se necesita contemplar al trabajar en este tipo de proyecto son:

• Incertidumbre del proyecto. Dependiendo el nivel de complejidad e incertidumbre del proyecto, se escogerá el enfoque más adecuado, si la complejidad y la incertidumbre es baja, se podría utilizar un enfoque tradicional para maximizar los recursos disponibles. Por el contrario, si no hay claridad a donde se quiere ir o la complejidad es muy alta y es necesario hacer cambios rápido, el enfoque ágil sería más apropiado para trabajarlo. Utilizar un enfoque para todo proyecto no importando su nivel de incertidumbre es un factor de fracaso porque no se aprovechará los recursos de la mejor manera.
• La práctica ágil involucra a todos los interesados. Algunos tienen la idea que solo los equipos deben ser ágiles y los demás siguen con sus prácticas habituales. Practicar la agilidad no es exclusivo de los equipos de proyecto, tiene que involucrar a la gerencia y demás interesados, este enfoque necesita de mayor interacción del equipo y los interesados. He visto como los usuarios al no tener claro este enfoque, esperan que su participación sea limitada y que desean un resultado al final del proyecto, es todo lo contario, por lo que se requiere que todos tengan claro cómo es el flujo de trabajo en este enfoque.
• Manejo del cambio. Utilizar un enfoque ágil requiere adaptarse a la situación que se encuentra, por lo que hace que los equipos tengan que adaptarse, muchas personas no quieren cambiar, desean hacer las cosas de la misma manera, este es un factor de hará la diferencia. He visto a equipos que sus miembros se han certificado el marco de trabajo que están utilizando, sin embargo, en el momento de una crisis, regresan a sus prácticas habituales porque creen que obtendrán resultados, sin embargo, ha causado desgaste en el equipo y pocos resultados. Es como si te dieran un auto, pero estás acostumbrado a manejar un bus escolar, por la costumbre no irás a alta velocidades y tengas que acostumbrarte la manera de manejarlo, llevará tiempo.
• Equipo adecuado a este tipo de enfoque. El que el enfoque ágil sea utilizado en proyectos con un alto nivel de incertidumbre, debe ser una llamada de atención para las personas que tienen la decisión de crear al equipo. Se requiere de personas con un conocimiento de negocio y técnico, sean multifuncional y autogestionados ¿por qué? Este enfoque requiere que se haga entregas parciales de semanas y no de meses o años, es necesario que el equipo se adapte a nuevas situaciones en cualquier momento y tome decisiones, esto es más difícil con personas recién contratadas o que no puedan autogestionarse, no obtendrán un resultado inmediato. Escucho a gerentes decir que se espera que el resultado de estos equipos sin experiencia o falte de autogestión darán resultados a mediano y largo plazo, a ello les digo, que su lógica es válida en un enfoque tradicional donde entregan valor en medio año o más, sin embargo, ¡es necesario dar resultados en semanas!
• Tener claro que significa no tener jefes. En Scrum (por ejemplo) no hay jerarquías, hay un Equipo Scrum conformado de Product Owner, Scrum Master y de desarrolladores, algunos se ponen felices por no tener jefes, sin embargo, no se dan cuenta que esto significa que todo el equipo es responsable del resultado y no un individuo en particular. Para algunos, no les gustará esta situación, en especial si les gusta sobresalir o no les gusta trabajar en equipo, pudiendo generar problemas de coordinación y búsqueda de alguien que les diga que hacer para disminuir su responsabilidad. Un equipo autogestionado mitiga esta situación, es por ello que las personas que conforman el equipo tengan características de negocio, técnica y autogestión.
• Mantener el flujo de trabajo
  en movimiento. Al definir un flujo de trabajo, es esencial que no se detenga, por ejemplo, en Scrum, el flujo se divide en Sprint, el cual se define que dura un par de semanas, significa que el siguiente Sprint inicia cuando termina el primero y así sucesivamente. Si hay trabajo en el primer Sprint que no se terminó, se evalúa si se trabajará en un futuro, de esa manera los Sprints, siguen su flujo para entregar valor. Ahora bien, que pasa si esto no ocurre, por ejemplo, si el primer Sprint se extiende por diversas causas (problemas de infraestructura, mala calidad, etc.), esto puede generar que los demás Sprints se atrasen, hay equipos que, al evitar esta situación, los trabajan en paralelo, perdiendo el control de los entregables y complicando más la gestión de éstos.
• Comunicación
  efectiva. Este tipo de proyectos donde se entrega valor de manera continua, requiere que los integrantes del equipo conozcan que hacen sus compañeros para tomar decisiones lo más pronto posible, obligando a que las reuniones sean eficientes para poder entregar a tiempo. No ayuda tener reuniones maratónicas para conocer el estado del proyecto o resolver un problema, es todo lo contrario, se vuelve un problema.
• Calidad. Se cree que al entregar en poco tiempo es sinónimo de mala calidad, sin embargo, para que esto no ocurra, es necesario mejorar algunas prácticas como el desarrollo, testing o refactorización. Esto mueve al equipo a mejorar los estándares de calidad, utilización de herramientas de automatización de código, mejoras en la inspección del producto, etc.

Hay más factores que influyen en el éxito de un proyecto, sin embargo, no hay una receta para ello por el simple hecho que este tipo de proyectos la incertidumbre es alta, por lo que siempre estará la situación de utilizar nuevas prácticas para resolver los impedimentos del proyecto.

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