PMI Barcelona Chapter

Agile en la PMO: Preparando a los Stakeholders para la Agilidad

Agile en la PMO: Preparando a los Stakeholders para la Agilidad

Perfil_LIM.jpg

By Ivan Seligmann

El contexto

Implementar Agile desde cero podría ser un desafío interesante, especialmente cuando no estamos hablando de proyectos de software, y más aún cuando no estamos hablando de proyectos aislados, sino a nivel de la PMO. La mentalidad Waterfall tradicional es la característica más frecuente que se encuentra entre los interesados dentro de una PMO, ésta será la principal materia prima para un proceso artístico de conversión hecho a mano. Estas personas suelen ser muy seguras de sí mismas, y también confían fuertemente en las WoWs (Ways of Working) que les han servido fielmente durante muchos años; definitivamente tienen un punto. Incluso cuando saben que el cambio es necesario, es frecuente y lógicamente difícil para ellos aceptar este cambio y despedirse de grandes viejos amigos como reportes, métricas y procesos tan asombrosos.

Necesitamos ser amables y cuidadosos con estas personas, en general estarán acertados en muchas de sus preocupaciones, por lo que es muy importante acompañarlos, capacitarlos, brindarles un nuevo conjunto asombroso de informes, métricas y procesos redefinidos, para permitirles familiarizarse con la nueva mentalidad y experimentar por sí mismos el proceso de transformación necesario para permitirse confiar en algo nuevo.

El objetivo de este artículo es hacer que este viaje sea lo más sencillo y menos costoso posible, veamos cómo podemos facilitar y acelerar el proceso de preparación para que los interesados de nuestra PMO conozcan, comprendan y finalmente amen Agile.

Antes de comenzar

Cuando necesite comenzar a implementar Agile en una PMO tradicional, conocer a sus interesados es tan crucial como para cualquier proyecto estándar, incluso podría considerar esta implementación como un proyecto en sí, y debe identificar y clasificar a sus interesados principales cuidadosamente. Debe ser capaz de afirmar con precisión quiénes de ellos están a favor o en contra de la agilidad, y tendrá que trabajar de cerca e involucrar en el proceso tanto como sea posible a los más reacios. En la siguiente tabla, tiene algunos consejos que lo ayudarán a reconocerlos de acuerdo con su mentalidad y comportamiento habituales:

Listo para Agile

Necesita preparación y tutoría

Abierto a los cambios

Piensa que el costo crece a medida que los requisitos cambian

Colabora a diario con los miembros del equipo

Estrictamente cernido a las políticas y procedimientos

Prefiere las conversaciones en lugar de correos electrónicos

Espera identificar todos los requisitos antes de comenzar el proyecto

Facilita las necesidades de los proyectos y elimina los impedimentos

Se frustra cuando los requisitos del proyecto cambian

Revisa con frecuencia los productos entregables con otros interesados

Cree que las pruebas frecuentes ralentizan el progreso del proyecto

 

Utilice esta información de manera inteligente y conjunta con su propio criterio y cualquier otra información que pudiera recabar sobre las opiniones, puntos de vista y preocupaciones de todos ellos, especialmente de los que se muestran reticentes al cambio; su principal desafío será mantenerlos a su lado, a lo largo de todo el camino de implementación, mostrándoles permanentemente los beneficios y ganancias de cualquier pequeño cambio. Al final, no es una locura esperar que sean sus seguidores más entusiastas.

Agile es exclusivo para proyectos de software

Por supuesto que no! Sin duda, este es el mayor mito en torno a la agilidad, y creo que es muy fácil superarlo. Me encantan los ejemplos de la “vida real” para explicar este tipo de temas controvertidos, los encuentro muy ilustrativos; pensemos en la siguiente situación:

Ha sufrido un desafortunado accidente, cayendo por una ladera, afortunadamente se encuentra ileso pero su ropa está totalmente hecha jirones, entonces de repente está desnudo y la gente comienza a amontonarse a su alrededor, no tiene ropa nueva para vestir, pero tiene hilo y agujas para coser… Suponiendo que el clima sea agradable, ya que un frío polar definitivamente cambiaría el orden de los entregables desde la perspectiva ágil: ¿Cuál sería el enfoque que elegiría en esa situación?

  • Waterfall (el orden no es estrictamente relevante)
    • Arregla la camisa
    • Arregla los pantalones
    • Arregla la ropa interior
    • Arregla los zapatos
    • Arregla los calcetines
    • Se viste completamente
  • Ágil (el orden definitivamente importa aquí ...)
    • Repara la ropa interior, se la pone
    • Repara los calcetines, se los pone
    • Repara su pantalones, se los pone
    • Repara la camisa, se la pone
    • Repara sus zapatos, y se los pone

Supongo que se entiende el concepto, ¿Verdad? No es sólo una cuestión de software, siempre que pueda entregar valor, más rápido y en piezas pequeñas, hará que su cliente (usted mismo en este caso) sea más feliz, así que ¿por qué evitarlo? También con respecto a los cambios, ¿qué sucede en el enfoque Waterfall si una vez que termina de coser todo, encuentra que cometió un error con la ropa interior y necesita rehacer esa reparación? ¡¡Aún no puede vestirse para nada!! Por otro lado, con el enfoque Agile, lo arreglará en el momento y luego podrá seguir cosiendo la ropa restante, pero al menos ya no estará completamente desnudo.

No quisiera ser repetitivo sobre los valores de Agile, pero es importante considerar una diferencia en el Manifiesto Agile cuando hablamos de PMO (o de proyectos que no son de software) en lugar de proyectos de software exclusivamente, veámoslos una vez más:

  • Individuos e interacciones sobre procesos y herramientas
  • Colaboración con el cliente sobre negociación de contratos
  • Responder al cambio sobre seguir un plan
  • Software funcionando sobre documentación exhaustiva

Dependiendo del caso, el último valor sería:

  • “Productos utilizables y / o servicios utilizables y / o procesos y / o resultados impulsados ​​por el valor del cliente” sobre documentación exhaustiva.

Preparación de actividades educativas

Cuando piense en cómo involucrar a las personas con una idea, existen dos formas principales de aumentar las probabilidades de éxito, mostrando su “producto” en acción, mediante capacitación, demostraciones en vivo, casos de éxito e historias de la vida real, y aún mejor el experimentar sus beneficios en carne propia. Con la planificación y realización de actividades educativas, podría aprovechar ambas opciones al mismo tiempo, diseñando una combinación de ellas y además, si quiere matar dos pájaros de un tiro, también es una gran oportunidad para organizar estas actividades dentro de un entorno de team building.

Hay varias actividades con eficacia probada que podría utilizar para educar y preparar a los interesados principales, tendrá que decidir cuáles tienen más o menos sentido para ser aplicadas de acuerdo a cada contexto específico. El objetivo principal es desarrollar la comprensión y la aceptación necesarias del impacto de cambiar a Agile y sus resultados esperados, para que puedan asimilar este impacto minimizando la resistencia al cambio y las posibles disrupciones. Entre los principales recursos que podría considerar, tenemos:

  • Entrevistas individuales
  • Reuniones de equipo
  • Reuniones informativas
  • Reuniones para tomas de decisión
  • Reuniones de Networking
  • Talleres facilitados
  • Coaching y mentoría
  • Capacitación específica

Estructura de informes presupuestarios

Probablemente la mayor preocupación cuando intenta comenzar a implementar Agile dentro de una PMO, a un nivel más alto que el de sólo proyectos individuales, son los informes y las métricas. Por lo general, familiarizarse con los nuevos principios, prácticas, métricas y las formas de comprender la salud y el estado de los proyectos, desde la perspectiva de la PMO, podría no ser nada fácil.

Los informes sobre el presupuesto y el control de costos suelen ser las estrellas favoritas para la mayoría de los interesados de las altas gerencias; una vez que implemente Agile en su PMO, ellos no podrán ver estas cifras exactamente de la misma manera que solían hacerlo, por supuesto, no significa que la información no esté disponible o que esté oculta, pero sí podrá tener una forma ligeramente diferente. Para generar confianza en su comité de interesados, debe tener métricas centradas en el punto de vista de la PMO, con una visión macro, no solo a nivel de proyecto único, sus métricas deben ser cuantificables y también por períodos (o sprints), precisas y completas, y deben comprender a todos sus proyectos, sin compararlos entre ellos. Un buen punto de partida probablemente incluirá métricas y reportes tales como:

  • Deadlines
  • Velocidad empresarial
  • Satisfacción del cliente y del equipo
  • Costo de la calidad
  • Trabajo en curso
  • Defectos escapados al control de calidad, encontrados en producción
  • Duración promedio del tiempo de ejecución y ciclo en la producción

Si tiene más preguntas sobre estos temas, por favor no dude en contactarme.

SUSCRIBIRSE SI NO ES MIEMBRO

captcha 

ef logo hrz fc rgb

Socios del Capítulo

Socios 347
New Members This Year 81
Socios PMP® 225
Socios CAPM® 3
Socios PgMP® 2
Socios PMI-RMP® 1
Socios PMI-ACP® 4
Socios PfMP® 0
Socios PMI-PBA® 1
Members with no Certification 116
Breakdown by type  
Individual Members 308
Student Members 37
Other Members 2
PMP/CAPM/PgMP/PMI-SP/PMI-RMP/PMI-ACP/PfMP/PMI-PBA are registered marks of the Project Management Institute, Inc.