¿Cómo adopté SCRUM?

Quiero comenzar este post, recreando el escenario en el que estuve hace un tiempo al llegar como líder de un equipo de TI.

Como Project Manager, la incertidumbre es uno de los principales obstáculos que se deben derrotar o al menos hacer hasta lo imposible por mitigarlo lo más que podamos. El hecho de no tener un panorama claro no te permite avanzar, tomar decisiones y augura un camino largo que no siempre llega a un final feliz.

En el escenario descrito se conjugaba una serie de factores que eran detonantes para cualquier proyecto, por más sencillo que fuera:

• Un equipo desmotivado por cancelación de proyectos previos. Algunos otros si fueron implementados, pero estaban en desuso por no cumplir con el alcance esperado.
• Alta rotación de personal por falta de motivaciones organizacionales, salarios bajos y poco reconocimiento de su gestión.
• Desconocimiento de la metodología para la gestión de proyectos, que se traducía en hacer lo que mejor consideraban, donde la documentación consumía un 80% de los recursos efectivos para el proyecto.

Sin duda era un barco en medio de una tormenta que debía llevarse a orilla para planear una estrategia clara y zarpar de nuevo.

Con el manifiesto ágil bajo mi manga, trace un plan en donde comenzáramos a dar pequeñas dosis de agilidad a los proyectos, de manera de seducir al equipo con resultados incrementales y efectivos.

Daily meeting

Como buen Project Manager, la comunicación debía ser mi principal arma. Era un gran reto sincronizar a un equipo que jamás se había escuchado y persuadirlos de participar en encuentros diarios, cuando estaban acostumbrados a reuniones estériles de horas.

Estaba claro que debía convencerlos que no era una reunión común y corriente, que no era "perder el tiempo", y para ello el tablero de kanban jugo un rol fundamental en la interacción del equipo con el proyecto. Estableciendo compromisos diarios, medibles y tangibles que brindaran pastillas de éxito todos los días en el ego profesional de cada miembro del equipo.

Fue magnifico el hecho de hacer las reuniones parados, concretas, sin dar cabida a relax, echar cuentos o tomar notas inútiles. La agenda de las reuniones se enmarcaban sólo en responder estas preguntas:

Al ser contestadas estas sencillas preguntas por cada miembro del equipo, era como presionar el botón "sincronizar" y salían de la oficina hablando el mismo idioma y trabajando en pro del objetivo común.

Historias de usuario

Otro reto importante era hacer más eficiente el levantamiento de información, otorgar valor a los proyectos con resultados palpables, más que con documentación extensiva.

Las historias de usuario jugaban un rol fundamental en ello. Definir los requerimientos en peticiones concretas con beneficios claros para la organización ayudó a digerir más fácilmente lo que el usuario requería, al tiempo que invertíamos menos esfuerzo en el levantamiento de información.

Simplemente era documentar la conversación que tuvieron con el usuario, siempre enmarcado en dos apartados diferentes, el enunciado y los criterios de aceptación.

Los documentos pasaron de extensas páginas de requisitos técnicos, casos de uso, UML, etc. a sencillos textos con lenguaje más común. Que además de ser más entendibles, facilitaban la transferencia de proyectos y curva de aprendizaje, fundamental para entornos con alta rotación de personal.

Gestión del cambio

¿El alcance cambio?, tranquilo... que no se acaba el mundo.

La misma tormenta que vivía el equipo de proyectos, la padecían los usuarios, por causas similares y por ausencia de una idea clara de las iniciativas. Esto se traducía en alcances variables, requisitos imprecisos y continuos cambios que retrasaban en gran medida los proyectos. Cada cambio solicitado era la catástrofe para el equipo, puesto que ello significaba doble esfuerzo y replanificación de los objetivos.

En nuestra experiencia, en medio de las iteraciones se producían cambios en los requisitos, pero que en su mayoría no requerían acción inmediata, puesto que no afectaban en gran medida el proyecto, o porque simplemente no estaba contemplado en la iteración que estábamos trabajando. Era tan sencillo como ajustar la historia de usuario e incluirlo en la iteración correspondiente.

Los estándares ITIL hablan de cambios normales y de emergencia. El equipo al no tener clara una metodología de trabajo, consideraba todos los cambios como emergencias, entraban en crisis y demoraban los proyectos más de lo necesario. El equipo se dió cuenta que la mayoría de los cambios no afectaban el proyecto global, ni el producto que pretendíamos entregar en esa iteración. Se dieron cuenta que estábamos trabajando en un entorno mucho más flexible y preparado para los cambios.

Y finalmente, les explique que todo lo que estábamos haciendo y los resultados que estábamos obteniendo, era parte de algo llamado SCRUM.

Al final del día, todo este trabajo se vio reflejado en la implementación de varios proyectos que incrementalmente eran cada vez más sólidos, el equipo de proyecto era más eficiente mostrando resultados y se traducía en mayor motivación organizacional.

No existe una guía fácil que te diga como adoptar SCRUM en 3 pasos, dado que cada mar tiene sus propias tormentas. Más allá de contarles mi anécdota personal o darles la ruta que deben seguir sus barcos, pretendo motivarlos a que hagan un ejercicio de analogía con el entorno profesional en donde se desempeñan y evalúen si es posible hacerlo más ágil.