«¡Un backlog, un equipo, un Product Owner!»: esa es la forma correcta de organizarse. El Product Owner es un trabajo a tiempo completo: gestionar el backlog, orientar al equipo, responder a lo que otros piden…
En algunos casos, puede que un Product Owner llegue a compartir el mismo equipo de desarrollo con otros Product Owners. Puede deberse a la cultura de la empresa o a meras limitaciones organizativas. Este modo de funcionamiento es un modelo totalmente «anti-agile».
Si estás en ese punto, te explicamos la mejor forma de proceder.
Caso 1: un equipo, varios proyectos, varios Product Owners
Resulta que estás en un equipo formado por varios Product Owners, los cuales gestionan varios proyectos en paralelo; de hecho, se trata de un centro de servicios.
En este tipo de organización, el equipo de desarrollo corre el riesgo de tener que priorizar él mismo su backlog para cumplir sus compromisos con todas las partes.
Caso 2: un equipo, un proyecto, varios Product Owners
Esta situación se suele dar en un equipo demasiado grande para contar con un solo Product Owner. También puede ocurrir en el caso de que se requieran conocimientos empresariales muy específicos.
En tal caso, se deberá asignar un Product Owner para cada área de especialización. Este método de organización también tiene sus propios riesgos: dificultades para respaldar al equipo de desarrollo, la complejidad de la priorización y una alineación.
El equipo se convierte en un cuello de botella, y las consecuencias son bien conocidas: problemas de calidad, desgaste del personal, tensiones, etc. Por desgracia, las palancas del cambio organizativo rara vez están en manos de los Product Owners o del equipo de desarrollo, así que tenemos que lidiar con ello. ¿Cómo se afronta una situación así?
Profundiza en este tema: descarga nuestro libro Las Claves del Product Management
La solución: poner en marcha un Kanban Ready
Sin tener que revolucionar tu forma de trabajar, una solución es razonar y hacer visible la situación actual para concienciar y conseguir mejoras. Si tu caso es el de un centro de servicios, tenlo en cuenta.
Tu equipo de desarrollo tiene una capacidad de trabajo y no es escalable. A menudo, cada Product Owner tiene su propio roadmap, sus plazos y sus compromisos, algo que puede convertirse rápidamente en un problema.
¿Cómo consigue el equipo de desarrollo establecer una prioridad indiscutible entre los elementos de trabajo? ¿Por dónde debería empezar?
En el caso de un centro de servicios, hay que considerar al equipo como un sistema y pensar en flujos o procesos. En resumen: adoptar una lógica Kanban.
Tanto si te encuentras en uno como en otro de los dos casos descritos anteriormente, la columna de gestión visual de la que se nutre el equipo de desarrollo debe ser única y debe priorizarse debidamente a través del trabajo de todos los Product Owners implicados.
Esto significa que la etapa final del trabajo de los Product Owners consiste en una etapa de coordinación para decidir las prioridades de desarrollo. Estas prioridades se detallan en la columna Ready to dev del Kanban.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Product Managers: ¡cread un Kanban Ready!
Además de la coordinación en las prioridades de desarrollo, este Kanban Ready tiene dos grandes virtudes:
- Los elementos de trabajo para el equipo de desarrollo guardan una coherencia entre sí.
- El equipo de desarrollo tiene una visión completa de la actividad de los Product Owners y una visión general de lo que está por venir.
En el diagrama anterior, cada Product Owner muestra su actividad en una pista del Kanban global.
Una vez que hay un número suficiente de historias de usuario que están maduras para él y sus compañeros, se puede proponer una sesión de presentación de historias de usuario al equipo, para colaborar entre los Product Owners y determinar la priorización correcta e inequívoca de las historias de usuario para enviar a desarrollo. Los Product Owners deben estar de acuerdo con esto.
También es una forma de adoptar un enfoque «justo a tiempo» para que las historias de usuario maduren: el equipo de desarrollo tiene una capacidad fija, un volumen máximo.
Este volumen debe tenerse en cuenta hasta en la forma de expresar los requisitos, la planificación de grupos de trabajo empresariales, la posible participación de equipos de pruebas, etc.
El uso de límites en las actividades de tu sistema permitirá que un flujo propulse a otro. Por lo tanto, el trabajo de los Product Owners se ajustará a la capacidad de absorción de los desarrolladores.
Así es: ¿por qué escribir, discutir, estimar, en definitiva, perder el tiempo en historias de usuario que el equipo no tiene la capacidad de absorber?
Los Product Owners que están «técnicamente desempleados» serán más útiles para ayudar al equipo a probar lo que se ha empezado o ayudar a otros Product Owners para terminar de escribir las historias de usuario más importantes. Esto se llama «enjambre».
Según el contexto y la cultura de la empresa en la que estés, un equipo de Product Owners puede utilizar este enfoque para coordinarse respecto a las prioridades y conseguir esa famosa columna única priorizada: Ready to dev o «Listo para desarrollo». A veces, se llega a un consenso con relativa facilidad.
Por desgracia, a veces tenemos que priorizar y, por tanto, cuantificar el interés de una historia de usuario respecto a otra. En este caso, no basta con manipular el valor del trabajo, que a menudo se malinterpreta o se utiliza de forma incorrecta.
Un buen enfoque es entonces utilizar una forma mínima de coste de retraso. ¿Cuánto ganaría o me ahorraría una historia de usuario si se entregara?
En general, se utilizan cuatro categorías para clasificar los elementos de trabajo:
- Urgencia: una historia de usuario que hace ganar o ahorrar dinero a la empresa de forma inmediata; cada día que pasa es, por tanto, una pérdida de ingresos.
- Fecha fija: una historia de usuario que debe entregarse en una fecha determinada, normalmente una obligación legal. Más allá de esta fecha, cada día que pasa se corre el riesgo de perder una cantidad importante de dinero (por ejemplo, por una multa).
- Estándar: una historia de usuario clásica que tiene un valor de negocio, cada día que pasa te aleja de una ganancia potencial.
- Intangibles: normalmente la deuda técnica, los intangibles no cuestan casi nada hasta que es demasiado tarde, la buena práctica es gestionar los intangibles todo el tiempo, poco a poco.
Esta técnica de priorización es una forma sencilla de cuestionar el valor de los elementos de trabajo, especialmente en el caso de líneas de productos o proyectos aparentemente "incomparables".
En todos los casos, debe prevalecer el espíritu ágil: la resolución de problemas relacionados con este modo de proceder se ve muy facilitada por un fuerte espíritu de equipo y una visión compartida.
La implementación de un Kanban Ready hará visible el problema, pero nunca sustituirá el intercambio entre los Product Owners. Es esencial un estricto ritual de priorización con un ritmo regular.
La creación de una comunidad de práctica de los Product Owners facilitará la coordinación, la transparencia y reforzará el espíritu de equipo.
Foto de fauxels en Pexels
Para aprender más: descarga nuestro libro Las Claves del Product Management
