Empezar a trabajar en Agile, como con todo nuevo modelo, requiere un tiempo de adaptación a los cambios que provoca. Aparte de los culturales, de la forma de trabajo, y del ritmo que exige, ya comentados, tenemos muchos cambios en los roles de Agile respecto a Waterfall, y no sólo en el nombre.
Empecemos por el que me toca más de cerca el Product Owner. El principal cambio para el P.O. es que ahora está mucho más cerca de los equipos de desarrollo. Tenemos 2 tipos de P.O.:
- El P.O. antes conocido como el Informático
- El P.O. Usuario
El primero en algún momento de su carrera profesional ha formado parte de equipos de desarrollo de software, en todos o en alguno de los roles. Y le encanta meterse al barro, diciendo al equipo Scrum que solución técnica debe construir. Por que claro, como buen informático que se precie de serlo tiene un máxima: el resto no tiene ni idea y mi solución siempre es la buena. Suele terminar "dialogando amistosamente" con el equipo Scrum, hasta que por fin se da cuenta que su responsabilidad es otra, definir el producto, y no cómo construir el producto.
Otra adaptación que debe sufrir este P.O. exinformático, es que en el Backlog haya User Story que de verdad aporten valor al producto final, y no funcionalidades o requerimientos que se adapten a la solución técnica.
El segundo es un P.O. que desde el mundo de los informáticos se ve como una persona que sabe encender el ordenador, mover el ratón, y manejar el Office (sobre todo el powerpoint), es decir, un USUARIO. En realidad, es una persona que ha estado siempre en departamentos de Negocio, y que sabe de eso, del negocio y las necesidades de la empresa. Este pobre se encontrará con el problema contrario.
De repente una serie de personas (freaks en su cabeza) empiezan a pronunciar palabras hasta ahora desconocidas para él: js, java script, properties, JCL, junction, servidor apache, json, COBOL, ... Su mayor reto será conseguir que los informáticos (que huelen el asombro) no le toreen, le lleven a su terreno, y termine como el anterior P.O. escribiendo en el Backlog funcionalidades y requerimientos en lugar de user story.
Además deberá conseguir explicar a los informáticos el producto que quiere entregar a su stakeholder, sin utilizar la jerga propia de los desarrolladores. Alguno ha decidido que le costaba menos aprender Klingon...
Ambos tendrán también problemas comunes. Mantener el Backlog como ellos quieren sin que nadie "meta mano", evitar interferencias de terceros a todos los niveles, controlar las expectativas, el tener que estar negociando constantemente con todos: equipo scrum, stakeholder, terceros, Scrum Master, la señora de la limpieza para que no tire los post-it (este lo comparte con el SM)...
Y sobre todo adaptarse al Poder. "Un gran poder conlleva una gran responsabilidad" (Tio Ben, Spiderman) El P.O. tarda en darse cuenta de la cantidad de "poder" que acumula su rol. La responsabilidad compartida, el cooperar para un objetivo común, y todo lo que ya he comentado en entradas anteriores, están muy bien y realmente son necesarias.
La realidad es que sobre los hombros de P.O. está la mayor responsabilidad del éxito o fracaso de un proyecto en Agile, debido a la gran cantidad de decisiones que debe tomar el P.O. y que afectan a todos los aspectos del producto. Desde la negociación con los stakeholder para ver la prioridad de sus necesidades, hasta la exigencia o laxitud en el contenido de los sprint, pasando por el refinamiento de las epics y user story. Todo, excepto la construcción, gira en torno a las decisiones que tome el P.O. Y eso algo para lo que no todo el mundo está preparado, o acostumbrado.
Para los Desarrolladores, aparte de la autogestión, el mayor cambio son los tiempos. Ahora tienen que hacer todo lo que antes podían "ir haciendo" en un Sprint de 2 semanas. Bueno, y que el Usuario ese que viene todos los días se entere de algo.
Y por último el Scrum Master. Reconozco que aún no me queda muy claro el peso del SM en los proyectos Agile. Y ese es precisamente su mayor reto, que ellos tampoco lo tienen claro.
La mayoría viene de ser Jefe de Proyecto en Waterfall, que más o menos todos sabemos de que va. Ahora se le pide que sea un Facilitador:
Un facilitador es la persona que ayuda a un grupo a entender los objetivos comunes y contribuye a crear un plan para alcanzarlos sin tomar partido, utilizando herramientas que permitan al grupo alcanzar un consenso en los desacuerdos preexistentes o que surjan en el transcurso del mismo."Sin tomar partido"... "Alcanzar un consenso"... Claro, y un unicornio rosa... Dile a un Jefe de Proyecto que no puede organizar el trabajo del equipo, pedir tiempos, que en realidad no tiene capacidad de decisión, etc, etc, etc. Sinceramente es el rol que tiene una adaptación más dura, ya que pierde protagonismo. A veces parece que si el SM desaparece, nadie se va a dar cuenta hasta que pasen los días y huela a muerto.
