El Product Owner se focaliza en maximizar la rentabilidad del producto. La principal herramienta con la que cuenta para poder realizar esta tarea es la priorización. De esta manera puede ordenar la cola de trabajo del equipo de desarrollo para que este construya con mayor anticipación las características o funcionalidades más requeridas por el mercado o la competitividad comercial.

Otra responsabilidad importante del Product Owner es la gestión de las expectativas de los Stakeholders mediante la comprensión completa de la problemática de negocio y su descomposición hasta llegar al nivel de requerimientos funcionales.

¿Qué pasaría si los personajes de Game of Thrones fueran Product Owners? ¿Cómo vivirían estas personas en equipos ágiles? Veamos a algunos de nuestros personajes favoritos como Product Owners de equipos ágiles.

Arya Stark - Pegar malas ideas con el extremo puntiagudo

Esta es una versión de Product Ownership sobre la frase de Arya "Pegar con el extremo puntiagudo", en referencia a su gran destreza y su habilidad sobre cómo manejar la "aguja" de su espada.

La regla del Product Owner aquí es dejar de comenzar nuevos trabajos si no se llega al objetivo desde una perspectiva analítica y de aprendizaje validado. Todos hemos visto el efecto HIPPO (la opinión de la persona mejor pagada) en acción, un trabajo que sabemos que no debería seguir y que parece ser acelerado. Los mejores Product Owners son aquellos que no tienen miedo de frenar el trabajo cuando es una mala idea, ya que saben los riesgos que puede tener para los resultados del proyecto o incluso para sus empleos, pero se mantienen firmes a pesar de todo.

Ygritte: no sabes nada si no validas tus hipótesis.

Si bien Jon Snow no sabía nada acerca de Ygritte, es la misma situación que ocurre entre los equipos y los Product Owners si van construyendo capacidades a ciegas sin validar las suposiciones de los ajustes del problema y la misma solución.

Lean Startup nos dio un gran cambio en la mentalidad de desarrollo de software cuando comenzó a reconfigurar nuestro pensamiento para dejar de considerar todo un requisito y comenzar a probar y aprender sobre nuestras suposiciones más riesgosas.

Los grandes Product Owners no solo prueban y aprenden de sus hipótesis más riesgosas sobre el problema que se presenta y su solución, sino que son muy conscientes de los diferentes tipos de caminos y propuestas que pueden surgir en el aspecto cognoscitivo por el involucramiento que cada miembro del equipo o Stakeholder pueda tener, y luchan contra las mejores resoluciones para garantizar que la mejor sea la que se vaya al mercado.

Jon Snow - Los beneficios están llegando

También podría ser invierno con la cantidad de dinero que cotidianamente se gasta en la construcción de un producto que no resulte en los beneficios esperados. Aunque la mayoría de las personas han escuchado el informe Standish Chaos de 2002 que cita que el 64% de las funciones rara vez o nunca se usan, esto aún no está estadísticamente validado. Una vez más, el mayor desafío de cómo los productos brindan beneficios proviene de la comunidad y las enseñanzas que nos presenta Lean Startup, al centrarse en un ciclo de vida que se integra profundamente en su núcleo en un proceso de Recopila-Visualiza-Aprende con puntos de decisión críticos en la etapa de Aprendizaje para cambiar (problemas con objetivos variables), perseverar (continuar en el mismo camino, cambiar las opciones de solución) o perecer (detener el trabajo por completo).

Todavía hay demasiada mentalidad de "dejarlo pasar por alto" en la industria. Es por ello que las organizaciones líderes están incorporando profundamente este ciclo de aprendizaje en sus enfoques de desarrollo y alejándose de lotes pesados ​​para incurrir en ciclos de vida basados ​​en el flujo. Mientras que Scaled Agile Framework (SAFe) continúa creciendo, se pierde en mucho de lo que implementan, que se aplica de manera deficiente, crea lotes masivos de tres meses.

Piensa en lo que esto significa desde una perspectiva de testeo y aprendizaje: lanzas algo al mercado y comienzas a recopilar una análisis de datos. Al mismo tiempo, comienzas la próxima reunión de Incremento del Programa y creas un amplio y firme compromiso para los próximos tres meses de trabajo. Digamos que después de tres semanas obtienes los datos suficientes para validar lo que acabas de publicar y con gran preocupación, no se obtiene el resultado esperado. Tienes una suposición sobre lo que necesitas ajustar, pero requerirá dos semanas de trabajo. ¿Qué haces?

Puedes esperar hasta el próximo Incremento del Programa, que está a otros dos meses y medio, y luego entregar un cambio en otros tres meses (un ajuste que tomó poco más de cinco meses). Podrías sacar algo del Incremento del Programa, rompiendo así la expectativa establecida, lo que retrasaría aún más los beneficios del alcance. Si fueras muy inteligente, habrías incorporado cierta holgura en el Incremento del Programa para permitir un pivoteo en el trabajo liberado.

En el campo, rara vez se ha visto alguna de estas decisiones. Por lo general, los líderes no permiten ningún margen de holgura en un Incremento del Programa y en cambio, tienden a conducir para que se llene todo el incremento, y luego, lamentablemente, lo que sucede a continuación es que se ejerce una gran presión para que los equipos entreguen ambos, rompiendo su sostenibilidad con la promesa de " No dejaremos que esto vuelva a suceder ”, lo que inevitablemente siempre sucede.

Si bien puedes argumentar que estos líderes no han sido entrenados de manera efectiva y están malinterpretando el valor central del manifiesto ágil en torno a la adaptación para Agile (responder a un cambio a raíz de un plan), no descarta el hecho de que SAFe, ya que tiende a implementarse da como resultado un procesamiento por lotes masivos que a su vez reducen el tiempo para entregar los beneficios y el giro para la optimización de dichos beneficios.

Los grandes Product Owners lo saben y tendrán la capacidad para rechazar a los líderes de la organización ya así garantizar la optimización de los beneficios. Para hacer esto, nuevamente, el Product Owner probablemente necesitará un gran coraje para defender su decisión contra los líderes dentro de la organización.

Littlefinger - Los Backlogs no son un hoyo, son una escalera

Por un tiempo consideramos usar la cita de Petyr Baelish: “No pelees en el Norte o en el Sur. Lucha cada batalla en todas partes, siempre en tu mente. Cada uno es tu enemigo, cada uno es tu amigo. Cada posible serie de acontecimientos está sucediendo a la vez. Vive de esa manera y nada te sorprenderá. Todo lo que sucede será algo que ya has visto antes”, convirtiéndolo en una cita sobre las partes interesadas, los clientes y la previsibilidad de las necesidades, pero al final decidimos utilizar la cita más conocida, “El Caos es una escalera. Muchos han intentado subirla pero han fallado y nunca intentan de nuevo. La caída los destruye. Y a algunos se les da la oportunidad de subir. Se niegan, se aferran a dioses o ilusiones. Pero solo la escalera es real. Escalar es todo lo que queda”.

Los Backlogs son reales. La escalada a través de ellos para entregar es casi todo lo que hay que hacer siendo un Product Owner. Es importante destacar que un Backlog no debe ser un hoyo. Los Product Owners tienden a reconocer todas las solicitudes de las partes interesadas y cortésmente las ponen en el Backlog. Estos se priorizan en la parte inferior de la acumulación de Historias de Usuario y permanecen ahí por toda la eternidad. Los Grandes Product Owners verán no solo el trabajo importante y prioritario en el Backlog como parte del refinamiento del trabajo acumulado, sino que también eliminarán de forma activa los elementos envejecidos dentro de él, un trabajo que nunca se realizará porque se considera que tiene una prioridad o valor demasiado bajo.

Los Product Owners también apreciarán dónde se encuentran en la etapa de Explorar-Expandir-Extraer de su desarrollo de productos y el contenido de sus pedidos atrasados ​​reflejará la etapa.

Tyrion - Un Lannister siempre prioriza por valor

¿Es necesario decir mas? La respuesta debería ser si. Un buen Product Owner priorizará por valor, un gran Product Owner priorizará por valor con una comprensión del costo, la alineación con la estrategia, el mercado y las tendencias competitivas. El valor puede tomar muchas formas: valor para el cliente, valor comercial, reducción del riesgo o cumplimiento de las obligaciones de la industria. El valor de equilibrio con el costo de la demora y el tamaño del trabajo significará que los Product Owners pueden obtener Quick Wins antes. Se puede utilizar un primer algoritmo ponderado de trabajo más corto con una estimación relativa para comparar el trabajo en el Backlog para garantizar que se priorice el trabajo de mayor valor.

Daenerys: No solo voy a contar la historia, voy a vivirla.

Daenerys Targaryen puede ser la que rompe las cadenas con el objetivo de romper la rueda, pero como Product Owner, representa el papel de una narradora de historias. A los Product Owners les apasiona el problema que intentan resolver. Quieren llegar al corazón de esto y hacer lo mejor posible al involucrarse directamente con los clientes y al conocer profundamente los datos, las percepciones y los puntos críticos sobre los clientes y el negocio. Lo ideal sería que el equipo asistiera a las pruebas del cliente, pero si no lo hacen, entonces el Product Owner realmente tiene que ser la voz del cliente, para ayudar al equipo a ponerse en su lugar y comprender sus necesidades.

Aquí es donde Lean UX y Design Thinking se cruzan con Agile para construir lo que el cliente necesita.

Artículo Original: https://agileforest.com/2018/02/24/product-ownership-game-of-thrones-style/

¿Más Product Owners en Game of Thrones?

¿Tienes algún ejemplo de un personaje de Game of Thrones que se desempeñe como Product Owner? Si es así te invitamos a publicarlo en la sección de comentarios para incluirlo en el artículo.