El Product Owner comienza a planificar y muestra al equipo una lista de elementos que ha priorizado en el backlog del producto. El primer elemento es la creación de una pantalla donde el usuario registrará sus datos personales. El equipo pregunta sobre la plantilla y el formato de cada campo, si necesita consultar la información en algún lugar, si el formato está listo. Algunos desarrolladores reclaman que los detalles no están claramente descritos en la historia, y el PO los complementa. El equipo puntualiza: 8 puntos. Podemos continuar con la próxima historia del backlog.
¿Cuántos problemas ve en esta situación? Si está acostumbrado a trabajar con un equipo "hacedor de tareas", tal vez no vea ninguno. Pero hay muchos puntos de mejora aquí, y algunas disfunciones que pueden causar verdaderos desastres en un producto.
Un equipo "hacedor de tareas" es aquel que se centra en la lista de tareas a ejecutar. Incluso puede tener la costumbre de crear historias técnicas, muchas veces por sorpresa durante la planificación, porque “es importante”. Es un equipo que busca la eficiencia más que la eficacia, pues está muy preocupado por el rendimiento y la velocidad, pero no tanto con lo que se aporta de valor para el producto. Este equipo delega en el PO de forma exclusiva el control, entendimiento y decisión sobre lo que va o no a resolver el problema del consumidor. Las hipótesis de solución del problema quedan a cargo del PO y, con suerte, del diseñador. Al equipo solo le corresponde hacer viable desde el punto de vista técnico lo que el PO haya decidido que debe hacerse.
Hablamos mucho de mentalidad ágil, pero al encontrar un equipo "hacedor de tareas" parece que esta mentalidad cesa cuando el equipo descubre que va a tener que calentarse la cabeza pensando en cómo resolver un problema del usuario. Este equipo falla al no darse cuenta de que las mejores soluciones emergen de equipos multidisciplinares (no, el PO no es un equipo multidisciplinar), y de que resolver un problema realmente importante va a exigir que todas las cabezas del equipo piensen juntas. En vez de asumir esta postura, lo que vemos es una transferencia de responsabilidad y esfuerzo cognoscitivo al PO. Mientras tanto, los miembros del equipo de desarrollo, a menudo incluyendo también a los diseñadores, asumen la postura del “solo cumplo órdenes”, "soy desarrollador, no me pagan para eso”, “necesito el límite de la historia cerrada”, “fue esto lo que pidió el PO”.
El resultado es un producto pobre, con una probabilidad de éxito mucho menor.
¿Cómo podemos, entonces, abordar estas disfunciones y transformar un equipo "hacedor de tareas" en un equipo de producto?
Problemas, no soluciones
Al crear una historia, debemos evitar definir la solución. Llévesela al equipo y hable usando las 3 C sugeridos por Ron Jeffries: cartón, conversación, confirmación. Recuerde que el objetivo de la historia es comenzar una conversación, y no ser prescriptivo. Usamos historias de usuario para que el equipo consiga empatizar con el consumidor del producto y lo ayude a resolver su problema; por lo tanto, debe explorar este extremo al máximo con el equipo y aproximarse a la experiencia y padecimientos del usuario. El equipo debe ser capaz de responder a la pregunta “¿Cómo ayuda a la gente el producto que estoy elaborando?”, expresando su propósito sin pestañear.
Refinamiento
Para los PO más experimentados esto puede no ser ninguna novedad, pero no es raro ver equipos que no hacen Refinamiento. Y, por lo general, estos mismos equipos tienen Planificaciones extremadamente extensas y desgastadoras.
El Refinamiento es un momento que tiene lugar durante el tiempo de sprint, mirando los elementos que están en la parte superior del backlog, probablemente serán absorbidos por el equipo de desarrollo en el siguiente sprint.
El objetivo del proceso de refinamiento consiste en dejar las historias preparadas según la definición de preparado (definition of ready). Sin embargo, es posible que durante el Refinamiento, el equipo descubra que no dispone de toda la información para decidir cuál será la solución a esa historia. ¡Y eso es genial!
¿Se imagina que espera a la Planificación para descubrirlo?
Durante el Refinamiento se espera que el equipo aborde algunas historias al mismo tiempo. Intentar abordar todas las historias de la próxima Planificación puede generar una reunión muy agotadora, por lo cual es válido prever reuniones rápidas para debates recurrentes a lo largo del sprint. Ejemplos: para sprints de 2 semanas, un refinamiento de 1 hora semanal. Para los sprints de 1 semana, 2 refinamientos de ½ hora semanal.
Es importante que, durante el Refinamiento, el equipo:
-
- compruebe si todos entienden el problema que ha de resolverse, el valor que debe agregarse al producto, la prueba de hipótesis que debe realizarse y los motivos que llevaron a la priorización de aquella historia;
- ayude a complementar la información de la historia, haciéndola más rica;
- discuta la solución para ese elemento de backlog y llegue a un consenso;
- averigüe si es necesario involucrar a más personas para discutir la solución, e invitarlas al próximo Refinamiento;
- compruebe si aún existen impedimentos o información adicional por recabar, y ocúpese de esto tan pronto como le sea posible, a fin de preparar la historia;
- valore la historia en relación al esfuerzo, pues se utilizará como criterio de priorización del PO.
El Refinamiento no debe usarse, sin embargo, para desechar tareas o hacer POC. Tampoco tratarse como una tarea puntuada en el sprint, ya que solo diluye, durante el Sprint, una discusión que, si no se hace, aparecerá de peor forma en la Planificación.
Dinámicas de consenso
Esta es una excelente manera de romper la expectativa del equipo de recibir el ámbito predefinido del PO. Usando dinámicas de consenso, usted puede presentar un problema y omitir temporalmente la solución que ha pensado para el mismo, mientras que el equipo busca formas alternativas que usted mismo puede no haber considerado. Esto enriquecerá las hipótesis de solución de su producto y le dará al equipo la sensación de que el producto le pertenece.
Independientemente de si puede perfeccionar su backlog con la participación exclusiva de su equipo, o si precisa de más personas (otros equipos, consultores, partes interesadas), es importante ser conscientes de que estamos tratando de empoderar al equipo para resolver un problema. Para ello, es necesario buscar un equilibrio entre las personas que tienen una postura de mayor liderazgo (sea por naturaleza o por cargo) y aquellas otras que no se sienten tan cómodas llevando el timón del barco.
Además, las aparentes concordancias exigen una atención. Las preguntas como “¿todo el mundo lo entendió?” no ayudan, porque nuestra tendencia es siempre a creer que lo entendemos, y que todos tienen la misma visión que nosotros. Una estrategia diferenciadora es poner todo el mundo a escribir de forma individual en un post-it lo que ha entendido y después comparar las respuestas para llegar a un consenso y anotar seguidamente en el cuadro el resultado.
(PATTON, Jeff)
Doble track scrum
El concepto creado por Jeff Patton tiene como objetivo arrojar claridad al proceso de descubrimiento continuo del producto. Parte del equipo está centrado en el desarrollo de los elementos de backlog que ya estaban preparados y forman parte de la planificación, mientras que el PO, el UX y uno o más miembros del equipo de desarrollo dedican parte de su tiempo a “descubrir” lo que deberá construirse a continuación, a través de prototipos y validación de hipótesis, que generarán elementos de backlog preparados para el próximo sprint.
Hagamos un intento de adaptación para explicar la idea de una forma simple y práctica:
Este es un sprint “común” frente a un sprint en doble track scrum:
Los porcentajes son aquí ficticios, y como mucho una sugerencia. Cada equipo termina descubriendo, sprint a Sprint, lo que funciona mejor.
Este es el contenido abordado en una vía de descubrimiento:
Parte del esfuerzo del sprint se usará para entender si lo ya entregado resolvió el problema que estamos tratando de solucionar. Vamos a in/validar nuestras hipótesis y aprender de acuerdo con las métricas que hemos definido anteriormente. Vamos a recoger comentarios y entender lo que podemos mejorar. Esto nos aportará elementos tanto para ajustar o modificar tanto las historias que a las que se dio prioridad como para descartar o crear nuevos elementos. Haremos pruebas con prototipos, investigación de guerrilla, conversaciones con los usuarios y cuanto resulte más útil para adoptar la mejor decisión posible en relación a cuáles serán nuestras siguientes hipótesis de problemas y de soluciones.
Mentalidad
Por último, es necesario que continuemos siempre reclamando la mentalidad correcta del equipo. Sin una presión saludable a los colegas, la tendencia es que el equipo retome una postura cómoda y rutinaria, por más que hayan apreciado el placer y la motivación de enamorarse del problema y formar parte de la solución. Después de todo, estamos luchando contra décadas de condicionamiento enfocado en la ejecución de hacer más cosas más rápido, y no en la búsqueda de lo correcto para construir.
¿Te gustó? ¿Quieres saber más acerca de este tema? Accede a los enlaces a seguir:
Inscríbete en nuestra formación de Certified Scrum Product Owner (CSPO).
Lee las publicaciones sobre:
Product Owner: descubrir el papel del PO
Transformación Ágil con OKR
Tanque de Decantación: un canvas como solución
