Esta es la transcripción de la entrevista realizada por Adolfo Foronda hace unas semanas sobre cómo un Propietario de Producto (Product Owner) puede transmitir eficazmente un mensaje NO. 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: ¿Dónde estás? ¿Estás en Nueva Zelanda ahora mismo?
Erich: Sí, estoy en la ciudad de Auckland.
ADOLFO: Guau. He oído que es maravilloso allí …
Erich: Sí, excepto en invierno, ja, ja, ja
ADOLFO: Muy bien. Bueno Erich vamos a profundizar en el tema.
Erich: ¡Bien!
ADOLFO: Uno de los mayores trabajos para un Product Owner es decir NO, metafóricamente o literalmente. Dime en tu experiencia la frecuencia con que ves a un Product Owner decir no, ya sea a un CEO, V.P. u otro tipo de persona dentro de la empresa… ¿Cómo debería hacerlo y cuáles son los resultados deseados?
Erich: Bueno, ¡eso es una pregunta interesante!
Lo primero que necesitamos entender es lo que NO significa. Es diferente en una organización Agile que en una organización tradicional.
«NO» en una empresa tradicional probablemente significa que no podremos tomar esa idea a bordo. Y si hablamos de requisitos técnicos, significa que no lo vamos a hacer. ¡Simple!.
Así que si estamos hablando de una nueva idea …. significa que no vamos a hacerla o que no la vamos a tomar en cuenta.
Las empresas tradicionales están basadas en planes, por lo que es más difícil tomar cambios a bordo, especialmente si estamos en medio de un año fiscal. Probablemente ya lo sabes…
También necesitamos entender algunas de las características básicas de las compañías ágiles o modernas y decir NO es una habilidad crucial especialmente para los Product Owner.
Imagínate que alguien pide algunos requisitos, algo que desea agregar a tu producto … centrémonos en esa nueva solicitud.
Entonces, ¿cómo podemos decir NO de hecho sin decir NO en absoluto?
Para esto, necesitamos entender cómo funciona Agile y cómo funciona SCRUM y KANBAN, así como funciona la visión y hoja de ruta (roadmap).
En primer lugar, cuando hablamos de una empresa Agile, necesitamos contar siempre con una visión clara de nuestros productos. Y aquí estamos hablando de una visión que es compartida y entendida por todos los empleados y a su vez, es inspiradora.
Muchas veces, cuando vemos un requisito que no cumple realmente con la visión actual, necesitamos hacer algo … y en Agile tenemos dos opciones claras.
#1
Se trata aquí de decir que NO cumple con la visión actual y pedir a la persona que revise la solicitud y regrese con una idea diferente o una nueva, por ejemplo.
#2
Se trata simplemente de cambiar la visión. Si la persona quiere tomar eso a bordo y no cumple con la visión, entonces la segunda opción es cambiar la visión del producto.
Pero cambiar la visión no es tan fácil. Es probable que tengamos que organizar un taller, invitar a todos los interesados (stakeholders), Product Owner tiene que estar allí, el equipo y necesiten tener consenso sobre la nueva visión.
A menos que sea alguien con mucho poder dentro de la empresa, digamos que sea el CEO quien pide el requisito, entonces probablemente no se sienta cómodo con la situación y trate de cambiar la solicitud inicial.
Como regla general, normalmente no cambias tu visión sin revisar la estrategia actual.
Así que realmente no necesitas decir que no, pero necesitas asegurarse aquí que la solicitud cumpla con tu visión.
También tenemos un escenario que es ligeramente similar que está relacionado con la hoja de ruta (Roadmap). Alguien de nuevo pide algo pero que no cumple con las metas definidas en la hoja de ruta.
Así que imagínate que la solicitud no cumple con tu hoja de ruta actual.
Las compañías revisan sus hojas de ruta cada pocos meses así que … probablemente tendría que esperar a la próxima revisión para ver si se va a cambiar la dirección en la que se va.
Y la situación es similar a lo que mencioné anteriormente.
#3
El tercer escenario es donde algo realmente cumple con tu hoja de ruta y la visión, por lo tanto, no puedes decir NO.
Aquí tienes de nuevo un par de opciones
DILE NO y explica el por qué. ¡Siempre necesitas explicar por qué dices que no! Ya que de lo contrario deberás adicionarlo a la pila del producto (Backlog). Un Product Owner bueno conoce muchas técnicas para priorizar lo que se pone en un Backlog.
Debe ser fácil para el Product Owner explicar por qué la característica se va a poner al final, en el medio o será de prioridad alta.
Un par de semanas atrás enseñé a un grupo de Product Owners diferentes técnicas para priorizar un backlog. Teníamos aproximadamente 10 técnicas diferentes para hacerlo.
En la primera parte, he explicado 3 escenarios diferentes sin tener que decir NO, pero hay algunas situaciones específicas en las que hay que decir NO. ¡Es parte de tu trabajo!
Tenemos que entender bien el rol del Product Owner, ya que el PO es la persona responsable de la entrega de valor y cualquier cosa que bloquee la entrega de valor de negocio tiene que ser eliminada tan pronto como sea posible de la cadena de valor.
Por ejemplo, si un Product Owner ve un aumento en la complejidad en la organización … digamos que alguien agrega nuevas reglas o tal vez está dispuesto a cambiar la organización de una manera que va a disminuir el valor del negocio producido por el equipo/equipos, ello tiene que ser detenido lo más pronto posible.
Creo que aquí es la única opción decir NO si ves a alguien añadir nuevas reglas. Veo esto específicamente en las empresas tradicionales utilizando Scrum.
Allí, todo el mundo quiere un nuevo informe, añadir nuevas reglas, etc, etc, etc o nuevas métricas, por ejemplo.
¡Tenemos que decir que no!
El segundo escenario aquí está relacionado con comportamientos que básicamente van en contra de los valores del equipo o los valores de la organización.
Como ejemplo, podemos ver que alguien quiere medir los equipos de una manera que no es ágil y que va a afectar a toda la red de valor. Cuando decimos la red de valor, estamos hablando los procesos y personas incluidos desde que a alguien se le ocurrió una idea hasta que el cliente la tiene en sus manos.
He visto esto un montón de veces, por ejemplo, a los jefes pedir de estar durante una retrospectiva, por ejemplo, o el CEO que quiere también estar en la reunión de retrospectiva.
¡Aquí tienes que decir que no!
Si no detienes este tipo de comportamiento, entonces nunca llegarás a un punto en el que tu o tu equipo se sienta seguro.
El último escenario es cuando tienes actividades de baja prioridad. Tu puede ver que los Product Owner generalmente tienen un montón de reuniones que consumen mucho tiempo.
Es realmente importante decir NO a este tipo de actividades, ya que absorben en general mucho tiempo. Sé que es difícil decir NO si el requisito viene del CEO, pero tu tienes que tener comportamientos consistentes.
El primer grupo de acciones que hemos visto están relacionados con cuando dices NO sin decir NO y están todos vinculados con las características del producto. Tu puedes allí decir no sin decir de hecho NO.
Simplemente utiliza todo el ecosistema SCRUM y AGILE como la visión, la hoja de ruta (Roadmap), el backlog y sus dinámica.
La segunda está relacionada con comportamientos. Aquí es muy importante que digas NO y tienes que practicarlo.
ADOLFO: ¿Entonces dirías que es raro decir NO?
Erich: Sí, es raro decir que NO ya que les resulta realmente difícil.
Hoy vamos a ver un par de técnicas que van a ayudar a Product Owners a comunicar el NO.
ADOLFO: Erich ¿cómo ayudas a los Product Owners a aprender a comunicar las noticias de NO a las figuras de autoridad?
Erich: Bueno, en mi experiencia, si estás pasando de ser una organización tradicional a una Agile, hay mucha fricción.
He visto a muchos gerentes no entender muy bien el papel de Product Owner y eso crea muchos malos entendidos.
En general, cuando estoy ayudando a las empresas, ello es una de las primeras cosas que hago. Tu debes ayudar a la gerencia intermedia a entender bien el rol.
Lo que trato de asegurarme es que cuando se tienen Product Owners también se tienen Scrum Masters, la gerencia intermedia y el patrocinador de la iniciativa reforzando la visibilidad y el rol.
Y eso es algo muy importante. Por lo general, tu necesitas obtener un gran apoyo de todas estas personas de alrededor. En mi experiencia, también es diferente basado en el país en donde estés.
Por ejemplo, cuando tienes un problema en Nueva Zelanda con un escenario en el que nadie entiende muy bien el rol del PO, allí a la gente le gustan las historias.
Tienes que decirles lo que el rol hace en términos de historias, en otros países están más orientados a números y hechos y por qué el rol funciona de esa manera.
Depende realmente del país, por ejemplo, lo que hago si estoy trabajando en España o en América del Sur o incluso en América, entonces trato de ir por los hechos.
Yo diría allí «la razón por la que trabajamos de esta manera es porque … por qué el rol es de esta manera …» y yo intentaría explicar lo que queremos lograr. También intentaría mostrar, por ejemplo, el informe CHAOS que muestra algunos números y hacer entender en primer lugar por qué tenemos ese rol.
Recuerda, si estas en Australia o en Nueva Zelanda, necesitarás historias. Tendrás que decirle a la gente historias que experimentaste para explicar por qué no deberían tener miedo de comunicar un NO.
Pero en todo caso, la gente necesita sentirse segura y bien apoyada. Hemos dicho antes cuando tenemos nuevos Product Owners, necesitamos asegurarnos de tener a Scrum Masters y especialmente a la persona que apoya la iniciativa, con el fin de asegurarse que cuentas con las estructuras que apoyan a ese Product Owner.
La gente tiene que sentirse segura aquí.
Una forma de transmitir un NO es por lo general asegurándote de que antes de tratar de transmitir el NO, tienes una conversación con el patrocinador de la iniciativa y cuentas con estructuras de empresa que te apoyan (¡y que todo el mundo entiende muy bien lo que está sucediendo!).
En algunas organizaciones, por ejemplo, después de tomar una decisión NO, ellos la discuten en la reunión de Scrum de Scrums con la gerencia para que todo el mundo entienda lo que está sucediendo y que puedan apoyar adecuadamente al Product Owner.
ADOLFO: ¿Puedes compartir algunas de las técnicas y enfoques que usas para transmitir el mensaje de que algo NO es posible?
Erich: Claro… si estamos usando el SCRUM, a veces se puede transmitir un mensaje utilizando los artefactos, como el burn-up o burn-down, el gráfico de velocidad. Ellos apoyan buenas conversaciones.
Un escenario típico es cuando el equipo no puede terminar con las historias de usuario, por ejemplo, y el propietario del producto debe decir a las partes interesadas (stakeholders) que no fueron capaces de terminar con ellas. Eso es un mensaje NO obviamente.
Tenemos que asegurarnos aquí que trabajamos con diferentes técnicas para mejorar la visibilidad. Podemos utilizar tableros Kanban, podemos hacer que el progreso sea visible, podemos hacer visible la deuda técnica y asegurarnos de que todo el mundo la entiende y por supuesto saber leer estos gráficos para ayudar a transmitir la información correctamente.
Tanto como sea posible, NO UTILICES CORREOS ELECTRÓNICOS para informar
ADOLFO: Eso es correcto.
Erich: Recuerdo hace mucho tiempo una compañía con muy poca visibilidad donde el primer día que fui, cancelé mi cuenta de correo electrónico para que todos tuvieran que hablar conmigo. Funcionó muy bien.
Y de hecho, algunas personas podrán decir … ¿cómo vas a interactuar con las personas que están remotas?
Bueno … usando skype y comunicación cara a cara.
Voy a compartir con ustedes algo muy importante… tuve una conversación con Stefan Sohnchen, que es un Agile Coach aquí en Nueva Zelanda. Estábamos conversando sobre 8 puntos importantes acerca de la transmisión de un mensaje NO, por lo que LEE ATENTAMENTE:
#1
El decir NO requiere que aceptes que decir NO puede ser una cosa difícil para ti, pero también es algo difícil para los demás.
#2
No te hace una mala persona. No hay razón para sentirse culpable. Esto es una cosa muy importante… ¿verdad?
#3
No es cruel ni una cosa cruel.
#4
No eres grosero, poco profesional o rudo.
#5
Si ese es el caso, trata de crear algunos acuerdos de trabajo (Woking Agreements) con las personas de tu alrededor para asegurarse de que apoyen tu NO.
Si la gente no se siente cómoda diciendo NO, entonces necesitas ver por qué. Quizás sólo necesites crear acuerdos de trabajo para que la gente se sienta segura, ¡y eso es algo muy importante!
#6
Decir NO es parte de aceptar el poder y la importancia de ser un Product Owner. ¡Esto es algo que necesitas practicar!
#7
Cuando tu tienes miedo de decir NO, probablemente estás alimentando un anti-patrón que generalmente vemos en las compañías que se llama «enfermedad de satisfacer» (“disease to please”).
Si tienes hijos, aprenda lo fácil que es decir NO, especialmente si tienen menos de cuatro años de edad, y trata de prestar atención de por qué los niños mayores generalmente no dicen NO.
Y la última parte que es muy importante …
#8
Evita estar cansado o enfermo ya que las personas asociarán ello con la respuesta.
Lo más importante aquí es distinguir entre la persona que hace la solicitud y los atributos de la solicitud que se está realizando.
Siempre puedes cambiar de opinión durante el «viaje».
En mi experiencia, es una buena idea practicar … ¡no te rías de lo que diré! … delante del espejo.
ADOLFO: Sí, por supuesto. Así es como lo hacen los actores y otros…
Erich: Si.
Yo personalmente recomiendo a los Product Owner hacerlo. Si tu estás trabajando en pares, por ejemplo, puedes pedirle a la otra persona que te dé retro-alimentación.
Y recuerda … si tu dices NO, estate listo para hacer una contra-oferta.
Y no olvides que siempre debes transmitir un mensaje NO en un ambiente donde te sientas seguro.
Hay un libro muy bueno que, no sé si has oído hablar de él, es de Patrick Lencioni llamado «The advantage«.
ADOLFO: No, no lo conozco.
Erich: Es un buen libro y voy a compartir el marco de trabajo que propone. Es para hacer organizaciones saludables… y lo voy a compartir forma gratuita.
Recomienda básicamente ciertas acciones repetitivas para asegurar que la organización crece de una manera saludable y que apoya tu NO.
La primera consiste en construir un equipo de liderazgo cohesivo.
Si tu estás especialmente en una transformación organizacional y tienes Product Owners nuevos, trata de asegurarte de que hay un equipo de liderazgo apoyándolos, de lo contrario, nadie va a apoyar sus NO.
La segunda consiste en crear claridad. Cuando tu dices NO, asegúrate de que todo el mundo entiende por qué, asegúrate de que tienen los comportamientos adecuados y trata de que si no hay unos buenos comportamiento, entonces habla con el patrocinador de la iniciativa.
La primera parte de este marco es acerca de la claridad de comunicación. Así que asegúrate de que el mismo mensaje se repite una y otra vez y una y otra vez y los buenos comportamientos como he dicho, tienen que ser coherente con tus comportamientos.
Esto se trata de reforzar la claridad.
Aquí puedes utilizar todas las técnicas de SCRUM y todo lo que tengas a mano para asegurarte de que mejorar la visibilidad
Realmente lo recomiendo si todavía no has leído, es una gran oportunidad para que te asegures de que entiendes cómo funciona una organización saludable.
Siempre quieres que si tienes que decir NO sea en una organización sana.
¿Quieres sentirte seguro cuando dices que NO, no?
ADOLFO: Erich, para los oyentes y para todos, ¿dónde podemos obtener más información sobre ti y lo que estás haciendo?
Erich: Me pueden contactar en LinkedIn en ERICH BUHLER or innova1st.es y podemos esta en contacto.
Siempre estoy apoyando comunidades en América Latina principalmente y ahora en Nueva Zelanda.
ADOLFO: Muchas gracias.
Erich: Muchas gracias a ti Adolfo.
–
Y recuerda, si necesitas conocer más sobre como potenciar equipos Scrum y Ágil dentro de tu empresa, visita nuestro sitio Web.
https://www.meetup.com/madriagil/events/241904692/
