Establecer relaciones de trabajo positivas entre el responsable del producto y el equipo de la retrospectiva ágil

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, unos objetivos alineados y la 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 hasta qué punto ese proceso resulta fluido y sin complicaciones.

Queríamos saber más, así que salimos en busca de 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 el apoyo 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 Product Owner, 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 metodologías ágiles 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ó «por qué» —

Uno de los aspectos importantes de ágil es que no se trata de ser rápido, sino de ser flexible, lo que conduce a un mayor éxito, como, por ejemplo, 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 en la esencia de un 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 precisamente 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 resulta realmente valioso».

Adam puso como ejemplo a dos miembros de un equipo con los que no se hablaban, 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 profundizando, indagando 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 de relieve el problema, 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 horarios de trabajo diferentes. 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; por eso, Adam se propone trabajar de forma conjunta.

«Si hago algo, quiero hacerlo con usted, no a usted. Ningún cambio tendrá éxito si lo hace usted solo».

«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 la conversación. La forma en que se desarrollen 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 dialogar 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 disciplinado 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 potenciación 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 responsable de producto en un proyecto en el que había 23 equipos y en el que predominaba la mentalidad de superar este sprint, luego otro sprint, y otro más, y así sucesivamente; simplemente superar el sprint como pudiéramos».

«A partir de entonces, empezamos a ser más disciplinados en el sprint».

«Sí, el primer mes fue complicado 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 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 se encontrarían con problemas.

Entonces, ¿qué debería ocurrir 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 reunión de revisión de productos, por ejemplo, si los asistentes empiezan a hablar de una solicitud concreta, hay que volver a centrar la atención en el motivo por el que estamos celebrando esta reunión y en el objetivo que pretendemos alcanzar como resultado de dicha sesión».

Por supuesto, el Scrum Master contribuye a mantener esta disciplina.

En lo que respecta a su enfoque retro, 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 qué sala o qué tecnología están utilizando. Su atención se centra en el problema en sí».

Fomente el desarrollo de su equipo a medida que este crea 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 función del Product Owner, con el apoyo del Scrum Master, fomentar esa 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 ofrecer 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 con una alineación firme. De ese modo, todos sabemos hacia dónde nos dirigimos y permitimos que el equipo llegue hasta 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í pues, 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 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 el equipo pueda desarrollar y valorar esas habilidades.

«Creo que el equipo desea que el PO sea sincero y se muestre abierto a la hora de participar».

En cuanto a lo que un Product Owner espera conseguir en una retrospectiva, la respuesta de Adam es sencilla: que el equipo mejore en lo que hace.

¿Por qué?

«Dado que el PO 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 alcanzar dichos resultados. Por lo tanto, un Product Owner inteligente asistirá a la retrospectiva para escuchar. No dirá a los miembros del equipo qué deben hacer, ni que deben hacerlo «de esta manera». Si el equipo ya lo supiera, ya lo habría hecho».

Adam considera que la retrospectiva es una oportunidad para que el equipo: –

1. descubra soluciones
2. ir descubriendo las cosas sobre la marcha para convertirse en un equipo de alto rendimiento y
3. para ascender en la escala de madurez.

El Product Owner desea contribuir a la creación de un equipo de alto rendimiento por numerosas razones:

1. para mejorar la previsibilidad
2. contar con una gestión de historias de usuario eficaz, sólida y sistemática
3. para mejorar la confianza y la calidad en general

a medida que se van desarrollando nuevas funciones con el tiempo.

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 el cambio porque se les está imponiendo algo y no sienten que tengan el control.

«Algo a lo que hago referencia en De “No” a “¿Cómo?” es el concepto de esfera de influencia y los focos de control. Es importante ayudar al equipo a centrar sus conversaciones en dónde se encuentra su foco de control, de modo que se sientan empoderados y capaces de introducir cambios».

«Deberían sentir que pueden contar con el responsable de proyectos 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 destino, entonces puede cambiar su realidad 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 responsable de producto ayudar a un equipo a evitar la disfunción

No podíamos dejar que Adam se marchara sin pedirle consejo sobre cómo lograr que un equipo pase de ser disfuncional a alcanzar un alto rendimiento.

Conclusiones clave:

1. Asegúrese de que todos sepan adónde se dirigen, cuál es su objetivo, y de que todos estén en sintonía.
2. 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.
3. ¡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 que las personas den lo mejor de sí mismas.
4. Explíqueles siempre el «porqué»
5. Ponga de manifiesto las disfunciones. Identificar problemas, conflictos y errores es muy positivo, ya que significa que se ha descubierto algo.

¿Tiene alguna otra reflexión o alguna experiencia que quiera compartir sobre cómo ha mejorado las relaciones de trabajo entre su equipo Scrum y el responsable de producto? Nos encantaría que las compartiera con nosotros.

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

Comience su prueba gratuita de 30 días