viernes, 27 de noviembre de 2020

¿Tablero de dependencias o de compromisos?

Tablero de compromisos donde los equipos ágiles y de soporte (TI y negocio)
colaboran para alinear y priorizar iniciativas a realizar hasta finales de año,
del video resumen del 2do PI Planning de Telefónica del Perú
Mientras miraba el video resumen del 2do PI Planning de Telefónica del Perú me llamó mucho la atención la imagen de la derecha que se muestra en el segundo 0:20. Se trata sin duda de un tablero de dependencias de una tribu en cuya cabecera puede leerse "Tablero de compromisos"...

¡Qué acierto! pensé, ese título va a la esencia, un tablero que representa los compromisos cruzados que adquieren los equipos en la PI Planning. Realza de esta manera que un tablero de dependencias no trata solo de visibilizar las dependencias identificadas, también trata de visibilizar el compromiso adquirido en cada una de estas.

Recordemos que para que un elemento con dependencias se lleve al tablero de dependencias tiene que haber sido hablado con el equipo del que dependemos, y haber sido resuelta su dependencia: haremos tal actividad en un sprint acordado para que el equipo dependiente pueda desarrollar su trabajo en un sprint posterior sin bloqueos ni retrasos.

El compromiso resultante se hace patente con la regla de que sólo un miembro del equipo correspondiente puede colocar un elemento en su carril, está prohibido colocar cualquier cosa en el carril de otro equipo. Con esto nos aseguramos que haya verdadero compromiso, si yo coloco algo en mi carril es que lo hago de forma consciente y entendiendo las consecuencias.

Utilizar el término tablero de compromisos tiene otra ventaja, y es que resuelve la problemática entre dependencias no resueltas y riesgos. Una dependencias no resuelta es un riesgo, y dado que en una PI Planning tenemos tablero de dependencias y tablero de riesgos puede resultar confuso distinguir riesgos y dependencias.

Para futuras PI Plannings hablaré de compromisos en lugar de dependencias... :-)

miércoles, 25 de noviembre de 2020

¿Cómo se sincroniza Product Management en SAFe®?

PO-Sync como evento del ART - imagen del tema
Program Increment cortesía de © Scaled Agile, Inc.
SAFe® introduce en la sincronización del tren (ART), en la llamada ART-Sync, el evento de PO-Sync. Su objetivo principal es obtener visibilidad sobre el avance del tren en la construcción del producto y del progreso hacia los objetivos, discutir problemas u oportunidades en el desarrollo de las features y evaluar cualquier ajuste de alcance del PI para asegurar una alineación de la visión del producto y el contenido relacionado con el trabajo en todos los equipos involucrados.

Este evento suele ocurrir semanalmente o con mayor frecuencia, según sea necesario, y está limitado a un tiempo determinado de 30/60 minutos. Cada equipo envía a su Propietario del Producto al PO-Sync y todos los Product Managers deben de asistir, lo suele facilitar el RTE o un Product Manager.

PO-Sync ante el Program Board
cortesía de Pixabay
Se efectúa ante el Program Board para dar visibilidad holística de la situación del tren, y se discuten temas en los que se incluyen:
  • Hacer seguimiento de features, progreso de los equipos e interoperabilidad.
  • Actualizar las dependencias y evaluar si el plan se ve afectado.
  • Actualizar los riesgos no resueltos, tratar los que puedan haber aparecido recientemente y evaluar si el plan se ve afectado.
  • Analizar problemas y oportunidades surgidas con el desarrollo de las features/epics.
  • Evaluar posibles ajustes de alcance, calendario y/o de prioridad (basados en realidades de los equipos y necesidades de los clientes).
  • Actualizar el tablero Kanban del tren.
  • Tratar otras cosas relevantes para compartir, como por ejemplo releases.
En un tren que esté empezando vale la pena verificar las siguientes preguntas con cada Propietario del Producto:
A PO-Sync generalmente le sigue un "Meet After", o reunión posterior, para aquellos que deseen profundizar en problemas específicos.

El evento también se puede utilizar para preparar el próximo PI y puede incluir el refinamiento de la pila del programa y su priorización mediante WSJF (Weighted Shortest Job First).

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

viernes, 20 de noviembre de 2020

¿Una actividad de team-building que asiente la colaboración en equipos remotos?

Tangram casa resuelto - cortesía de Pixabay
En esta época de COVID-19 es más importante que nunca hacer actividades de team-buidling, tanto para formar equipos vía remota como para reforzar equipos existentes. Toda actividad de team-building refuerza la integración de los miembros del equipo, muestra las debilidades y fortalezas de cada individuo en relación al equipo e impulsa el progreso a lo largo de las etapas de Tuckman.

Quiero presentar una actividad muy sencilla y que se realiza en menos de media hora. Se basa en Tangram (siete tableros de astucia), un juego chino muy antiguo, que consiste en formar figuras con siete piezas, llamadas Tans, sin solaparlas: 5 triángulos, 1 cuadrado y 1 romboide.

El propósito de esta actividad es experimentar cómo funciona un equipo ágil en los aspectos de colaboración y comunicación.
Pantallazos antes y después de la actividad que comparto en forma de Google Slides en este post

Los pasos para realizar el juego son:

  1. Seleccionad un cronometrador
  2. Resolved en tres iteraciones de forma colaborativa los rompecabezas lo más rápido posible con un tiempo límite de 3 minutos
  3. Después de cada figura haced una retrospectiva de 1 minuto para discutir el proceso e identificar cómo podéis mejorar
  4. Pasad a la siguiente figura y aplicad las mejoras identificadas
  5. En la retrospectiva final comparad los tiempos de cada iteración y compartid los aprendizajes
Segunda ronda en ejecución
Sigue un ejemplo del aprendizaje de un equipo que trata de resolver los rompecabezas de forma colaborativa:
  • La primera ronda suele ser caótica, todo el mundo se lanza a resolver el rompecabezas de forma individual; chocan en la selección de los Tans y algunos deshacen lo que otros hicieron.
  • En la primera retrospectiva el equipo se focaliza en como mover las fichas, en como decir donde van y quien mueve. Suele aparecer la figura del facilitador que mueve y comparte una pantalla que sirve de referencia para las conversaciones.
  • A lo largo de la segunda ronda se producen principalmente conversaciones sobre como mover las fichas, hay menos jugadores moviendo y se ve claramente como cooperan.
  • En la segunda retrospectiva aparecen las primeras reglas, como por ejemplo empezar con piezas que sea evidente donde van.
  • La tercera ronda ya es de equipo integrado, las conversaciones son muy cortas y se producen indicaciones rápidas de forma ordenada.
  • En retrospectiva final he oído la frase "lo difícil es llegar a una estrategia común", y eso es precisamente el objetivo de este ejercicio; aprender a ser equipo definiendo una estrategia común.
Observaremos que la resolución de los rompecabezas suele empezar con alrededor de los 2 minutos, y el último rompecabezas, que es de un nivel más avanzado, ¡lo resuelven en más o menos 1 minuto!

Tangram on-line de Mathigon
He creado un documento en formato Google Slides que permite que varios participantes colaboren sobre el mismo y resuelvan el rompecabezas. Si sigues este link a Google Drive te abrirá a una copia que podrás guardar en tu unidad:

Otra opción para realizar la actividad es el Tangram on-line de Mathigon, el de la imagen que se ve a la izquierda. Cada sesión es para un solo jugador y la idea es que un jugador voluntario comparta su pantalla en videoconferencia y haga los movimientos que el equipo decida hacer.

A través de esta actividad también podéis hacer experimentar la autoorganización y la mejora continua de los equipos ágiles a vuestros alumnos en los cursos de Scrum. ¡Mucho éxito!

lunes, 16 de noviembre de 2020

¿Cómo sincroniza Scrum de Scrums el ART en SAFe®?

Scrum de Scrums como evento del ART - imagen del tema
Program Increment cortesía de © Scaled Agile, Inc.

SAFe® introduce en la sincronización del tren (ART), en la llamada ART-Sync, el evento de Scrum de Scrums. Su objetivo es apoyar a los equipos en la colaboración y coordinación de su trabajo con otros equipos, coordinando las dependencias del tren y proporcionando visibilidad del progreso y los impedimentos, para asegurarnos de que logren sus objetivos de sprint versus a los objetivos generales del PI.

Scrum de Scrums suele ocurrir una vez a la semana. Dependiendo de la madurez es usual que al principio se realice con mayor frecuencia, e incluso haya algún evento ad-hoc provocado por una situación urgente o circunstancias particulares.

Se realiza dentro de un tiempo limitado, usualmente a 30 minutos, y de nuevo, dependiendo la madurez si queremos apoyar el aprendizaje, puede ser positivo alargar y limitar los primeros eventos a 60 minutos. Lo facilita el Release Train Engineer (RTE) y asisten los Scrum Masters, y opcionalmente miembros de equipos, incluidos Propietarios del Producto, como expertos para tratar algún impedimento o necesidad que el equipo ha llevado al Scrum de Scrums. La asistencia es obligatoria, por tanto es importante agendar el evento en un slot que todos puedan asistir, especialmente ahora con COVID-19 y nuestra realidad de equipos dispersos cuando es importante buscar una hora que ayude a todos.

Scrum de Scrums ante el Program Board
Se efectúa ante el Program Board para dar visibilidad holística de la situación del tren, y el RTE sigue el un guión de preguntas para facilitar la sincronización. Quiero resaltar que los Scrum Masters, o quienes representen su equipo, deben haberse preparado para responder a estas preguntas previamente.
Mantener la reunión breve y enfocada en estas preguntas ayudará a concentrarse en lo que realmente importa, y al RTE a estar al tanto de los problemas que afecten a más de un equipo.

A Scrum de Scrums comunmente le sigue un "Meet After", o reunión posterior, para aquellos que deseen profundizar en problemas específicos. Para finalizar una de las responsabilidades del RTE es comunicar bloqueos, impedimentos mayores y retos a los interesados clave y, si es el caso, buscar y gestionar soluciones con éstos.

La clave para el éxito de Scrum de Scrums es que todos entiendan de la misma manera el propósito del evento. Uno de los grandes beneficios que he experimentado es como se forma y potencia la colaboración entre los Scrum Masters, y por ende entre los equipos. Fomenta que los Scrum Masters y equipos se preocupen unos por otros, y a medida que el tren madura los impedimentos llevados a Scrum de Scrums decrezcan porque se empiecen a resolver fuera del Scrum de Scrums. Se evidencia cuando en conversaciones la gente habla de problemas que han resuelto y que nunca llegaron al Scrum de Scrums.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

sábado, 14 de noviembre de 2020

¿Existe alguna simulación de Scrum on-line?

Autora facilitando la simulación
Dada la situación actual de COVID-19 muchos de nosotros, tanto coaches ágiles como trainers, tenemos necesidad de una simulación de Scrum on-line.

Algunos hemos preparado tableros FunRetro o tableros Miro para nuestros entrenamientos, y ahora, gracias a Timofey Yevgrashyn, tenemos opción a una simulación simple y realista para entrenar y fomentar la colaboración de nuestros equipos de desarrollo. El juego está diseñado para hasta 6 jugadores e incluye en su ejecución todos los eventos de Scrum a lo largo de 3 sprints de 3 días. A lo largo de la simulación ocurren problemas a los que el equipo se ha de enfrentar tomando decisiones colaborativas antes de que termine cada día de trabajo.

Tablero de inicio de la simulación Scrum Card Game
En la página web del juego podemos leer: "Scrum Card Game es un juego simple que permite a los jugadores experimentar el trabajo en sprints de Scrum, discutir muchas cuestiones y temas que suceden en la vida real mientras trabajan en un equipo Scrum. La discusión sobre la mesa de juego será muy cercana a la experiencia real del trabajo en un equipo Scrum. Este juego usualmente se juega durante un entrenamiento o taller. Los participantes ya deben conocer y entender el marco de trabajo Scrum o pueden aprenderlo mientras participan del juego. También puede servir como método para hacer que un equipo experimentado reflexione sobre sus rituales y reglas establecidas de Scrum".

Tablero que muestra el juego en curso
Uno de los puntos fuertes de esta simulación es que no tiene automatismos de flujo, llevando toda decisión sobre asignaciones y movimiento de historias de usuario a la autoorganización del equipo.

Iniciar simulación: Para acceder a la simulación podemos ir a la página de Scrum Card Game o directamente a la página del juego on-line. Pide un nombre y acto seguido genera un enlace para compartir con los demás jugadores para que puedan acceder a la simulación.

El tablero de inicio trae un pila de producto priorizada con historias de usuario preestimadas en puntos de dado.

Planificación de sprint: El Propietario del Producto explica cuáles son las historias más prioritarias a desarrollar. Toma en cuenta la capacidad del equipo, la cual puede ser estimada, por ejemplo, en función del máximo, mínimo o promedio de puntos de dado que puede sacar el equipo por sprint, con base en el número de miembros. El equipo decide cuantas historias va a abordar en el sprint, considerando todo lo anterior y las ha de arrastrar a la columna de "To Do".

Reunión diaria: Cada miembro se asigna a una o a varias historias. Dado que la simulación fomenta la colaboración, los miembros pueden hacer swarming y asignarse varios a una misma historia. Asignados los miembros a las correspondientes historias, éstos ya pueden lanzar sus dados y aplicar los puntos a las historias. El dado introduce en el juego la variabilidad que ocurre en la vida real. Con las jugadas también pueden ocurrir problemas o que un miembro adquiera una habilidad o una solución.

Los problemas bloquean una historia. Para solucionarlos el equipo decide aplicar una de las posibles soluciones que han ido adquiriendo a lo largo de las tiradas. Es importante tomar en cuenta que para que una historia pueda considerarse terminada (Done) no debe tener puntos por hacer y no debe tener ningún bloqueo.
Resolución de problemas en la daily

Revisión de sprint y retrospectiva: Después del tercer día el equipo realiza la revisión del sprint, con base en el tablero, comparando historias planificadas versus historias terminadas, y luego realiza una retrospectiva para reflexionar sobre la forma en la que han trabajado, y acordar acciones concretas que puedan mejorar su forma de trabajar en el siguiente sprint.

Debrief: Después de tres sprints la ejecución de la simulación finaliza y es momento de analizar los aprendizajes: planeado versus real, variaciones en la velocidad, riesgos que sucedieron (técnicos, de personas, eventos no planeados, ...)...

La simulación en su versión original se diseñó para jugarla de manera presencial, y la web de Scrum Card Game ofrece varias alternativas para comprarlo.
Tablero descargable y fichas que se pueden comprar para jugar en presencial

Timofey Yevgrashyn, el autor, da opción a descargar el manual de la versión de IT (software) de forma gratuita. Esta incluye el set de fichas para poder imprimirlas para poder jugar la simulación en presencial. Podéis encontrar el manual descargable en este enlace.

Finalmente quiero invitar a quién se decida a jugar esta simulación que eche un vistazo al video "How to play Online Scrum Card Game" en YouTube y a que comparta su experiencia en los comentarios de este post.
Partida de Scrum Card Game en un curso on-line de Scrum Manager - Gracias a todos!!!

jueves, 12 de noviembre de 2020

¿Qué dinámica se puede utilizar para trabajar la definición de hecho (DoD) en remoto?

DoD Kards de Thomas Wallet y Camilo Velásquez
Imaginemos que nuestro ámbito es el desarrollo de software y que tenemos un equipo disperso recién formado y necesitemos ayudarles a definir su lista de definición de hecho (DoD). O puede que tengamos un equipo ya formado que necesite refinar su DoD, y en ambos casos necesitamos hacerlo de forma remota.

Thomas Wallet y Camilo Velásquez han ideado un taller basado en un juego de cartas, las DoD Kards, que está disponible en el área de recursos de Kleer, y que nos pueden ayudar:

"Es un juego de cartas cuyo objetivo es reflexionar y consensuar entre todos los miembros de un equipo cuáles son los criterios a incluir en su definición de terminado (DoD por su sigla en inglés: Definition of Done)."

El juego propone cartas con criterios de DoD en los ámbitos de revisión, calidad, entornos y difusión, tanto predefinidas como personalizables. El taller consiste en distribuir esas cartas de criterios de DoD de forma colaborativa en tres columnas (mi recomendación es al menos una carta de cada ámbito):
  • , para los criterios que queremos incluir a nuestra DoD a partir de ahora.
  • AÚN NO, para los criterios que no podemos incluir por el momento pero que queremos reconsiderar en el futuro.
  • NO, para los criterios que no aplican, no entendemos, no queremos incluir en nuestra DoD o para los cuales no logramos ponernos de acuerdo.
La actividad y las conversaciones que se producen durante el taller, entre los miembros del equipo de desarrollo y con el Propietario del Producto, crean alineamiento y una definición única de lo que significa "hecho".

En la cabecera del tablero están las instrucciones del juego, que básicamente sugiere que los asistentes muevan de forma rotativa carta a carta a la columna que creen que debe de ir. Antes de rotar a la siguiente persona se comprueba si hay alguien disconforme, en ese caso se le da oportunidad al equipo a conversar alrededor del criterio y a llegar un consenso sobre a qué columna debe de ir la carta. Al finalizar, la columna SÍ contendrá la nueva definición de hecho (DoD) del equipo.
Tablero inicial, como viene por defecto, y después de realizar el taller
Captura del taller de DoD de Scrum Manager
Quisimos averiguar como funcionaría el taller como actividad en un curso de Scrum remoto, así que lo probamos en un curso de historias de usuario de Scrum Manager.

El feedback fue muy esclarecedor: para un curso hay que contextualizar primero el equipo, exponer su madurez en Agilidad y la de la empresa en la que están. Probablemente la empresa tenga políticas que haya que tener en cuenta en la DoD. Por otro lado hay que contextualizar la infraestructura que les rodea. Por ejemplo, no es lo mismo una DoD para un equipo que tenga acceso a pruebas automatizadas que uno que realiza las pruebas de forma manual. Sin contextualizar ocurriría que iríamos a máximos ágiles y todas las cartas se considerarían como SÍ, como criterios DoD.

Mis agradecimientos a Thomas Wallet, Camilo Velásquez y a Kleer por poner a disposición de la comunidad ágil recursos tan valiosos como las DoD Kards. Y mis agradecimientos a los asistentes al curso de historias de usuario de noviembre de 2020 que direon un feedback muy valioso.

martes, 10 de noviembre de 2020

¿Puede tener un Propietario del Producto diferentes posturas?

En este post quiero compartir una descripción general de las posturas malentendidas y preferidas del Propietario del Producto que la Scrum.org incluye en los aprendizajes de Professional Product Owner avanzado. El post se basa en el artículo "Product Owner Stances" de Robbin Schuurman que invito a leer ya que profundiza en cada una de las posturas.

Una de las responsabilidades del rol del Propietario del Producto es, inspirar y motivar a través de la visión de producto, al equipo de desarrollo y a los interesados, potenciando así el propósito del producto de manera que hace entender las necesidades de los clientes. A su vez busca crear las mejores experiencias de usuario en los clientes, buscando las mejores soluciones posibles que sean viables a las necesidades de estos. Para todo ello puede adoptar diferentes posturas que le permiten interactuar en diversos escenarios, con diferentes tipos de interesados y circunstancias, y así maximizar la entrega de valor.

Las posturas se dividen en dos grupos:
  1. Las posturas malentendidas: resume 6 patrones que son usuales en muchas organizaciones que han empezado a trabajar con Scrum y que han llevado a posturas no ágiles. Recordemos que una transformación ágil es un camino de aprendizaje continuo en le que las personas que realizan el trabajo tienen permiso de cometer errores, lo que se considera positivo ya que nos permite aprender y mejorar.
  2. Las posturas preferidas: estas son 6 posturas constructivas, positivas y valiosas que han sido adoptadas por Propietarios del Producto exitosos.
Las posturas de un Propietario del Producto de "Product Owner Stances" de Robbin Schuurman

LAS POSTURAS MALENTENDIDAS


El escritor de historias, o escriba, transcribe ideas e información en nombre de otros; a veces copiando de otro documento, a veces de instrucciones orales de personas que desconocen el formato de historias de usuario, a veces transcribiendo una grabación o notas personales. Se centra en especificar historias de gran nivel de detalle, su pila de producto suele estar perfectamente organizada. las historias en la parte superior son realmente pequeñas, claras, muy especificadas, con diseños detallados y con estimaciones precisas.

Su pila de producto está pensada para evitar que el equipo de desarrollo tenga dudas... y tenga que pensar. Este enfoque tradicional fomenta equipos que quieran historias detalladas para que no se les pueda culpar por construir lo incorrecto, y refuerza la creencia que el Propietario del Producto maximiza el rendimiento del equipo evitando que piensen en otras cosas que no sea codificar. El desperdicio que se produce al utilizar este enfoque es no usar el cerebro de los miembros del equipo para tomar buenas decisiones; sus decisiones están mermadas por no entender la visión más amplia y las necesidades del cliente, y estar inmersos en un entorno que no fomente la proactividad y el pensamiento.

También conocido como scribe (escriba), secretary (secretario), business analyst (analista de negocio), technical writer (redactor técnico) y note taker (tomador de notas).


La postura del jefe de proyecto es la que se centra en el progreso del día a día del equipo de desarrollo: asiste a todas las reuniones diarias y mengua la autonomía del equipo convirtiendo la reunión en una reunión de seguimiento preguntando a los miembros "qué han hecho", "qué van a hacer" y "si hay algo que les bloquee". Suele medir el éxito del equipo en forma de más velocidad, a poner el foco en los puntos de historia hechos, burn-down charts y la utilización de recursos, pretendiendo maximizar resultados, lo que no es lo mismo que ofrecer más valor al cliente, a los usuarios y a la organización.

También conocido como velocity maximizer (maximizador de velocidad), resource utilization maximizer (maximizador de utilización de recursos), wishlist administrator (administrador de la lista de deseos), sidekick to management (compañero de administración) y progress reporter (reportero de progreso).


El experto en la materia, o SME, es un experto en explicarle al equipo cómo funcionan las cosas. El Propietario del Producto que adopta esta postura es una bendición y a la vez una maldición, ya que por un lado aporta conocimiento de dominio relevante al equipo lo que les permite tomar mejores decisiones y crear mejores planes para lograr los objetivos del sprint, y por otro lado mengua la autoorganización del equipo limitando el aprendizaje y la obtención de conocimiento de negocio, usuarios, cliente y producto, porque les es muy fácil preguntar al experto en la materia.

También conocido como senior user (usuario senior), key user (usuario clave), process manager (administrador de procesos), domain expert (experto de dominio) y business expert (experto en negocio).


El liderazgo al servicio es importante para las organizaciones ágiles, sin embargo el liderazgo al servicio no trata de ser un sirviente. Un Propietario del Producto sirviente trata de complacer a los interesados y nunca les dice "no", simplemente toma pedidos y actúa como mediador con el equipo de desarrollo. Se trata de un Propietario del Producto que no tiene ningún poder y que no está enfocado en lograr la visión del producto, ni en la elaboración de metas y objetivos claros. Su pila de producto suele ser larga y desordenada desde el punto de vista de valor de negocio, y no suele interactuar con el cliente y los interesados externos.

También conocido como admin (administrador), secretary (secretario), waiter (camarero), yes man (hombre del si) y order taker (tomador de pedidos).


El Propietario del Producto portero es aquel que actúa de único punto de contacto entre el equipo y el mundo exterior, bloquea todas las conexiones entre el equipo de desarrollo y los interesados, toda comunicación debe de pasar por él. Piensa que con esta postura ayuda al equipo a mantenerse enfocado, pero su postura le convierte en un cuello de botella, y por tanto suele tener poco tiempo para el equipo. Su enfoque de control hace que quiera que toda idea, deseo y demanda sea en forma de historia de usuario, y que quiera aprobar cada uno de esos requisitos para que al equipo los construya solo enfocado en codificar. El resultado es un bloqueo total del feedback de interesados a equipo, incluso suele haber una merma significativa del feedback en la revisión de sprint.

También conocido como protector (protector), guard (guardia), shield (escudo), gateway (puerta de enlace) y single point of contact (punto de contacto único).


El Propietario del Producto gerente se preocupa por el bienestar de su equipo, le encanta ver personas felices, comprometidas y motivadas que se están desarrollando, aprendiendo nuevas habilidades, obteniendo nuevos conocimientos y cometiendo errores. Es el responsable de la gestión del desempeño y la evaluación del equipo. Todo esto está bien, el problema es que es una postura que no está enfocada en el desarrollo de producto y maximizar el valor del mismo.

También conocido team boss (jefe de equipo), team lead (líder de equipo), technical lead (líder técnico), Product Owner & Scrum Master y HR-responsible person (responsable de RRHH).

LAS POSTURAS PREFERIDAS


El Propietarios del Producto visionario comunica e inspira claramente la visión del producto, la estrategia, las metas y los objetivos comerciales a todas las partes relevantes, su enfoque es en lo que puede ser en lugar de lo que es. Adoptar la postura visionaria de vez en cuando es clave para maximizar el valor del producto y una forma de ver el valor como contribución potencial para lograr la visión.

Este Propietarios del Producto se compromete personalmente con la visión. Es como si la visión estuviera dentro de el. Tiene gran imaginación y capacidad de visualización, tiene voluntad de compartir la visión con el mundo porque sabe que no puede llegar al destino solo. Necesita a otros para este viaje y, por lo tanto comunica su visión y sueños a otros para atraer a las personas adecuadas. Con una visión sólida sabe que habrá desafíos en el camino, nunca se rinde y sabe que los fracasos son parte del proceso de aprendizaje.

También conocido como inspirator (inspirador), challenger of the status quo (retador del status quo), the dreamer (el soñador) e imaginative product owner (Propietario del Producto imaginativo).


Un Propietario del Producto colaborador interactúa y trabajar estrechamente con los interesados y el equipo de desarrollo, apoyando a las personas en su propio proceso de descubrimiento, ya sea para definir objetivos, aclarar historias o analizar las necesidades del cliente.

Es abierto y transparente, comparte abiertamente información que pueda ser o no ser relevante para interesados y equipo, generando así gran confianza. Trabaja en equipo y entiende qué significa colaborar con personas, habla de "todos" nosotros y se pregunta qué está contribuyendo a la relación con los demás y al bien común. Escucha para comprender, no para responder, y sabe mantenerse fiel a su yo auténtico. También entiende que, si como Propietario del Producto desea maximizar el valor de su producto, ha de ser amable con aquellos que construyen el producto y con aquellos que lo consumen.

También conocido como team player (jugador de equipo) y team worker (trabajador de equipo).


El Propietario del Producto representante del cliente es la persona a la que recurren aquellos que deseen comprender qué buscan los clientes y los usuarios en el producto, cuáles son sus desafíos, y qué dolores y ganancias tienen. Al adoptar la postura de representante del cliente es capaz de explicar cómo nuestro trabajo impacta a los clientes. y poder expresar lo que los clientes valoran y cómo calificar y cuantificar ese valor.

Tiene una comprensión clara de las personas del cliente y del usuario, y comprende muy bien que escuchar al cliente es mucho más importante que hablar con el. Tiene reuniones periódicas con clientes y usuarios reales para identificar las necesidades de éstos observando y haciendo preguntas poderosas. La creación de un gran producto, que a los clientes les encante, no se logra haciendo preguntas sencillas, sino con preguntas poderosas que tratan de comprender realmente a los clientes y a los usuarios.

También conocido como customer advocate (defensor del cliente), voice of the customer (voz del cliente), user representative (representante del usuario), user advocate (defensor del usuario) y voice of the user (voz del usuario).


El Propietario del Producto tomador de decisiones ayuda a los interesados y al equipo a reducir el time-to-market reduciendo el tiempo de toma de decisiones que ocurren a diario; algunas las delega al equipo o interesados, otras las toma él mismo. Decide qué historias añadir a la pila de producto, como priorizarla y qué elementos eliminar, toma decisiones sobre la visión y estrategia del producto y cuándo lanzar el incremento de producto al mercado. Al contrario del escritor de historias, evalúa varias opciones y toma una decisión racional que ayude al equipo, a los interesados y al producto en general. Favorece las decisiones en las que todos estén de acuerdo, pero puede tomar las decisiones difíciles cuando sea necesario.

Otro rasgo clave de un Propietario del Producto tomador de decisiones es el uso de datos; conoce el valor de mercado de su producto, el tamaño del mercado que podría comprar el producto, y el de la competencia, ingresos, costos, crecimiento, cadena de valor, ..., los conoce y puede respaldarlos con números.


Al adoptar la postura de un experimentador este Propietario del Producto enuncia hipótesis y suposiciones, en lugar de historias de usuario y requisitos. Ven el trabajo que hace el equipo como experimentos para descubrir valor nuevo y oculto, en lugar de ejecutar y entregar paquetes de trabajo "inamovibles". El experimentador comprende que hay más cosas desconocidas que conocidas y, por tanto, siente la necesidad de probar cosas nuevas, explorar, innovar y experimentar. Es optimista sobre el futuro y siente el impulso de hacer que el mañana sea mejor que el hoy. No le teme a los fracasos porque sabe que estos son parte del proceso de aprendizaje.


El Propietario del Producto que es un gran influenciador logra que las cosas se hagan sin ejercer una autoridad formal sobre el equipo. Los grandes influenciadores actúan y hablan de tal manera que apenas se les nota cuando están presentes, pero se les echa mucho de menos cuando se van. Ayuda a los interesados y al equipo a alinearse en torno a la visión, estrategia, metas y objetivos del producto. Utiliza habilidades efectivas de comunicación, negociación e influencia para lograr que las personas se unan a la causa. Es honesto, siempre abierto y transparente, generando credibilidad y confianza, que son la base para evocar la confianza y el respeto de quienes le rodean. Es flexible y excelente oyente para comprender los diferentes intereses de la organización.

lunes, 2 de noviembre de 2020

¿Cómo preparar una PI Planning remota?

Hoja de ruta hacia la PI Planning
cortesía de Pixabay
Hemos hecho el taller de identificación del flujo de valor operativo (Operational Value Stream) y el del tren (ART)... estamos listos para preparar la PI Planning remota que se nos avecina, y lo primero que ya hemos hecho es marcar la fecha del evento. En este post quiero mostrar una guía de cuando hemos de prestar atención a qué tareas para crear una hoja de ruta que nos lleve a maximizar el éxito de la PI Planning.

Al menos 2 meses antes:
Mes y medio antes:
Un mes antes
2 semanas antes (iteración IP en caso de venir de un PI)
Ejemplo de hoja de ruta de preparación para una PI Planning remota - cortesía de Pixabay