La teoría nos dice que un Product Backlog está creado con las necesidades de un sólo producto, pero la realidad es que a veces nos encontramos con equipos que crean, mejoran y/o mantienen más de un producto. En este caso ¿cómo podemos ayudar al equipo a gestionar esta situación?
Trabajar con más de un producto no suele ser decisión del propio equipo, me arriesgaría a decir que nunca lo es, pero me podría equivocar 🙂 A veces, sin saber siquiera muy bien cómo, el equipo se ve envuelto en un torbellino de productos y prisas que nos llevan a tener tareas de todos ellos en el mismo Sprint, sin un Sprint Goal claro, y con futuros silos de conocimiento por que cada desarrollador trabaja en algo diferente. ¿Os suena? A mi me suena mucho, muchísimo… así que he probado algunas cosas que me gustaría compartir con vosotros para que las pudierais tener en cuenta y ver si os sirven.
Posibles orígenes de esta situación
Tal y como esté diseñada la organización
Un motivo por el que un equipo puede trabajar con diferentes productos puede ser la no adecuada priorización de un portfolio a alto nivel, que nos hace trabajar en varias cosas a la vez con el objetivo de sacar variedad de cosas, ya sea por probar muchas hipótesis, por cubrir temas legales, etc…
El tipo de producto en el que trabajemos
Otro motivo puede ser el trabajar con un producto tan grande que puede tener diferentes pequeñas iniciativas o mini productos que pueden ser desarrollados en paralelo (quizá para diferentes clientes si el producto se hace a medida). Además, tras crearlos, tienen un futuro mantenimiento, que junto a otras pequeñas iniciativas con las que el equipo puede innovar para aportar nuevas soluciones a necesidades del cliente, suelen hacer que a corto plazo acaben teniendo diversidad de pequeños objetivos.
Seguramente haya más motivos, pero dados estos dos ejemplos, ya os podéis imaginar que esto existe… Además la cosa se puede complicar, y no tener un sólo cliente sino varios, uno para cada producto.
La posible solución a trabajar con más de un producto
A continuación os explico dos posibilidades ante dos casos distintos para que podáis probarlas.
Cuando los clientes son diferentes para cada producto
- Reunid a los clientes y poned encima de la mesa todo lo que hay previsto hacer.
- Haced que ellos mismos expliquen cada una de las iniciativas y qué valor creen que eso puede aportar a la empresa.
- Seleccionad distintos criterios por los que ellos puedan evaluar cada una de las iniciativas, sean suyas o no. Nosotros elegimos los siguientes:
- Expansión del negocio
- Aumento de ventas
- Compliance Requests (afectación de la marca, legalidad…)
- Reducción de costes (coste operativo, eficiencia…)
- Añadid un peso a cada uno de los criterios en función de la estrategia que la compañía tenga en ese momento.
- Explicadles como evaluar, por ejemplo con puntos de historia, cada uno de los criterios para cada iniciativa
- Multiplicad cada valoración por su peso y sumadlo todo.
- Ordenad los valores de mayor a menor y tendréis priorizadas las iniciativas de distintos productos con los que trabajar.
El éxito de esta actividad dependerá del nivel de decisión que tengan los clientes en su producto. En nuestro caso funcionó bien en un inicio, pero con el tiempo, los clientes presentes en nuestras sesiones se veían presionados por sus responsables, que obviamente sólo miraban los resultados de su departamento, no de la empresa, eso hizo que dejaran de priorizar juntos para volver al método «quien se queje más fuerte irá antes». Pero tampoco podemos culparles por ello, recordemos que cuesta mucho adoptar una mentalidad agile a nivel de negocio (Business Agility) y se suele empezar la casa por el tejado, implementando la cultura sólo a nivel técnico.
Cuando tenemos a un único cliente para todos los productos
Parece raro que con un solo cliente tengamos problemas de priorización, pero puede haberlos si no tenemos un Objetivo (o Product Goal del producto) bien definido. Tenerlo os puede salvar de esta situación.
Un Product Goal es un objetivo a largo plazo que describe la visión del producto y lo que se espera lograr con él, éste establece la dirección general para el equipo y se enfoca en el valor que se entregará al cliente. (Scrum.org)
Para definir un Objetivo os recomiendo usar cualquiera de las plantillas que corren por internet con este objetivo. Lo importante en este caso son tres cosas:
- Definid bien, junto con los clientes, qué queremos conseguir. No queremos un output, sino que hay que forzar a buscar el outcome. Por ejemplo, no nos sirve decir que queremos que X esté en producción el día D, tenemos que saber qué estamos buscando con X, qué pretendemos conseguir de cara al usuario.
- Listad todos las iniciativas que tengáis pendientes y pensad qué aporta cada una de ellas a ese objetivo final. Incluso podéis valorarlas como hemos hecho en el caso anterior (cuando teníamos diferentes clientes). El objetivo es tenerlas priorizadas.
- Pensad en cómo vamos a medir cada una de las iniciativas cuando vayan saliendo a producción, para saber si estamos consiguiendo nuestro Objetivo o no, y modificad la prioridad si es necesario.
¿Tenéis más casos aquí no contemplados? Los podéis compartir en comentarios o bien hacédmelos llegar para pensar juntos nuevas soluciones.
¿Habéis probado otras soluciones para el mismo problema? Os invito a añadirlas a través de los comentarios para que sean útiles también para otros.
Descubre más desde CAMBIO Y EFECTIVIDAD
Suscríbete y recibe las últimas entradas en tu correo electrónico.