¿Debería mantenerse el rol de Project Manager en un proyecto ágil? ¿Sí? ¿No? Este es un tema al que últimamente le he estado dando muchas vueltas, y es otra de las dudas durante la transición de proyectos tradicionales a proyectos ágiles.
Si nos fijamos en Scrum, expertos sobre el tema como Mike Cohn o Ken Schwaber han llegado a comentar que el rol de Project Manager en los proyectos software mata la creatividad y es contraproducente.
Su visión es que las responsabilidades de este rol deben estar repartidas y no concentradas en una única persona.
Repartiendo las responsabilidades de Project Manager en el equipo Scrum
Así típicamente en el caso de Scrum solo hay 3 roles diferenciados, que se reparten responsabilidades del Project Manager (ojo, esto quiere decir que ninguno de estos roles es puramente Project Manager, cada uno hace una parte de lo que debería hacer un Manager):
– El Scrum Master: Se queda con la responsabilidad de un buen proceso, en este caso de Scrum. Es un experto en el proceso de Scrum, y su función es que todo el mundo lo entienda, lo aplique bien y solucionar impedimentos.
– El Product Owner: La gestión del producto, ámbito del proyecto, posibles fechas, priorización del valor para el cliente, etc. va a cargo del Product Owner.
– El equipo: Es autoorganizado y multifuncional, no necesita management porque se autogestiona.
Por otra parte, la calidad del producto es responsabilidad de todos los roles, dentro de sus respectivos ámbitos.
Debido a esto muchos Project Managers en la transición a un proyecto Scrum suelen cambiar de puesto hacia el rol de Scrum Master o Product Owner.
Pero…En este esquema de roles y responsabilidades me falta algo. Ya lo comenté la semana pasada en ¿Cómo deberían ser los líderes ágiles?: desde mi experiencia, no podemos asumir que toda la gente puede adoptar una actitud de auto-organización automáticamente. No todo el mundo está acostumbrado, ni tiene las cualidades necesarias para ello. Y he vivido los dos casos, por un lado el de equipos que automáticamente se auto-organizan porque la gente tiene los valores y actitud necesarias para ello y el de equipos que se pierden solos, ya que no están acostumbrados.
Personalmente no creo que esto sea algo malo. Todos somos personas, diferentes y nadie es perfecto. Si lo fuéramos, ningún proyecto de ninguna industria fallaría, no necesitaríamos procesos, ni metodologías de desarrollo, ni cascada ni agilidad ni nada, todo siempre saldría bien.
¿Qué responsabilidades típicas de Project Manager no se tienen en cuenta en esa división de roles?
Para mí el trabajo en equipo es muy complejo, porque somos personas diferentes, pensamos diferente y tenemos objetivos diferentes. Y esto a la par que dificultad, le aporta creatividad al tema del trabajo en equipo, ya que podemos obtener productos sorprendentes por la combinación de distintas perspectivas.
Pero la realidad es que aunque cada equipo sea un mundo, en muchas empresas los objetivos de negocio son los que hay, únicos y hay que cumplirlos.
Así que aquí hay varios aspectos a tratar en los proyectos que no hemos tenido en cuenta en los 3 roles de Scrum:
– Todo el equipo tiene que estar alineado con los objetivos del proyecto y en la forma de trabajo.
– Todos tenemos que dar lo mejor de nosotros mismos. Si uno lo da todo y el resto no, surgirán problemas.
– Lo ideal es que estemos centrados y motivados para hacer el proyecto lo mejor posible.
Por otra parte creo que siempre hay cambios. Pueden ser tangibles para el proyecto, como cambios en los requisitos, que la tecnología se quede obsoleta y haya que cambiarla, en el negocio, etc. o intangibles, como cambios en nuestros objetivos personales, en lo que queremos en la vida, en nuestra experiencia, habilidades, compromiso, etc.
Normalmente solo vemos los cambios tangibles (a veces demasiado tarde, cuando no hay más remedio y los gestionamos tarde y mal), pero los cambios intangibles también afectan mucho a los proyectos.
Por ello, se añaden más cosas a la lista:
– Lo ideal es que pase lo que pase, hay que intentar que la gente siga comprometida y motivada con el proyecto. Habrá gente que se motive promocionando dentro de la empresa, con más dinero, aprendiendo, creando productos nuevos, innovando, cambiando de rol, etc.
– Hay que detectar esas necesidades y gestionar esos cambios, esto no se soluciona solo.
– Hay que evolucionar las planificaciones del proyecto, saber los riesgos, el impacto y tener ciertos planes de actuación en consecuencia.
– Como todo se mueve tan rápido, todo el mundo tiene que estar coordinado, tiene que fluir la comunicación, etc.
Cuando digo todo el mundo, me refiero a todos los roles, todos los equipos, equipos de desarrollo y comerciales, etc.
Además, para trabajar en equipo necesitamos comunicarnos, e inevitablemente, la comunicación puede llegar a causar conflictos. Para mí saber comunicarse bien es un arte. No ofender a nadie, saber llegar a la audiencia, que todo el mundo lo entienda, etc. es muy complicado, y no es una habilidad que todo el mundo tenga. Sin intención de ofender a nadie, creo que en España no nos caracterizamos por ser buenos comunicadores por defecto, ya que no estamos acostumbrados: ni desde pequeños en las escuelas, ni en la universidad, ni nada. Solo hay que ver ciertas presentaciones (en las propias empresas, congresos, etc.) para darse cuenta de ello.
Y esto es un problema más arraigado en muchos perfiles técnicos. Normalmente solemos aislarlos en aprender nuevas tecnologías, etc. pero no le damos importancia a estas habilidades interpersonales. Muchas veces no les damos importancia porque no nos gustan, tenemos miedo a hablar en público, o en la comunicación del día a día no somos conscientes de que el resto de personas no son informáticas y no nos entienden cuando hablamos de nuestras cosas. Aunque intento evitarlo, a mí esto me pasa, y lo veo continuamente en más gente.
Por último, en las empresas los procesos de desarrollo software no suelen estar bien implementados, y aunque lo estén, nunca llegan a ser perfectos, con lo que:
– ¿Realmente la gente tiene impedimentos y bloqueos, o toma como excusa un mal proceso para no hacer nada?
– ¿La gente realmente sigue el proceso? ¿Le parece útil? ¿Podría mejorarlo?
– ¿Alguien tiene todo el conocimiento y no quiere transmitirlo por alguna razón o no tiene tiempo para ello?
¡Me falta alguien que gestione personas!
De una manera o de otra, todos estos puntos que he ido marcando en negrita se repiten tanto en empresas tecnológicas como las que no lo son, en todos los proyectos, en todas las empresas. Todo por el simple hecho de que trabajamos en equipo muchas personas y con perfiles diferentes.
Creo que en un mundo ideal y perfecto, en organizaciones maduras, todo esto fluiría solo. Todo el equipo tecnológico se auto-organizaría para lograr el objetivo, para estar motivado, centrado, ser proactivo, etc.
Pero como todos los seres humanos son diferentes, y únicos, creo que no todo el mundo es capaz de estar dentro de un equipo auto-organizado. Aceptémoslo, no todo el mundo cuadra con los valores de la agilidad desde el principio.
Habrá gente proactiva, otra que no, gente que no es capaz de centrarse, gente desalineada con los objetivos de negocio, gente que no sepa comunicarse bien, gente engreída, gente que genera conflictos…
Algunas de estas personas con un poco de ayuda podrán conseguir ser auto-organizados, pero para otros habrá que optar por otra estrategia. Y eso no significa que sean malos, incluso algunos que no entran en la definición de auto-organizados pueden ser grandes contribuidores para el proyecto, gestionándolos de forma diferente y personalizada. Por ejemplo sé que en Google admiten genios técnicos aunque sean antisociales y no quieran trabajar en equipo, pero gestionan esos temas de una manera distinta.
Este trato de personas, de peculiaridades, de todos los aspectos que he ido poniendo con guiones a lo largo del post, no lo veo reflejado en las funciones típicas del Product Owner, ni del Scrum Master (aunque este sí gestiona impedimentos y mejoras del proceso de Scrum).
En los proyectos más tradicionales todos estos aspectos los solía gestionar un buen Project Manager. En agilidad esto los suele llevar un Agile Coach, pero también podría hacerlo un Project Manager, un Scrum Master…Realmente, me da igual quién lo haga. Me da igual el título que se le quiera poner. Pero creo que la gestión de personas es algo imprescindible dentro de cada equipo, y alguien específicamente debería dedicarse a ello.
Todo con autoridad, tacto, pero sin imponer las cosas. No hay ciencia para esto. Tratar con gente es un reto, y este rol no será capaz de solucionar todos los problemas del equipo, pero sí mitigar unos cuantos.
¿Qué opináis?
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Hola!
Creo que la «gestión de personas» es una de las partes más difusas de los contextos ágiles. Incluso en el caso de que el equipo conozca la manera de trabajar y tenga experiencia siempre es bueno que haya alguien que pueda «Dirigir» fuera del ámbito técnico, ser árbitro en conflictos, reforzar el equipo, asumir la responsabilidad y el coste de decisiones corporativas… etc.
Mi opinión es que, en el desarrollo de software, a medida que pasa el tiempo, se hace cada vez más importante factores humanos que técnicos. Originalmente era una tarea más de «Cowboy Coder». Ahora uno de los pilares es la integración en equipos de trabajo. Para ello creo que hay un valor esencial, «la empatía». Debemos reforzar los lazos de grupo, para ello debemos «ponernos en la piel de otro» con más frecuencia.
Salu2.
Si decimos que SCRUM es Agil, estaría muy de acuerdo, existen otros métodos ágiles como Kanban, donde la figura del Líder Agil tiene un espacio importante, por su naturaleza, sin embargo debe reconocer que SCRUM es un método Agil con la mayor relevancia en el mercado.
Hay que considerar que SCRUM no es Agil, SCRUM es un metodo de Agil y en ese sentido podemos considerar que el Lider de Proyecto/Project Manager tiene un rol relevante en la empresa, ademas si bien es cierto los equipos son auto-organizados debemos recordar que deben ser dirigidos y en ese sentido la figura del Lider de Proyecto emerge naturalmente. Espero contribuir con mi opinion al desarrollo de la comunidad Agil, sigan escribiendo que estaremos atentos para aportar valor a este nueva manera pensar que da valor a nuestra empresa o emprendimiento
Hola,
Bajo mi punto de vista las palabras project Manager se han quedado obsoletas dentro de un equipo Agile. Para ser más correctos, deberíamos llamarle Aguile Project Manager.
¿Por qué Agile Project Manager? Porque el propio APM debe ScrumMaster y ser el que haga el seguimiento e inculque al equipo el uso y seguimiento de metodologías ágiles ya sean Scrum, Kanban, o una pseudo-mezcla entre varios según las necesaides de los equipos.
Por otro lado, un equipo debe ser auto-gestionado en el sentido que el propio equipo debe estimar el esfuerzo de las tareas a realizar, y cómo y cuales van a desarrollar. Dichas tareas deben venir creadas y priorizadas por un PO (project owner) pero deben estar gestionadas por un APM que haga de punto de conexión entre el PO y el equipo. de manera que sean cuales sean las necesidades del equipo, el APM es el canal de comunicación para solventarlas.
Otro concepto que me viene a la cabeza leyendo vuestros post sobre líder, empatía, jefe, etc; es el de holacracia-holocracia; no se si es algo que habéis barajado como forma de gestión.
Como ya han comentado, el nombre del post no se adecua al contenido. Debería ser ¿Tienen cabida los project managers en los proyectos Scrum?
Mi opinión es que si entendemos el JdP como un rol entonces por supuesto, más aún si tenemos en cuenta que como casi nadie hace un Scrum puro, porque deberiamos ser puros en esto?
En un equipo pequeño una misma persona puede hacer de JdP y desarrollador perfectamente.