Proyectos - Un inicio ágil bastante lento.

Un inicio ágil bastante lento

Un cambio de metodología va mucho mas allá del conocimiento de la misma pues conlleva a asumir una filosofía que no todos estamos dispuestos a seguir. Las metodologías ágiles parten de planteamientos bastante admirables, y dado su poco nivel de prescripción, iniciarse en ellas sin la ayuda de un experto con experiencia puede ser bastante complejo.

A continuación una serie de dificultades que nos encontramos tratando de iniciar un proyecto con SCRUM:

• Falta de alineación: Suena a frase de cajón pero esta es la principal dificultad al iniciar cualquier proyecto. ¿Que es lo que quiere lograr el negocio?, ¿El producto owner está alineado 100% con lo que quiere lograr y las prioridades definidas son un reflejo de tal alineación?

• Incapacidad para priorizar: El negocio siempre quiere tenerlo todo. La consecuencia es que termina teniendo nada.

• Falta de herramientas: Pareciera ser un ítem bastante trivial pero la metodología plantea el uso de muchos elementos (Post-its, marcadores, tablero, tarjetas de estimación de poker, tarjetas de escritura de historias de usuario, entre otros) que en ausencia de ellos entorpecen el proceso. 

• Visión del proyecto: Todos los miembros del equipo deben tener la misma visión del objetivo que debe lograrse. Pida a varios miembros del equipo que explique las metas que deben alcanzarse y le beneficio que se entregará al completar el proyecto. Muchos probablemente no conocen estos datos.

• Demasiado tiempo en el arranque: Quedarse mucho tiempo definiendo planes, herramientas, haciendo consensos o cualquier otra cantidad de cosas, puede ser contraproducente. ¡JAMAS ESTAREMOS LISTOS PARA ARRANCAR!, de modo que es mejor dedicar un tiempo corto y limitado a esta labor y ajustar todo los que sea necesario en los primeros sprints. Lo importante es que se maneje la expectativa y no se esperen grandes resultados pues el equipo apenas se estará organizando.

• Orientación a generar valor al negocio: En todo proyecto de desarollo lo común es que se realicen actividades orientadas a generar la base de desarollo que permitirá construir la funcionalidad requerida por el negocio. En SCRUM es vital que en cada iteración se entregue valor aún cuando sea mínimo y encontrar este equilibrio no es fácil. ¿Como decirle al usuario que en 8 días no pudimos hacer nada porque configurar la aplicación fue muy complejo o porque no alcanzamos a definir el plan de GCS?. Esto es inaceptable.

• Justificar la tecnología de implementación: Algunas veces el tiempo y el costo de implementación pueden variar considerablemente por la inclusión de una nueva tecnología. Justificar el ¿Por que? al negocio es una labor compleja si no se explica en sus términos. De hecho siempre se debe buscar el beneficio de esta ante el usuario, ya sea de cara a una mejoría en la aplicación o en temas de proyecto como tiempo o costo, en el mediano o largo plazo.

• Expectativa: Muchas veces el negocio espera mucho mas de lo que le podemos ofrecer con el tiempo y el presupuesto disponible. Alinear expectativas es importante al inicio de modo tal que no se lleven una gran desilusión. Esto suele ser una labor ardua.

• Pretender hacer planes al inicio: Los planes deben estar el servicio del equipo por lo tanto este es quien los diseña de acuerdo a sus necesidades. Muchas veces se pretende definir formas de trabajo (TDD, ATDD, DDD, BDD, etc) pero es la realidad del proyecto la que determinará la mejor combinación. Es importante sentar una base común al inicio. Por ejemplo, el plan de gestión de la configuración podría diseñarse previo al desarollo pero esto no impide que cambie durante el proyecto.

• Intermediación: Para solucionar un problema se pasa por varios intermediarios hasta llegar al responsable. Esto dilata demasiado el tiempo de resolución del problema.

• Impedir la autogestión del equipo: El rol del scrum master no se asume plenamente y se ve viciado por elementos de las metodologías tradicionales de gestión de proyectos, rayando en algunas ocasiones con el seguimiento, control y la interferencia en la toma de decisiones.

• Falta de foco: Es muy común que cada miembro del equipo se concentre en una historia de usuario y al final queden varias empezadas. Sobre todo al inicio cuando el equipo no conoce su velocidad es preciso enfocarse solo en ciertos items de modo que se garantice la entrega de algo aún cuando sea poco. Solo los items completos que dan valor al negocio generan avance.

• No tener en cuenta a los stakes holders: Dada la velocidad con la cual se generan entregables en SCRUM, es muy importante que todas las áreas que intervienen de manera directa o indirecta en el ciclo de vida del producto hasta que llega a producción, se tengan en cuenta. Si requerimos permisos en la estación de trabajo, configuraciones en los servidores previo al paso entre ambientes, configuraciones de bases de datos,  o cualquier otro tema que dependa de otros, debe identificarse a quien acudir y tenerlos en cuenta desde el inicio. Si cualquiera de ellos no ofrece la ayuda adecuada en el momento justo, probablemente no generemos valor en muchos sprints.

De todos los aspectos mencionados el mas impactante es el ultimo. Los stake holders afectan de una manera impresionante todo el proceso. Durante el primer sprint del proyecto objeto de análisis no se entregó absolutamente nada por lo siguiente:

• Una de las estaciones de trabajo tenía problemas y la dependencia con soporte tecnológico impedía avanzar en este frente
• No se tenía acceso como administrador a la estación de trabajo por lo que no era posible instalar el software requerido para iniciar labores.
• Se requerían accesos servidores y aplicaciones existentes dentro de la compañía cuyos responsables tenían un acuerdo de servicio demasiado amplio para un proyecto SCRUM.

Los errores cometidos nos son muy diferentes a los que se presentan en proyectos gestionados de forma tradicional. La diferencia radical es que bajo esta metodología se falla rápidamente. Muchos de estos problemas los aprende a manejar el equipo en el tiempo conforme adquiere autonomía y el apoyo de los stakes holders. Esto se evidenció después del primer sprint en el cual se pudo generar valor. 

Solo un poco pero se generó valor¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡.