Esta es la transcripción de la entrevista realizada por Adolfo Foronda hace unas semanas sobre cómo un Propietario de Producto (Product Owner) debe priorizar una pila de producto (backlog). Espero que lo disfrutes y lo encuentres útil.
ADOLFO: Soy tu anfitrión Adolfo Foronda en nerd Stalker en Twitter.
Hoy estoy con un invitado muy especial, Erich Bühler. Él es consultor senior Agile, que regularmente trabaja en pareja con entrenadores de Scrum certificados (CSP) y es experto en Business Agility y transformaciones organizacionales.
Es también autor del primer libro en .NET en español en 2002. Presenta en muchos eventos internacionales y recientemente dirigió un webinar sobre Enterprise Social Systems (ESS) para Scrum Alliance, organizó el primer ScrumDay en Chile y Valencia, y ha servido como asesor de confianza en los últimos 22 años para las siguientes empresas líderes … hay un montón de ellas aquí … LATAM Airlines Chile, Microsoft Iberica, Ministerio de Defensa España, British Telecom UK, Bolsa de valores de Londres, INDRA España, MasterCard Uruguay , AXA insurance Mediterranean España, y muchas más empresas en Malta y Nueva Zelanda ….
Erich bienvenido al show.
Erich: Gracias!
ADOLFO: Erich, ¿cuáles son las cosas que debes considerar para priorizar la pila de producto (backlog) y su conexión con los «releases» y cómo explicas por qué las partes interesadas (stakeholders) lo necesitan?
Erich: Para producir un Backlog se necesita contar con una definición de valor de negocio única en toda la empresa y una hoja de ruta (Roadmap). En Agile, la mayoría de los Roadmap se basan en metas, en general, no usamos requisitos fijos para nuestros mapas de ruta…
Una buena hoja de ruta te ayuda a traducir las decisiones estratégicas en planes factibles y alinear las expectativas del cliente con los resultados.
Así que para tener una hoja de ruta (esto es la primera parte), es necesario contar con una visión compartida y una estrategia válida.
Básicamente, tu hoja de ruta tiene que informar a la gente cómo va a crecer tu producto y los diferentes «releases»… y tenemos que conectar estos objetivos con los «releases» (lanzamientos).
Pero lo importante aquí es que cuentes con una historieta coherente que englobe esos lanzamientos. ¡Esto es una parte muy importante!
Ni siquiera pienses en hacer otra cosa hasta que tengas la historieta coherente que conecte los lanzamientos entre sí.
Tu emplearas esa historieta para alinear a las partes interesadas (stakeholders) y asegurarte de que todos estén en la misma página. Es necesario definir más o menos lo que va a tener cada lanzamiento o «release» (aparte de la historieta) y luego analizar el costo y el impacto que cada uno de ellos tratará de lograr.
Necesitas tener la relación correcta entre la hoja de ruta y la pila del producto (Backlog). Cuando tienes una hoja de ruta buena, entonces puedes pensar en priorizar tu pila de producto.
Recuerda que tu hoja de ruta es tu estrategia o plan estratégico y describe cómo el producto probablemente crecerá a través de las diferentes versiones
El backlog en su lugar, es la herramienta táctica. Así que es más detallado; allí puedes encontrar las épicas, las historias de usuarios, etc.
Mi recomendación es que mantengas ambos separados pero conectados al mismo tiempo con una muy buena historieta que explique el porqué de lo que estamos haciendo, para que la gente lo pueda entender.
Una vez que entiendas todas estas cosas, estarás listo para priorizar tu pila de producto (Backlog).
A su vez, algunas compañías hacen refinamientos … y yo generalmente recomiendo hacer tres o cuatro refinamientos a la semana.
ADOLFO: Has tocado algunas de esas técnicas y herramientas. Vamos a hacerlo al detalle … ¿qué debemos usar o recomendar? Más temprano dijiste que dejaste de utilizar el correo electrónico (ver podcast anterior) en una empresa…
Erich: ja ja ja … sé que suena un poco loco, ¿verdad? Pero funcionó muy bien.
En mi experiencia, lo que he visto en algunas empresas es que las formas o las técnicas que utilizan son muy anticuadas o complicadas para priorizar la pila de producto (Backlog).
Lo primero que tienes que comprobar es algo muy simple … si la pila del producto (Backlog) es visible.
Generalmente pido a la gente que escriba algunas tarjetas y las coloque en la pared … y especialmente lo hago con equipos nuevos y Product Owner. Y luego enseño alrededor de 10 técnicas diferentes para priorizar un Backlog. Podemos utilizar valor del negocio, podemos emplear sentido de urgencia, costo de la demora, Skeletton, … tenemos al menos 10 o 12 técnicas. Probablemente podríamos hablar de esto durante horas…
Lo importante aquí es que todo el mundo en el equipo y fuera del mismo entienda las técnicas y la forma en que las decisiones se toman. Por lo general, recomiendo tener sesiones de refinamiento tres veces a la semana, como he mencionado antes, de 45 minutos cada una y con todo el equipo. Y sé que algunas compañías lo hacen ya… pero incluyendo solo una parte del equipo.
Recuerda que el objetivo de los refinamientos es el crear alineación y hacer que todo el mundo entienda por qué estamos haciendo lo que hacemos.
El resultado de esta sesión de refinamiento tiene que ser un entendimiento compartido de las historias de usuarios que vienen, todas ellas con sus criterios claros de aceptación.
Como he dicho, también es necesario asegurarse de que todo el mundo entiende las técnicas. No tiene nada de malo que los miembros del equipo de desarrollo sepan como funciona el Costo de la demora (por ejemplo) y por qué estamos usando eso.
Realmente no queremos producir documentos, sino que crear esa comprensión compartida. Los documentos compartidos no se traducen en comprensión compartida. Este es un problema común que he visto en muchas empresas.
Necesitamos tener un Backlog claro y visible y con buenos criterios de aceptación; Luego usamos las técnicas e priorización… puedes hablar de costo de la demora o de valor de negocio durante la sesión de refinamiento…
Finalmente tenemos que asegurarnos de que todo el mundo entiende cómo funcionan las técnicas y tienen una definición muy clara de terminado (Definition of Done) para los elementos del Backlog.
ADOLFO: Suena como si estuvieras proponiendo papel y no escucho que estés hablando de Jira o Trello o sabes … todo esas cosas…
Erich: Bueno … especialmente con los nuevos Product Owner, tenemos que asegurarnos de que todo el mundo puede ver lo que está sucediendo.
Pero también entiendo que algunas empresas tienen equipos que están remotos. Equipos que probablemente están divididos en diferentes zonas geográficos.
Tanto como puedas… intenta cerciorarte de que cada miembro puede ver lo qué está sucediendo en todo momento. De hecho, en una de las empresas que ayudé estaba dividida en dos lugares diferentes, y allí pusimos cámaras todo alrededor de la empresa. A su vez, se contaba con un mapa/plano donde las personas podían hacer clic en las diferentes habitaciones y ver quiénes estaba allí. Ahí rompimos la barrera entre los que estaban a la distancia y quienes estaban en la oficina.
Y esto es algo muy importante especialmente con gente nueva. Necesitamos reforzar este tipo de comportamientos donde todo el mundo puede ver lo que sucede y contamos con visibilidad alta.
ADOLFO: Suena como si hubieras tocado ya varios temas ¿cómo ayudas a las partes interesadas (Stakeholders) a llegar a un entendimiento común de las prioridades y qué prácticas son buenas para vincular las prioridades con el negocio de la empresa? Suena como que estas reuniones tres veces por semana realmente ayudan a establecer un entendimiento compartido ¿Es así?
Erich: Sí, especialmente si la empresa viene del mundo tradicional.
Tenemos que asegurarnos de ir aumentando la visibilidad. Lo importante aquí es también que se comprenda la estimación y el valor del negocio.
He visto que muchas compañías donde se tienen diferentes definiciones de valor de negocio, incluso cuando están produciendo el mismo software.
Lo que generalmente hago es tratar de organizar una reunión o un taller con todo el mundo… a veces lleva dos sesiones.
Durante la primera sesión escribimos las metas que se transformarán en la hoja de ruta (Roadmap). Y luego lo que hacemos es comenzar a crear las historias de usuario o épicas. Terminamos la sesión con un entendimiento común de valor de negocio y las metas del mismo.
Durante la segunda sesión, lo que hacemos es tratar de revisar lo que alcanzamos en la primera sesión y empezamos a centrarnos en la creación de los «releases» (lanzamientos) … y lo que va incluira proximadamente cada versión.
Esto probablemente implique decenas de negociaciones. Todo el mundo tiene que estar presente … las partes interesadas (Stakeholders), equipo de desarrollo y también el propietario del producto.
Se trata de crear un entendimiento compartido de las prioridades.
Mis expectativas después de este tipo de sesiones es que todos estén alineados y entiendan cuál es la primera prioridad.
ADOLFO: Muy bien, gracias Erich.
Erich: ¡Gracias!
–
Y recuerda, si necesitas conocer más sobre como potenciar equipos Scrum y Ágil dentro de tu empresa, visita nuestro sitio Web.
