Agile Coaching. Autor: Norberto Figuerola

Transcripción

1 Agile Coaching Autor: Norberto Figuerola Si un equipo verdaderamente ágil es auto-organizado y selecciona su propio trabajo de la lista priorizada de características o backlog, que le cabe al Gerente de Proyecto? En lugar de temer perder su prestigio el Gerente de Proyectos debería maximizar la entrega de valor de negocio del proyecto y buscar ampliar su conjunto de habilidades con más y mejores prácticas de liderazgo y estudiar un poco más. La transición a la agilidad no sucede de un día para otro. Existe un largo y prolongado período de transición que a veces resulta difícil, hasta que todos los interesados en el proyecto adopten una mayor colaboración y estén familiarizados con un nuevo enfoque de trabajo. Algunas personas realizan dicha transición más rápido que otras y con frecuencia muchas otras tienden a continuar con algunas actividades de PM tradicionales. En mi humilde opinión, creo que resulta mucho más fácil entender el mecanismo ágil si el profesional ya tiene experiencia en manejo de proyectos tradicionales. Además una formación certificada y profesional en la disciplina de Project Management le da mayor apertura de conocimientos a la hora de aplicar técnicas y métodos ágiles. De hecho uno de nuestros nuevos cursos está orientado a aprender las técnicas y el coaching ágil con el requisito de haber participado en algún curso anterior de gestión de proyectos o conocimiento del PMBOK. Dicho curso explora las características fundamentales de los

2 procesos ágiles tal cual lo exige la certificación PMI-ACP, con foco en Scrum, Kanban y Lean. Volviendo al tema del rol del Gerente de Proyectos en Agile y con referencia al liderazgo, la característica ágil respecto del Servant Leadership no fue un descubrimiento de los líderes ágiles. La gestión de proyectos moderna y los tipos de liderazgo apuntan a que los equipos de trabajo son más efectivos (sobre todo cuando hablamos de desarrollo de software) en ambientes participativos, colaborativos y cooperativos. Los equipos ágiles encuentran que los estilos de gestión que favorezcan estos enfoques (liderazgo con énfasis en el logro de cosas a través de la colaboración y la visión compartida) funcionan mucho mejor. Cuando la obra del líder se hace, la gente dice: Lo hicimos nosotros mismos. - Lao-Tzu (604 ac) Los gerentes de proyecto que trabajan en proyectos ágiles saben que necesitan dar un paso atrás y dejar que el equipo organice su propio trabajo, resuelva sus problemas y tome decisiones por sí mismos. Esto puede ser difícil de hacer dada la tentación de "ayudar", y pensar en organizar y dirigir a las personas para lograr los objetivos del proyecto. Sin embargo, para los métodos ágiles, esto no es ayuda en absoluto. Cuando el equipo tiene la autoridad para tomar decisiones locales mejora en la autoestima, la responsabilidad y la productividad, creando además un entorno más gratificante de trabajo. Podríamos enumerar cuatro grandes funciones que todo Gerente de Proyecto debería practicar cuando gestiona proyectos ágiles: Rol Agile PM 1: Eliminación de obstáculos Desde una perspectiva lean, es el equipo de desarrollo el que genera valor para el negocio, y por lo tanto un papel fundamental para el PM es maximizar la entrega de valor mediante la eliminación de los obstáculos en su progreso. Esto significa que el Gerente de Proyecto debería participar en la solución de problemas y la eliminación de los obstáculos que pueden estar impidiendo el progreso del equipo de trabajo. En la reunión de stand-up diario donde el equipo informa de los avances, los trabajos previstos, y los problemas u obstáculos, el Gerente de Proyecto debe tomar nota de los mismos y hacer que se resuelvan lo antes posible. Algunas herramientas de PM ágiles ahora soportan los backlogs de impedimentos, una especie de lista priorizada de obstáculos para Scrum Masters y Gerentes de Proyecto, a los efectos de realizar seguimiento del trabajo de eliminación de trabas. Rol Agile PM 2 : Actuar como Escudo Como el nombre lo sugiere, el papel protector del escudo implica proteger al equipo de las solicitudes fuera de tema y el trabajo excesivo que desvía el cumplimiento de los objetivos de la iteración actual y en general de la entrega de valor de negocio. El esquema de tipo ágil al trabajar más de cerca con el cliente o personal del negocio, hace que resulte más

3 tentador hacer peticiones laterales para cambios o mejoras directamente a los desarrolladores. Si bien los proyectos ágiles fomentan positivamente estas ideas de negocio y solicitudes, el canal adecuado es a través de la reunión de planificación de la iteración o las solicitudes del Product Owner. El Gerente de Proyectos tiene que recordar a la gente que las solicitudes deben ir a través de los canales para que se pueda mantener el enfoque en la iteración y establecer una velocidad fiable para ayudar a planificar el trabajo futuro. Además de las distracciones internas, el PM debe proteger especialmente contra los desvíos externos. La ubicación física de los miembros del equipo (co-localización) es una forma eficaz de prevenir interferencias externas. Sin embargo, si una o dos personas aún se encuentran en sus antiguos departamentos o espacios de trabajo, resultará más fácil que pueden ser extraídos temporalmente fuera del proyecto. En el vocabulario de lean, las actividades que no contribuyen directamente a la entrega de valor de negocio se llaman work compliance e incluyen reuniones fuera del proyecto y otras tareas de administración. La reducción al mínimo de estas actividades, ya sea mediante contratación de personal para hacerlas o mediante la eliminación de su necesidad, es un aspecto importante de la maximización de la eficacia del equipo. Hacer algo "porque sí" no es una razón válida. Rol PM Agile 3 : Comunicar la visión del proyecto Una de las funciones más críticas del Gerente de Proyecto es comunicar y re-comunicar la visión del proyecto. Mediante la creación de una imagen clara del sistema y el proyecto finalizado, los interesados pueden comprobar y alinear sus decisiones y trabajar hacia el objetivo común. "Los líderes tienen que revelar dónde está la cumbre haciendo señas, para que los otros pueden trazar su propio camino." En pocas palabras, una visión común ayuda a mantener a las personas que empujen en la misma dirección. Si bien esto puede parecer obvio, también es muy común en métodos ágiles que se desarrollen y promuevan los puntos de vista divergentes entre los miembros del equipo bien intencionados. Ciertos deseos de simplicidad de los desarrolladores o aplicar nueva tecnología pueden divergir de la necesidad de los usuarios. Analista de control de calidad con deseos de exhaustividad y conformidad pueden diferir del Gerente de Proyecto y los requisitos de los patrocinadores para el progreso y su finalización. Un rasgo característico de líderes de nivel 5 (más efectivos) es dedicar un porcentaje mucho mayor de su tiempo de trabajo para la comunicación y la re-comunicación del proyecto y visión corporativa. El ejercicio de visión no sólo se efectúa durante el inicio del proyecto, sino que se desarrolla en cada iteración, de forma continua buscando oportunidades para comunicar el proyecto, visión y nuevas formas de ilustrar y reforzar esa visión.

4 Rol PM Agile 4 : Realizar retro alimentación y proveer Recursos Como Gerentes de Proyectos necesitamos proporcionar recursos en forma de herramientas, compensaciones y estímulo para mantener al equipo nutrido y productivo. La gente no trabaja en forma productiva simplemente animada por su capacidad, profesionalidad y responsabilidad. Tenemos que aprender lo que motiva a los miembros del equipo como individuos y encontrar la manera de recompensarlos por su buen trabajo y celebrando también las pequeñas victorias a medida que avanzamos. Otro ejemplo de este tipo de apoyo incluye la formación y desarrollo profesional. Con el cultivo de nuevas habilidades, los miembros del equipo no sólo obtienen los beneficios de un nuevo conocimiento, también demostramos nuestro interés por ellos. Finalmente proporcionar al equipo de trabajo con las herramientas técnicas y tecnológicas mínimas e indispensables que aseguren calidad en su trabajo y permitan impulsar cualquier método práctico apropiado conforme a la metodología (ejemplo: herramientas IDE, herramientas de testeo, herramientas de integración continua, etc.). Como se vió los Gerentes de Proyecto deben eliminar los impedimentos, proveer los recursos, comunicar la visión del proyecto, actuar como un escudo y una multitud de otras tareas valiosas, tales como, entender las necesidades del equipo, crear un ambiente propicio, manejar el aspecto ético, lidiar con proveedores y top management, proponer mejoras en los procesos, explicar la metodología a aplicar e intervenir en caso de problemas cuando sea necesario. Esta última frase significa saber cuando intervenir en un problema, para trabajar en forma más directa con el equipo, esto es, si se encuentra un problema importante o inminente. Por ejemplo, si la velocidad de la entrega promedio, está siguiendo un patrón mucho más lento del esperado durante un número prolongado de iteraciones, entonces algo está sucediendo y se requiere la intervención. Inicialmente existe una delgada diferencia entre intervenir como se expuso anteriormente e interferir, que es lo que NO debe hacer un Gerente de Proyecto. Como podemos saber si realmente estamos interviniendo en el momento apropiado, o solamente estamos interfiriendo el normal comportamiento del equipo? Existe un concepto útil para ayudar a los administradores de proyectos a tomar la decisión correcta en el momento de dar un paso atrás o el momento de intervenir. Estos conceptos son los mismos que vemos en los cursos cuando hablamos de Calidad y se refieren a las famosas variaciones que exponía Edwards Deming en su Teoría del Conocimiento Profundo respecto de las variaciones que ocurren en un proceso. Deming divide las variaciones como producto de causas comunes o causas especiales. Si se tiene en cuenta que en varias ocasiones estamos golpeando un clavo, nunca se golpea exactamente de la misma manera, es decir, existen algunas variaciones. A veces se puede golpear exactamente y otras, puede ser un poco de lado, con lo que el clavo

5 quedará inclinado, esto es variación provocada por una causa común. Sin embargo, si nos rompemos el brazo e intentamos golpear el clavo con el brazo enyesado, o si nos apagan las luces en el lugar donde estamos martillando, la varianza de los golpes mal efectuados tienen ahora una causa especial, provocada por estos factores externos. El punto es que el Gerente de Proyecto debe aceptar la variación de causa común, pero intervenir en la variación por causa especial. Cosa que puede también ser parafraseada diciendo: evitar la microgestión y en su lugar trabajar en la eliminación de los cuellos de botella y obstáculos. Así que centrar mucho esfuerzo en el seguimiento de la conformidad con un plan rígido no es el mejor uso de la gestión del tiempo. En cambio, mirar el exterior y asistir a la reunión de stand-up diario cuando el equipo reporta algún problema, impedimentos o bloqueadores a su trabajo, eso si pueden ser triggers de causas de variaciones que necesitan ser resueltos. Deming decía que sólo hay dos tipos de error que un jefe de proyecto puede hacer : 1. Interferir con el trabajo que está variando dentro de sus causas comunes (microgestión), 2. No intervenir cuando se detecta una variación de causa especial, esto es falta de apoyo y servicio, dado que el Gerente de Proyectos debe ayudar a solucionar estos problemas externos Así que la próxima vez que se trata de determinar si se debe o no intervenir, trate de clasificar a la cuestión como variación de causa común o como variación de causa especial. Si el tema es realmente de causa común, entonces debería resistir la tentación de inmiscuirse y reservar su energía para aquellas cuestiones especiales de variación.