Una de las sesiones más comentadas del Simposio del PMI '17 fue la de Seth Norburg, Supervisor de Gestión de Programas en Caterpillar. En su sesión, Seth recorrió el Agile Journey de Caterpillar Equipment y cómo fue la introducción de las metodologías ágiles en este gigante industrial de 100 años.
El equipo del Sr. Norburg era una PMO central que ofrecía algo así como un apoyo de consultoría a los equipos locales a la hora de estructurar y ejecutar los proyectos.
El viaje ágil de Caterpillar Equipment
Inicialmente tenían un equipo de software que tenía 
adoptó el método ágil, que tuvo bastante éxito. Cuando otro equipo pidió a la PMO central que les ayudara a adoptar también la agilidad, no les fue tan bien. De hecho, las palabras que utilizaron fueron "fracaso total". Al revisar las lecciones aprendidas, determinaron que su fracaso en la implementación de agile para el segundo equipo se debió a que tenían:
- Conocimiento insuficiente de las metodologías ágiles
- No sabía qué metodología "ágil" utilizar
- Necesidad de involucrar a más equipos
La siguiente oportunidad que tuvieron de implantar la metodología ágil fue con un equipo que tenía problemas de alcance rampantes: alcance incontrolado, cambios frecuentes de requisitos y ciclos constantes de planificación y replanificación.
Lo que hicieron esta vez, antes de la implantación, fue empezar por ponerse en contacto con las principales partes interesadas para identificar la comprensión actual del equipo y sus actitudes hacia lo ágil, de modo que pudieran planificar las estrategias de formación y respuesta adecuadas. Descubrieron que el equipo pensaba que:
- Si utilizamos el método ágil, ya no es necesario cumplir los plazos
- nuestro proyecto es demasiado grande para ser ágil
- no estamos ejecutando un proyecto informático, por lo que no es aplicable la metodología ágil
- no podemos utilizar la agilidad a menos que estemos ubicados en el mismo lugar
- ¡No necesitamos un plan en agile!
Su temprana y 
El enfoque consistente era la educación y la formación, que incluía la identificación de los puntos clave de resistencia y el intento de abordarlos. La clave para ello fue centrarse en las cosas que son similares entre Agile y Waterfall:
- AMBOS utilizan la iteración y la elaboración progresiva
- Ambos tienen un jefe de proyecto, ambos tienen una carta de navegación. El PM / líder facilita la colaboración entre el equipo y las partes interesadas. Así que, al final, se trata de trabajar con la gente para conseguir algo.
Y, en definitiva, 
A los patrocinadores de las empresas no les importa lo que hagamos para cumplir, sólo les preocupan los resultados.
A la hora de ponerlo en práctica, se centraron en tres áreas:
- Educación y formación
- Gestión del cambio
- Proporcionar ofertas de servicios flexibles para apoyar la metodología adecuada
Pero... ¿qué metodología era la correcta?
La metodología
El equipo de Caterpillar examinó las metodologías ágiles y decidió que la única metodología que podía gestionar su trabajo a nivel de proyecto, programa y cartera, y abordar las necesidades de los componentes en cascada de un programa era SAFe Agile. Este enfoque:
- Se basa en los principios Lean/Agile
- Soporta Scrum, Kansan y XP
- Proporciona una gestión ágil de carteras y programas
- La mejor escalabilidad y adaptabilidad
Programas híbridos
Por supuesto, no tenía sentido llevar a todos los equipos de forma ágil, ni podían asegurar que todos los equipos del mismo programa fueran ágiles - entonces, ¿cómo gestionar un programa híbrido? A continuación se muestra una ilustración de cómo combinaron proyectos ágiles y en cascada en el mismo proyecto -
- Alinearon las historias de usuario para alcanzar los hitos y dependencias clave.
- Su regla general era que cada sprint tenía que tener algún tipo de material entregable, aunque no fuera una prueba completa
- A continuación, superponen los hitos de gestión
- Se añaden los GANTT del trabajo basado en la cascada (legal, infraestructura, etc.)
- Por último, para mantener todo unido, mantuvieron un detallado registro de dependencias, que describía las dependencias entre los equipos ágiles y los equipos de cascada, lo cual es fundamental para que todo funcione.
Restos de cascada
Están y piensan seguir funcionando en un entorno "híbrido", porque 
Algunos proyectos son más adecuados para Agile y otros para Waterfall. En general, su enfoque era que si un proyecto tenía un alcance muy duro, era mejor para la cascada. Si había alguna posibilidad u oportunidad de que el alcance se flexionara o pudiera flexionarse, lo llevaban a Agile. Y admitían libremente que esta elección no siempre era fácil, ni siempre 
bien a la primera. En ocasiones, se encontraron con que necesitaban llevar un proyecto Waterfall Agile, o un proyecto Agile Waterfall.
Herramientas
En cuanto a las herramientas, parece que se trata de un trabajo en curso. Para los componentes en cascada, utilizan Primavera, que también parece ser el lugar donde realizan la mayor parte de su planificación financiera, representando cada sprint ágil como una barra de tareas de 2 semanas. Hoy en día no existe una integración automatizada, todo se introduce manualmente, en cada uno de los sprints.
En cuanto a la agilidad, utilizan Microsoft Visual Studio Team Services (VSTS). Esta herramienta permite a los equipos introducir y gestionar épicas, características, historias y tareas, y también es compatible con Kanban. Aunque otras herramientas pueden ofrecer estas características, ya tenían experiencia interna, así que decidieron optar por ella.
El lado negativo de estas herramientas es que no hay integración, por lo que hay mucho trabajo manual de procesamiento posterior para obtener los datos reales mensuales. Aunque no se ha dicho, imagino que el seguimiento de las dependencias debe ser manual y, probablemente, supone un gran trabajo de mantenimiento y actualización.
Lecciones aprendidas
- La educación es absolutamente clave para el éxito en la implementación de Agile, y debe ser una transformación de arriba hacia abajo
- Apuntar a un piloto exitoso
- Desarrollar un modelo sólido para la educación, abordando las necesidades de los miembros del equipo, los maestros de scrum, los propietarios del producto y los entrenadores ágiles
- La transformación no es fácil y requiere un cambio total de mentalidad.
- Comprender los beneficios de cuándo/dónde utilizar agile, waterfall o bot
¿Preparado para la agilidad?
Contact Us to find out more about our Project and Change Management Services, please email us at PPManswers@KolmeGroup.com.
Asegúrese de seguirnos en Twitter, LinkedIn y YouTube y utilice #KolmeGroup en las publicaciones compartidas.
Reserve su consulta