Equipo tradicional vs equipo ágil: Ser PO proxy

Por Cristina Ramos

Uno de los principales problemas que nos encontramos al momento de introducir un equipo ágil (externo o interno) en una empresa con metodologías tradicionales es la falta de un rol que represente “la voz” del cliente: el ProductOwner (PO). Este rol es indispensable para poder construir en tiempo y forma el producto más adecuado para el negocio.

Dado que este impedimento es un riesgo extra del proyecto, en este breve documento explicamos un rol llamado PO Proxy, que sustituye el rol inexistente del PO y permite mitigarlo.

¿Que es un ProductOwner?

En la mayoría de los proyectos ágiles de consultoría, el rol de ProductOwner(PO) es representado por el líder de proyecto del lado del cliente,que tiene como objetivo llevar adelante la construcción de un producto adecuado a las necesidades del negocio.

Las responsabilidades propias de un PO son:

• Decidir qué habrá de construirse y en qué orden (prioriza el backlog de trabajo)
• Definir las características del producto o los resultados esperados del proyecto desde la perspectiva del negocio
• Seleccionar las fechas de entrega y su contenido
• Asegurar el retorno de la inversión (ROI)
• Priorizar las características y resultados según el valor de mercado
• Ajustar las características y resultados según las necesidades
• Aceptar o rechazar los resultados del trabajo realizado
• Servir de facilitador en la reunión de planificación (ScrumPlanning)

Además, es imprescindible que el PO trabaje en estrecha colaboración con las partes interesadas, facilite la comunicación del equipo y los grupos de interés y se asegure de que el equipo esté construyendo el producto correcto.

¿Qué sucede si se presenta un equipo mixto: ágil y tradicional?

El líder de un equipo tradicional no siempre entiende y presenta las habilidades o características propias de un PO, pudiendo representar un impedimento extra en el proyecto. Si se presenta este caso en el equipo del cliente, será necesario que el equipo ágil cubra ese rol desde el inicio para una mejor integración de la metodología.

Luego del relevamiento realizado por un equipo ágil, interactuando con un cliente con metodología tradicional, se arribó a la conclusión de que era necesario elegir un PO proxy.Éste actuaría como “traductor” del líder del cliente, desde una perspectiva tradicional y la llevaría a una perspectiva ágil, permitiendo al equipo representar algunas funciones del PO, tales como priorizar el backlog de trabajo y los resultados esperados por el negocio en corto y mediano plazo, necesarias para poder avanzar con objetivos claros.

El rol de PO proxy fue cubierto por el analista funcional del equipo, quien al conocer del negocio y participar de todas las reuniones de equipo y con clientes, pudo tomar varias de las decisiones que corresponden al PO, con el fin de organizar la correcta construcción del producto.

¿Cuál fue el resultado de contar con un PO proxy?

Con el apoyo del equipo y en constante comunicación con los involucrados, el equipo ágil pudo llevar adelante el proyecto, con altibajos en varios momentos, debido precisamente a que no tenía la potestad de tomar ciertas decisiones concernientes al PO del cliente, y éste a su vez no tenía el apoyo interno suficiente como para lograr respuesta a consultas y realizar definiciones necesarias para el avance del desarrollo del producto.

Es un gran desafío participar de un proyecto donde el PO no puede tener claros ciertos aspectos que pueden cambiar el curso de lo que se espera del producto en ciertos momentos, y definir las prioridades de manera clara y objetiva, teniendo siempre como prioridad construir el producto adecuado para el negocio, dentro del contexto.

Conclusión:

Si una empresa es tradicional en su enfoque del desarrollo de proyectos, se hace difícil la integración del POa un equipo ágil. Los problemas comunes en este sentido son la pérdida de tiempo en cuestionar los procesos(sprints, dailys, etc), y el costo del tiempo en el aprendizaje y la adaptación para colaborar al desarrollo del producto dentro de la metodología ágil, lo que incluye: definir historias de usuario, criterios de aceptación, entender el armado de sprint, etc.

Por otro lado, también podría ser riesgoso que el PO sea alguien sin conocimiento del negocio o carezca de las habilidades blandas necesarias que le permitan ser un buen negociador y tener buena relación con todos los interesados.

Es recomendable capacitar a los futuros PO nacidos en metodologías tradicionales, especialmente para aquellos que tengan ganas de adquirir conocimientos sobre la metodología ágil y asuman la responsabilidad que eso conlleva.

Gracias a esta capacitación, el POpodrá obteneruna variedad de herramientas que le permitan colaborar para que tanto el equipo de desarrollo del producto como los dueños del producto obtengan lo deseado de la mejor manera y en el menor tiempo posible, aportando un valor agregado que conduzca al equipo al logro de un proyecto exitoso.

Referencias:

https://www.scrumalliance.org/why-scrum/core-scrum-values-roles

Imagen: Jogo da Comunicação no Workshop de desenvolvimento ágil por Improve it