Creación de relaciones de trabajo positivas entre el propietario del producto y el equipo de retrospectiva ágil
Formas prácticas para que los propietarios de los productos y los equipos de scrum generen confianza, clarifiquen las funciones y lleven a cabo mejores retrospectivas: herramientas, agendas y correcciones.
La relación entre el Product Owner, los Scrum Masters y los desarrolladores es fundamental para el éxito de un equipo ágil. Se trata de una relación simbiótica que se basa en una comunicación clara, objetivos alineados y transparencia, y que se sustenta en la confianza. El objetivo habitual es crear un producto que goce de una amplia aceptación o lograr una mejora continua, pero la cohesión y la dinámica del equipo pueden determinar lo fluido y sencillo que resulte ese proceso.
Queríamos saber más, así que salimos a buscar a un Product Owner para que compartiera sus ideas y experiencias.
Tras su presentación sobre la hoja de ruta de productos en el Perth Agile MeetUp, nos reunimos con Adam Mullett, autor del libro De «no» a «¿cómo?»: cómo conseguir la aceptación y liderar el cambio y Product Owner, para preguntarle cuál es su opinión sobre el grado de participación que debe tener un Product Owner en una retrospectiva.
Lo que obtuvimos fue algo más que una simple respuesta a una pregunta: fue una demostración del papel del Product Owner y una nueva apreciación de la confianza, la transparencia y la disciplina.
La relación entre el responsable de producto, los scrum masters y el equipo ágil
Adam pareció algo desconcertado cuando se le preguntó si el Product Owner debía participar en la retrospectiva.
La pregunta surgió a raíz de la observación de que algunas personas involucradas en el método ágil consideraban que la presencia del Product Owner en la retrospectiva era opcional, o incluso un obstáculo.
Tras una breve pausa, su respuesta fue un rotundo «¡sí!».
A continuación, explicó el «porqué» –
Uno de los aspectos más importantes de ágil es que no se trata de ser rápido, sino de ser flexible, lo que conduce a un mayor éxito, como una mejor aceptación del producto.
A la hora de dirigir las retrospectivas de un equipo, no solo es importante facilitar el proceso, sino que resulta igualmente importante gestionar la cultura. El equipo depende en gran medida de la orientación y las aportaciones del Product Owner, en su calidad de experto en la materia. El Product Owner fomenta un entorno en el que el equipo puede esforzarse por alcanzar un alto rendimiento, asumir la responsabilidad de los resultados y autogestionarse, de modo que siga rindiendo cuentas ante sus partes interesadas.
Confianza y transparencia
Adam considera que la confianza y la transparencia son elementos fundamentales para la esencia del Product Owner.
«Para mí, ser transparente es un don, porque implica compartir lo que uno piensa o lo que sabe. Si el equipo no consigue que usted se abra, entonces no les está dando lo que necesitan para alcanzar el éxito».
«No debería haber secretos entre el equipo, el Scrum Master y el Product Owner. En mi caso, me centraría en esos aspectos. Prefiero plantear el problema y afrontar el conflicto antes que dejar que la situación se agrave».
«Poder descubrir qué es lo que impide que un equipo avance es realmente valioso».
Adam puso como ejemplo a dos miembros de un equipo que no se hablaban entre sí en un equipo al que había entrenado en su día.
«¡Era inconcebible! Por eso, si durante la retrospectiva se hacía algún comentario relacionado con el tema, yo seguía indagando, profundizando en el «por qué», hasta que se daban cuenta de que el problema era su falta de comunicación».
Aunque el enfoque fue algo conflictivo, una vez que se puso el tema sobre la mesa, resultó más fácil abordarlo, y los miembros del equipo se mostraron posteriormente agradecidos de que se hubiera resuelto el asunto.
«Resolver este tipo de problemas podría ser tan sencillo como ofrecer diferentes horarios de trabajo. El hecho de que unos no se dirigieran la palabra a otros no era, sencillamente, una razón válida para no ser un equipo de alto rendimiento».
Involucre a las personas en la conversación
Un Product Owner debe dar prioridad a la colaboración, y por eso Adam apuesta por la cocreación.
«Si hago algo, quiero hacerlo con usted, no a usted. Ningún cambio tendrá éxito si lo lleva a cabo en solitario».
«Dado que la colaboración en equipo es imprescindible para que se produzca la cocreación, es importante saber cómo y cuándo involucrar a las personas en el diálogo. La forma en que se desarrollan las conversaciones puede marcar una gran diferencia».
«Por ejemplo, es más fácil mostrarle a alguien su trabajo que tener que convencerlo. Un prototipo de una hora con el que se pueda interactuar resulta, en ocasiones, mucho más eficaz que una larga sesión de planificación en la que se intenta vender la idea. En otras ocasiones, quizá sea mejor crear de forma conjunta».
Sea riguroso con los procesos y los resultados
Cuando la disciplina se considera una base de apoyo, en lugar de un obstáculo para la flexibilidad, puede actuar como un mecanismo de empoderamiento del equipo.
La disciplina puede consistir simplemente en comenzar una reunión a la hora prevista, terminarla a la hora prevista y tener una definición estricta de lo que significa «estar listo». Se trata de pequeños comportamientos acordados que los miembros del equipo respetan con el fin de mejorar conscientemente la cohesión y el respeto dentro del equipo.
En opinión de Adam, con disciplina se pueden fomentar hábitos saludables que contribuyan al buen funcionamiento de los equipos.
«Yo era el Product Owner de un proyecto en el que había 23 equipos y una mentalidad general de superar este sprint, luego otro sprint, y otro más, y así sucesivamente; simplemente superar el sprint como fuera».
«Entonces empezamos a ser más disciplinados en el sprint».
«Sí, el primer mes fue duro porque intentábamos hacer dos cosas a la vez. Pero a partir de ahí, todo fue sobre ruedas. Y el equipo pudo seguir mejorando y creciendo como un equipo de alto rendimiento. De hecho, otras personas de la organización querían formar parte de ese equipo».
También se observó que los equipos que carecían de disciplina acababan teniendo problemas.
¿Qué debería ocurrir, pues, si los miembros del equipo no adoptaran un enfoque disciplinado?
«Si alguien acude sin estar preparado, es importante dejar claro cuál es el objetivo de la reunión y explicar por qué sus acciones no contribuyen a ese objetivo».
«Se trata de mantener la atención. Durante la sesión de preparación del producto, por ejemplo, si los participantes empiezan a hablar de una solicitud concreta, hay que volver a centrar la atención en el motivo por el que nos hemos reunido y en el objetivo que pretendemos alcanzar con esa sesión».
Por supuesto, el Scrum Master ayuda a mantener esta disciplina.
En lo que respecta a su enfoque retrospectivo, Adam añadió que, una vez que un equipo comprende y valora la estructura que ha creado su disciplina, se muestra mucho más centrado y eficiente, sin necesidad de recurrir al pensamiento del «Sistema 2», tal y como se describe en el libro Pensar rápido, pensar despacio de Daniel Kahneman.
«Contar con un proceso claro facilita las cosas. Los equipos no quieren tener que preocuparse por cuestiones como en qué sala se encuentran o qué tecnología están utilizando. Su atención se centra en el problema en sí».
Fortalezca a su equipo mientras este desarrolla soluciones
En lo que respecta a Adam, no hay ninguna ambigüedad en cuanto al papel del Product Owner; si usted es un Product Owner, forma parte del equipo ágil.
«Creo que es tarea del Product Owner, con el apoyo del Scrum Master, forjar la cultura y aportar claridad al equipo».
«A los equipos les disgusta no saber hacia dónde se dirigen. Se vuelven unos contra otros, se ponen nerviosos, intentan aparentar que están ocupados y se producen todo tipo de disfunciones. Si puede darles a las personas una razón, un «por qué», una dirección estratégica, entonces dirán: «De acuerdo, genial. ¡Entendido!». Así que se trata de mantener una relación flexible pero estrechamente alineada. De esa manera, todos sabemos hacia dónde vamos y permitimos que el equipo llegue allí».
Adam ha trabajado con equipos presenciales, a distancia e híbridos. Durante 18 meses, colaboró con personas repartidas desde Sídney hasta la India. Independientemente de su composición, uno de los factores clave del éxito de un equipo de alto rendimiento era la capacidad de anticipar lo que iba a suceder a continuación.
«Así que, si surgía algo durante nuestra retrospectiva, alguien se encargaba de crear una incidencia en Jira. La gente podía seguir trabajando en equipo aunque no estuvieran siempre en la misma sala. Contar con métodos de trabajo sólidos nos ayudó a adaptarnos a esa situación».
El papel del responsable de producto en una retrospectiva ágil
Volviendo a la cuestión del papel del Product Owner en la retrospectiva, Adam señaló que el Product Owner es un participante.
En su opinión, la propia sesión retrospectiva puede ser dirigida por cualquier miembro del equipo, aunque él prefiere que la moderación se vaya rotando entre los miembros del equipo, de modo que estos puedan desarrollar esas habilidades y el equipo pueda valorarlas.
«Creo que el equipo desea que el PO sea sincero y se muestre abierto durante su participación»
En cuanto a lo que el Product Owner espera conseguir en una retrospectiva, la respuesta de Adam es sencilla: que el equipo mejore en lo que hace.
¿Por qué?
«Porque el Product Owner es responsable ante la organización de los resultados, tanto en lo que respecta al tiempo que ha llevado llevar a cabo una tarea como a los recursos utilizados. El equipo es responsable de obtener dichos resultados. Por lo tanto, un Product Owner inteligente asistirá a la retrospectiva para escuchar. No le dirá a la gente qué hacer, ni que deben hacerlo «de esta manera». Si el equipo ya lo supiera, lo habría hecho».
Adam considera que la retrospectiva es una oportunidad para que el equipo…
- descubra soluciones
- aprender sobre la marcha para convertirse en un equipo de alto rendimiento y
- para avanzar en la escala de madurez.
El Product Owner desea contribuir a la creación de un equipo de alto rendimiento por muchas razones:
- para mejorar la previsibilidad
- contar con una gestión de historias de usuario eficaz, sólida y sistemática
- para mejorar la confianza y la calidad en general
a medida que se van desarrollando nuevas funciones.
Fomente y facilite los cambios en sus reuniones retrospectivas
Entonces, ¿por qué funcionan los estilos retro?
«Creo que se debe a que el equipo tiene la capacidad de proponer medidas que puede poner en práctica. Pueden definir objetivos SMART que puedan llevar a cabo en las próximas dos semanas. Son ellos mismos quienes identifican el problema que les afecta, por lo que el cambio surge de su propia iniciativa».
Se señaló que algunas personas pueden temer al cambio porque se les impone algo y sienten que no tienen el control.
«Algo a lo que hago referencia en De “No” a “¿Cómo?” es el concepto de la esfera de influencia y los centros de control. Es importante ayudar al equipo a centrar sus conversaciones en dónde se encuentra su centro de control, de modo que se sientan empoderados y capaces de introducir cambios».
«Deben sentir que pueden contar con el responsable de producto para aprovechar su influencia o su capital social con el fin de ejercer influencia más allá del ámbito de influencia del equipo».
«Mientras tanto, si un equipo ágil siente que tiene el control de su propio destino, entonces puede cambiar su entorno y hacer que las cosas sucedan. Se siente con más capacidad para actuar y, por lo tanto, puede ponerse manos a la obra y llevar a cabo sus tareas».
Cómo puede un Product Owner ayudar a un equipo a evitar la disfunción
No podíamos dejar que Adam se marchara sin pedirle consejo sobre cómo llevar a un equipo de la disfunción al alto rendimiento.
Puntos clave:
- Asegúrese de que todos sepan hacia dónde se dirigen, cuál es su objetivo y de que todos estén en sintonía.
- Asegúrese de que haya una buena comunicación; ya sea entre los miembros del equipo, entre el Product Owner y el Scrum Master, la comunicación debe ser abierta y sincera.
- ¡Disciplina! Ofrezca a las personas un espacio para la creatividad. Comience a la hora prevista y céntrese en el tema de la reunión. Esto proporciona una estructura que permite a las personas desarrollarse plenamente.
- Explíqueles siempre el «porqué»
- Señale las disfunciones. Identificar problemas, conflictos y errores es muy positivo, ya que significa que se ha descubierto algo.
¿Tiene alguna otra idea o experiencia que quiera compartir sobre cómo ha mejorado las relaciones de trabajo entre su equipo Scrum y el Product Owner? Nos encantaría que nos la contara.
Acerca de Adam Mullett
De «No» a «¿Cómo?»: Cómo conseguir el apoyo y liderar el cambio anima a compartir con los compañeros y con el superior los resultados de los intentos fallidos de mejora, como forma tanto de asimilar la lección como de compartir lo aprendido con los demás.
Pruebe una demostración con nuestros divertidos bots
o