"Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum."

Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro "Succeeding with Agile: Software Development Using Scrum" de Mike Cohn. Hoy publico solo la sección de "Gerentes de Proyecto" como parte de la serie "Roles ágiles".

Gerentes de Proyecto

En un proyecto con un proceso de desarrollo secuencial, el gerente del proyecto tiene la difícil tarea de asegurar que el producto que desea un cliente es el que se desarrolla. Para ello, el gerente del proyecto debe tratar de manejar todo lo relacionado con el alcance, costo, calidad, personal, comunicación, riesgo, adquisiciones, etc. Algunas de estas responsabilidades en realidad pertenecen a otros. El control del Alcance, por ejemplo, por derecho le pertenece al cliente. This article is a Spanish direct translation of the "Project Managers" section from the InfoQ Article named "Book Excerpt: Succeeding with Agile: Software Development Using Scrum", which is about Mike Cohn's book "Succeeding with Agile: Software Development Using Scrum".

You can access the Spanish version of this article following this link.

Since the original article is written in English, I see no need to translate it. Please visit the original article here: http://www.infoq.com/articles/cohn-chapter8

Nadie más está en mejor posición para realizar los cambios necesarios a raíz de las decisiones que se producirán durante el desarrollo de productos, como prioridades, la velocidad del equipo, y las condiciones del mercado. La determinación de prioridades no es una actividad estática, por una sola vez, hecha al comienzo que pueda ser administrada por un gerente del proyecto. Sin embargo, una y otra vez, los proyectos secuenciales exigen que los gerentes de proyectos realicen conjeturas para entregar el producto correcto.


En los proyectos Scrum, reconocemos el papel insostenible del gerente del proyecto y lo eliminamos. La eliminación del rol, sin embargo, no significa que podamos deshacernos del trabajo y las responsabilidades. Como puedes imaginar, ya que los equipos auto-organizados son un principio central de Scrum, una gran parte de la responsabilidad previamente asumidas por el gerente del proyecto es transferido al equipo Scrum. Por ejemplo, sin un gerente de proyecto que asigne tareas a los individuos, los miembros del equipo asumirán la responsabilidad de la selección de las propias tareas. Otras responsabilidades se han movido  al ScrumMaster o Product Owner.


Ex gerentes de proyecto a menudo asumen una de las funciones que han tenido en algún momento de su pasado  -el gerente de proyecto se convierte en Product Owner o ScrumMaster o miembro del equipo, dependiendo de la experiencia, habilidades, conocimientos e intereses.


Algunas personas se convirtieron en gerentes de proyecto porque lo consideran el siguiente paso en una carrera deseable, sin embargo, no disfrutan de la gestión de proyectos. Estas personas se pierden el desafío técnico de trabajar como programador, tester, ingeniero de base de datos, diseñador, analista, arquitecto, etc. Muchas de estas personas se beneficiarán con la eliminación de la función de gerente de proyecto para volver al trabajo que encuentran más satisfactorio.


Otros gerentes de proyectos han utilizado sus funciones para llegar a conocer la empresa y sus clientes. Un gerente de proyecto en esta situación aprovechará ese conocimiento para adoptar un rol de Product Owner. Esto puede ser una coincidencia excelente, especialmente para aquel gerente de proyecto que tiene dificultades para abandonar por completo la capacidad de decir al equipo qué debe hacer. Como parte de su función, los Product Owners están autorizados a decir al equipo acerca de "qué hacer" siempre y cuando eviten decirles “cómo hacerlo”. Esto puede satisfacer a un ex gerente de proyecto cuya naturaleza haga que le cueste parar de dirigir al equipo.


Si un gerente de proyecto puede superar los viejos hábitos de dirigir el equipo y tomar decisiones por ellos, es probable que pueda convertirse en un buen ScrumMaster. Este es el nuevo rol que comúnmente adquieren los gerentes de proyectos en las organizaciones que adoptan Scrum. El nuevo rol probablemente será difícil al principio para el ex gerente de proyecto, mientras aprende a morderse la lengua y dejar que el equipo aprenda a resolver sus propios problemas y tomar sus propias decisiones. A menudo, los nuevos ScrumMasters son colocados en la posición desafiante de entrenar a los equipos en algo que todavía ellos mismos no son buenos, ser ágiles. Las mejores estrategias para un ScrumMaster en esta situación son las siguientes:

  • Limitarse lo máximo posible a seguir Scrum según el manual. Inicialmente seguir el consejo de este u otro libro de Scrum de cerca. O contratar a un entrenador y seguir sus consejos al pié de la letra. Sólo empezar a personalizar el proceso después de que haya experiencia real y práctica.
  • Hablar con otros ScrumMasters tanto como sea posible. Si hay ScrumMasters en su organización, formar una comunidad y compartir buenas y malas experiencias. Busque aprender de las lecciones aprendidas de situaciones comunes. Si usted es el único ScrumMaster en su organización, encuentre ScrumMasters fuera de la misma con quienes pueda compartir historias y comparar métodos.
  • Aprender tanto como pueda lo más rápido posible. Lea libros, artículos, blogs y sitios web. Mira en los grupos de interés locales y asista a sus reuniones. Trate de asistir a una o más conferencias principales de Agile o Scrum.

Doris Ford, una gerente de ingeniería de software en Motorola, es una gerente de proyectos de formación clásica y Project Management Professional (PMP). Sin embargo, a pesar de tener un trasfondo tradicional en la gestión de proyectos, el enfoque de Doris ha sido siempre el de apoyar y dar libertad a sus equipos. Debido a esto, ella fue capaz de pasar más fácilmente de gerente de proyectos a ScrumMaster. Ella escribe sobre cómo su trabajo ha cambiado con Scrum:

Durante los años en la gestión de desarrollo ágil he aprendido a no preocuparme por los detalles de las tareas. Como gerente de proyectos tradicional, siempre necesité estar al tanto de quién estaba haciendo qué, cuáles eran sus dependencias, y si se estaban haciendo a tiempo. Pasé innumerables horas haciendo estas preguntas para obtener las respuestas en un intento por satisfacer el alcance/cronograma/presupuesto/calidad y la presentación de informes sobre los progresos (a veces utilizando el método de valor ganado). En un entorno ágil tuve que aprender a confiar en los miembros del equipo en que iban a identificar y realizar las tareas necesarias para completar el alcance de cada sprint. Fue difícil al principio, pero rápidamente aprendí que el equipo podría hacerlo. Ahora paso la mayor parte de mi tiempo a asistiendo a los miembros del equipo abordando los obstáculos que aparecen y conteniendo el ruido externo para que no desvíe su atención.

¿Por qué cambia el título?


Si es posible que un gerente de proyectos pase a convertirse en ScrumMaster de un equipo o product owner, ¿por qué tenemos que cambiar el título de la persona? Vamos a considerar el término ScrumMaster. Hace años, cuando empecé a realizar proyectos Scrum, el término ScrumMaster no existía, y nunca se me ocurrió llamar al rol de otra forma que gerente del proyecto. Esto funcionó bastante bien. Pero, yo estaba a cargo de la contratación de nuevos individuos para estos roles, yo tenía claras mis expectativas sobre cómo debían interactuar con el equipo. Evité los individuos de estilos dominantes, de “command-and-control”. Además, estos nuevos gerentes de proyectos reportaban a mí, lo que me dió mucha influencia sobre la forma en que interactuaban con sus equipos. Llamarlos  gerentes de proyectos funcionó bien.


A medida que nuestra compañía continuaba teniendo éxito y crecimiento, comenzó a adquirir otras empresas. En esas empresas heredaría gerentes de proyectos que a veces tenía la mentalidad muy tradicional sobre el papel del gerente de proyectos. Me encontré ayudándoles a cambiar esa mentalidad, a una más compatible con el desarrollo ágil. He encontrado esto mucho más difícil que contratar gerentes de proyectos con un enfoque de colaboración adecuado a la auto-organización de los equipos.

Años más tarde, en un debate con Ken Schwaber, me ayudó a comprender por qué la transición de los gerentes de proyecto existentes había sido más difícil de lo previsto. Schwaber me informó que al permitir que los gerentes de proyecto retuvieran sus títulos,  les permitía pensar que los cambios eran menos de lo que realmente eran. Él inventó la palabra ScrumMaster en 1997, en parte para recordarles  a todos que este no era sólo el rol del gerente de proyectos con algunas responsabilidades menos o adicionales. Schwaber me dijo que "el vocabulario de Scrum es un vocabulario de cambio. Las palabras son a menudo deliberadamente feas: Burndown, backLog, ScrumMaster-porque nos recuerdan que el cambio se está produciendo".

Aunque lo recomiendo, no necesariamente tienen que desterrar el título de gerente de proyectos. Si usted o su organización están enamorados de él, siga utilizándolo. Sin embargo, sean conscientes del consejo de Ken Schwaber y de mi experiencia, el uso de las viejas palabras retardar o previenen la adopción del nuevo enfoque. El mantenimiento de un título anterior no motiva a pensar en la nueva forma. Además, si las personas no están dispuestas a renunciar a algo tan insignificante como un título de trabajo, es probable que tampoco estén dispuestos a realizar los cambios más difíciles y profundos al adoptar Scrum.


Dime lo que piensas. Por favor, deja un comentario más adelante (y luego dale click a ese botón de 'Me gusta'!)

Seguir leyendo


Comentarios

comments powered by Disqus