- OnceDev
Cómo asegurarte de que estás trabajando en los elementos más importantes en cada iteración
Actualizado: 4 abr 2019
Elaborado por: Mike Cohn
Traducción: rick@oncedev.com
A ver si este problema te suena familiar:
Tu equipo Agile ejecuta una serie de Sprints, siempre realizando el trabajo de máxima prioridad como lo eligió el Product Owner. Pero después de esa serie de Sprints, revisas lo que el equipo cumplió. Y resulta que no es muy satisfactorio. Parece que todo lo que el equipo logró hacer fue pasar de una emergencia a otra, apagando un fuego tras otro.
El equipo trabajó muy duro sin duda alguna. Sin embargo, no logró hacer mucho.
¿Qué pasó? Caíste en la trampa de establecer prioridades en función de lo que parecía más urgente al comienzo de cada Sprint, un efecto secundario frecuente de la naturaleza iterativa e incremental de Agile. Existe una forma mejor.
La trampa de priorización Agile: selección de trabajo en cada iteración
La selección del trabajo que parezca más importante al comienzo de cada iteración puede afectar el nivel de optimización en algunos casos. Puede llevar a los Product Owner a priorizar el trabajo en la crisis del día, ya sea esto
Un problema urgente de soporte técnico
Algo por lo que se perdió una venta ayer.
El último capricho de un cliente importante.
Si bien cualquiera de estas razones puede ser lo más importante en que trabajar, con demasiada frecuencia no son decisiones estratégicas. Y al elegir trabajar en lo que sea que alguien esté gritando en el momento, el Product Owner renuncia a la oportunidad de avanzar en algo más grande, más importante o más estratégico.
Priorizar sin objetivos es como escalar montañas tener un mapa
Mis compañeros residentes de Colorado y yo estamos orgullosos de nuestros 53 "Decimocuartos", que son picos montañosos que tienen al menos 14 000 pies de altura (4 267 metros). Hay dos maneras de alcanzar la cima de un Decimocuarto.
El primer método consta de simplemente conducir hasta la base de la montaña y comenzar a caminar hacia lo más alto que puedas ver. Eso seguramente será un pico falso , que solo parece ser la cima porque oculta a la cima verdadera.
Pero, habiendo subido el pico falso, ahora puedes ver un pico más alto. Creyendo que es la cima verdadera, sigues subiendo. Solo para descubrir que ese pico también es un pico falso.
Sigues de esta manera hasta que finalmente llegas a la cima verdadera. Pero entre tú y la cima, hay un valle profundo. Y para alcanzar la cima de 14 000 pies, primero debes descender 10 000 pies antes de subir de nuevo.
Claramente, esta no es una buena manera de alcanzar a uno de los Decimocuartos de Colorado.
El segundo enfoque consiste en comprar un mapa topográfico en una tienda de senderismo local. Con el mapa en la mano, puedes planificar una ruta más eficiente hacia la cima que evita la necesidad de descender y volver a ascender 10 000 pies.
Metas de iteraciones múltiples: el mapa del Product Owner
Para el Product Owner Agile, el equivalente del mapa topográfico es tener un objetivo de iteraciones múltiples más grande. Sin un objetivo de iteraciones múltiples, el Product Owner simplemente está escalando de un pico falso a otro. El Product Owner y el equipo pueden llegar a su destino final, pero a menudo solo después de descender y salir del equivalente al valle de 10 000 pies.
Sin embargo, es muy tentador abordar esas crisis a corto plazo primero.
Para empezar, le da al Product Owner un sentido de logro: algo se ha completado y se puede quitar de la lista de tareas pendientes. En segundo lugar, apacigua a quienquiera que pida una solución inmediata. A la mayoría de nosotros nos gusta complacer a otras personas, y esto es lo que precisamente hace. A menudo con solo un impacto mínimo o imperceptible en el objetivo más grande, el objetivo a largo plazo y generalmente el objetivo más importante.
Al priorizar, recuerda que lo urgente raramente es lo importante
El presidente de Estados Unidos, Eisenhower, sabía lo importante que es distinguir entre asuntos importantes y asuntos urgentes. Aunque los historiadores no están de acuerdo si Eisenhower en realidad lo expresó de esta manera, a menudo se lo cita diciendo:
"Lo que es importante rara vez es urgente, y lo que es urgente rara vez es importante".
Sin importar la manera en que lo expresó, Eisenhower estaba diciendo que esas crisis urgentes en las que todos nos vemos tentados a trabajar no suelen ser importantes para alcanzar nuestro objetivo general.
Un buen Product Owner tiene cuidado al considerar tanto la importancia como la urgencia de los elementos de la cartera de productos cuando tiene que priorizar el trabajo para el equipo.
Los Product Owner deben identificar un objetivo significativo trimestral
Pero si el Product Owner no sabe lo que es importante, la urgencia siempre ganará. Y esto lleva a la serie de Sprints decepcionantes que describí al principio de esta publicación. Cuando un equipo Agile pasa de un problema urgente a otro problema urgente, la gratificación inmediata se desvanece cuando el equipo y las partes interesadas se dan cuenta de que no se avanzó hacia las metas más importantes.
Esto significa que es vital para el Product Owner definir un objetivo considerablemente importante. Tengo la impresión de que los mejores objetivos significativos toman alrededor de tres meses para cumplir.
Llevar a cabo más de una iteración es importante porque enfoca al equipo en un plazo de tiempo más largo. Esto significa que el objetivo importante debe ser un resultado comercial importante, como migrar una parte de un sistema a una nueva tecnología; añadiendo una característica grande, importante y notable; o cualquier cantidad de cosas.
Pero tiene que ser significativo. Para un producto nuevo, podría ser crear un producto mínimo viable (MVP). Para un producto existente, podría ser agregar una característica comercializable mínima (MMF). Algunas organizaciones se refieren a él como un objetivo extremadamente importante (WIG).
Equipado con un objetivo importante, ya sea en forma de MVP, MMF o WIG, el Product Owner podrá evaluar de una mejor manera las necesidades urgentes. Si abordar un problema urgente es más importante que trabajar hacia lograr un objetivo importante, por supuesto, el equipo debe dirigirse hacia el problema urgente.
La intención de establecer un objetivo significativo no es crear una devoción servil a un objetivo de iteraciones múltiples. Más bien, es establecer un mecanismo para respaldar las decisiones de priorización del Product Owner.
Sin un objetivo significativo contra el cual se pueda comparar la importancia de los asuntos urgentes, la urgencia siempre ganará.
¿Cuál es tu experiencia?
¿Has experimentado el resultado insatisfactorio de una serie de Sprints que se enfocaron solo en asuntos urgentes? ¿Cómo protege el Product Owner o equipo de su producto contra los objetivos urgentes sobre los importantes a más largo plazo? Por favor comparte tus pensamientos en los comentarios abajo.