Las conversaciones sobre el método ágil suelen centrarse a menudo en el marco Scrum, con sus reuniones programadas y sus roles definidos. Sin embargo, a medida que la filosofía ágil sigue madurando, ¿está cambiando este enfoque? En esta entrevista, el coach ágil full-stack Jon Fazzaro aborda esta cuestión y otras más.

La cosa empieza con fuerza, ya que Jon cuestiona la idea de basarse exclusivamente en Scrum como punto de partida para la agilidad. En su lugar, aboga por un enfoque más orgánicamente ágil.

A medida que avanza el debate, la reflexión retrospectiva pasa a ocupar un lugar central y se analiza el papel del entrenador.

Por último, se ofrecen ideas sobre el bienestar de los equipos ágiles, junto con consejos muy valiosos para apoyar a su equipo.

¡Empecemos!

Una perspectiva en constante evolución sobre Scrum

He leído su artículo en Medium La retrospectiva es el latido del proyecto. ¿Sigue pensando que es así o diría que hay algo más importante que se debería tener en cuenta ahora?

Desde que escribí ese artículo, he dejado de pensar que Scrum sea la mejor forma de empezar a trabajar de manera ágil si aún no lo hace.

Voy a tomar prestada una metáfora que el director de nuestra empresa, Joshua Kerievsky,, compartió hace un tiempo en una charla que impartió.

Cuando se aprende a montar en bicicleta, se utilizan ruedines. Al menos, así es como lo hacen la mayoría de los niños: llevan unos pequeños ruedines atornillados a los laterales de la bicicleta. Lo primero que aprenden a hacer es pedalear. Por eso, cuando se quitan las rueditas, lo primero que hacen es caerse. No se dan cuenta de que tienen que pedalear hacia delante. No han aprendido a mantener el equilibrio.

Existe una forma alternativa de enseñar a los niños a montar en bicicleta. Se llama «bicicleta de equilibrio». Es muy sencilla. Ni siquiera tiene pedales. Tiene forma de bicicleta, con dos ruedas y un sillín. Y solo hay que decirles que caminen; que avancen andando y vean si son capaces de impulsarse y mantener el equilibrio.

Esa es la mejor manera de enseñar a un niño a montar en bicicleta. Lo difícil es mantener el equilibrio, no pedalear.

Del mismo modo, Scrum es la forma más habitual en que los equipos dicen: «Bien, tenemos que ser ágiles; adelante, adoptemos Scrum». A continuación, se limitan a poner en marcha su «Scrum de principiantes». Dicen: «Estas son las reuniones, estos son los roles y esto es lo que hacemos».

Lamentablemente, en la práctica, Scrum no es suficiente.

No me malinterpreten. Sobre el papel, la guía es muy buena. Contiene muchas ideas excelentes. Pero Scrum no suele hacer lo suficiente para enseñar a un equipo lo que realmente necesita para ser ágil.

El papel de las retrospectivas en los equipos ágiles

Dado que su postura respecto a Scrum y su relación con el método ágil ha evolucionado, ¿qué opina de la retrospectiva?

Sigo creyendo que es importante dejar de trabajar y hablar sobre cómo se está llevando a cabo el trabajo. Creo que eso es lo más importante. Me gusta la idea de celebrar retrospectivas con mayor frecuencia. Para acelerar el ritmo.

El equipo no tiene por qué realizar una retrospectiva intensiva de dos horas todos los días. En su lugar, tal vez bastaría con dedicar media hora al día en un momento concreto, en un abrir y cerrar de ojos. Es posible que descubra antes cosas que son importantes. En lugar de esperar dos semanas para solucionar «eso» y acumular una lista de «otras cosas» pendientes, el equipo puede abordarlo casi de inmediato.

Francamente, eso es más ágil. En lugar de agruparlo todo y esperar.

¿Qué podría significar ese latido cardíaco regular, y posiblemente más rápido, para el equipo directivo de una organización?

Aparentemente, les preocupa que el equipo goce de buena salud y rinda a un nivel previsible. Como responsables del negocio al que presta servicio el equipo, desean poder confiar en que este les proporcione lo que necesitan para alcanzar sus objetivos empresariales.

Si un equipo no se reúne con regularidad y no se coordina, puede volverse impredecible. Es posible que hayan tenido una semana excelente porque todos han trabajado horas extras, pero están agotados. Entonces, durante las tres semanas siguientes, no hacen más que cometer errores y cometer tonterías.

Eso es lo que me importaría en un puesto directivo. Creo que saber eso tiene un gran valor.

El coach ágil y las retrospectivas eficaces

¿Qué indicadores, no necesariamente datos, podría buscar un Scrum Master, teniendo en cuenta que no todos ellos tienen experiencia en desarrollo?

En la retrospectiva, un Scrum Master es, en esencia, su entrenador.

Si recurrimos a una metáfora deportiva, normalmente un entrenador es alguien experto en el juego. Quizá un exjugador. Para ser útil, debe asumir que no puede ayudar a los jugadores participando él mismo en el juego.

La persona que dirige la retrospectiva debe distanciarse del contenido de la conversación. Debe fijarse más bien en el conjunto de la conversación.

Por lo tanto, en realidad podría resultar beneficioso que no comprendieran ciertos aspectos de lo que se está debatiendo, ya que esos aspectos podrían suponer una distracción. Podrían desviar su atención de la forma en que interactúa el equipo. Supongamos que a alguien le interrumpen constantemente. Ahí es donde el entrenador podría intervenir. Podría ayudar a intentar reorientar la conversación.

Aunque el contenido de la conversación pertenece a quienes la mantienen, a veces el desarrollo de la misma no sale como debería. Se necesita a alguien presente que se limite a observar cómo se desarrolla. Se les puede animar a «interactuar» mejor entre ellos.

¿Están contribuyendo a garantizar que el «juego» se aproveche al máximo?

Sí.

Si quieren dar un paso más, ¿qué podría hacer el entrenador?

Bueno, la expresión que me viene a la mente es «mantener el espacio», procedente de la Tecnología de Espacios Abiertos.

Crear un espacio propicio es una tarea en sí misma. Eso es lo que haría un facilitador de una retrospectiva, ya sea un coach o un Scrum Master, independientemente de su cargo. Se trata de facilitar la conversación. Uno no interviene en el contenido, sino que crea el marco y observa el desarrollo de la conversación.

Eso implica explicar cómo va a desarrollar la conversación. Ha preparado las preguntas para esa conversación. Ha establecido los límites. Requiere mucho trabajo de planificación.

Según mi experiencia, cuando una retrospectiva no sale bien, lo que suele faltar es que la persona que la modera no se ha tomado el tiempo de planificarla. Simplemente va improvisando sobre la marcha.

Eso no sirve de nada.

Lo que resulta útil es que establezcan un límite de tiempo, por ejemplo, 10 minutos. Cuando se agota ese tiempo, no se andan con rodeos, sino que se muestran firmes: «Bien, ya hemos hablado lo suficiente sobre eso; es hora de tomar una decisión y seguir adelante».

Por lo tanto, esos parámetros son realmente muy importantes para que el espacio resulte eficaz. ¿Qué problemas ha observado que se hayan podido solucionar con una simple mejora?

En lo que respecta a las retrospectivas, el error más habitual es decir: «Tengamos una conversación abierta». A continuación, el grupo se pone a hablar de cualquier tema que se le ocurra. Aunque eso es importante en algunos contextos, lo que realmente se busca es obtener un valor concreto del tiempo que se dedica a la retrospectiva.

Recuerde: no nos centramos en el trabajo en sí. Nos centramos en el equipo. Nos centramos en cómo trabajamos.

Algo que a menudo se pasa por alto, cuando nos dispusimos a hablar de cómo nos sentimos ante lo ocurrido, es determinar qué ocurrió realmente. Es importante asegurarse de que todos los presentes compartan una visión común de lo que estamos tratando.

En definitiva, una puesta a punto. Una comprobación para ver si estamos de acuerdo en los hechos.

A menudo, en mi caso, una herramienta útil para lograrlo es dedicar unos minutos a que el equipo elabore una cronología de lo ocurrido. Trace una línea horizontal en una pizarra y empiece a anotar en ella: «Al principio del sprint ocurrió esto, y luego pasó aquello».

Esto contrarresta cualquier sesgo de recencia. No se limitarán a pensar en lo que ha ocurrido en el último día o dos, o en la última hora o dos. Esto es importante, sobre todo si se trata de una iteración de dos semanas, de un mes o de más tiempo. Hay muchas cosas que no recordará.

Darles tiempo para que recuerden de forma activa resulta de gran ayuda.

Es posible que haya miembros del equipo que no lo hayan vivido de la misma manera o que no recuerden los hechos con tanta claridad. Quizás hayan oído hablar de algo, pero no participaron directamente. De este modo, se les ofrece una visión un poco más completa y compartida.

A partir de ahí, una vez que el equipo se ponga de acuerdo sobre lo que ha ocurrido, podrá hablar de lo que eso implica, de cómo se sienten al respecto y de qué se podría mejorar.

La amnesia puede tratarse en primer lugar.

O simplemente puntos de vista totalmente distintos. Antes de que comience la retrospectiva, se pueden abordar modelos mentales totalmente distintos de lo que ocurrió.

Imagínese, pues, la alternativa. Entrar directamente en el tema de si «¿eso estuvo bien o mal?». Cada uno tiene en la cabeza su propia versión de lo ocurrido. Esas versiones son todas completamente diferentes. Esto significa que las palabras que utilizan para describir las cosas resultarán totalmente inadecuadas desde el punto de vista de la otra persona. No habrá conexión alguna. De ahí no puede surgir ninguna comprensión.

Los equipos ágiles como sistemas vivos: una exploración de la metáfora

Ahora, para profundizar aún más en su dominio de la metáfora: si la retrospectiva es el latido del corazón, ¿qué es el equipo?

Es un sistema. Un conjunto de órganos que funcionan en conjunto. Cada uno desempeña una función diferente. Intenta seguir adelante, crecer y aprender. Intenta mantenerse sano.

Esto nos lleva, de hecho, al tema del bienestar del equipo. ¿Se ha encontrado alguna vez con un equipo que, aunque disfuncional, sea eficaz? Hay personas de gran rendimiento que, sin embargo, tienen problemas reales.

Claro, van tirando el día a día. Pero ahí está esa expresión: «ir tirando». Si uno va tirando, es porque probablemente hay algo que resulta difícil y que a las personas más sanas no les cuesta. Se pierden oportunidades.

Esto nos lleva de nuevo a la previsibilidad. Creo que una de las cosas más devastadoras de padecer una enfermedad grave es lo impredecible que se volvería mi vida. No podría hacer planes con verdadera fiabilidad, porque no sé si de repente voy a desmayarme. Podría necesitar una ambulancia e ir al hospital. Ahí se va mi semana.

Creo que eso es lo que tiene la salud y la metáfora de la salud. Uno se esfuerza más para mejorar las cosas, con el fin de que la vida resulte más fácil.

En mi experiencia personal, se me da bastante mal hacer ejercicio y mantener una rutina. Sin embargo, ha habido momentos en mi vida en los que lo he hecho bien durante unos meses. Solía hacer algo bastante sencillo. Por ejemplo, 10 flexiones al día. Y lo he mantenido durante bastante tiempo.

Cuando he sabido hacerlo bien, lo que más me llama la atención sobre cómo me siento no es que me sienta más grande o más fuerte, sino que siento que el mundo se ha vuelto más fácil. La dificultad se ha reducido.

Esa fluidez. Esa facilidad de movimiento cuando uno está en plena forma. Por eso creo que eso es lo que se busca en un equipo cuando se le pone a punto como es debido. El efecto que esto tiene en las personas para las que trabaja el equipo es que este resulta predecible, como un reloj, y es de fiar, ¿entiende?

En el libro El cuerpo en 4 horas, de Tim Ferriss, se plantea el concepto de la «dosis mínima eficaz». No es necesario estar en forma como un atleta olímpico; se trata del mínimo necesario para lograr un efecto positivo. ¿Cuál es el mínimo que podemos hacer para lograr un efecto, un efecto positivo en el equipo? En muchos casos, eso es suficiente.

Características de un equipo ágil y eficaz

¿Qué aspectos debería tener en cuenta quien modera una retrospectiva para evaluar el estado de su equipo?

Bueno, sin duda deberían ver cómo se toman las decisiones. El panorama cambia en el equipo que goza de buena salud. Están haciendo pequeños ajustes. Están adaptándose. Están experimentando con total libertad.

La responsabilidad no recae a nivel individual. Recae en todos. Existe una especie de atmósfera en la que no se culpa a nadie, del tipo: «Oye, eso no ha salido muy bien». Puede que identifiquen que alguien hizo algo y eso causó un problema, pero no se diría: «Cuando hiciste eso, realmente lo estropeaste todo, ¿y qué vas a hacer para solucionarlo?». Se trata más bien de: «¿qué podemos hacer mejor para reaccionar ante eso?». Sabe que la responsabilidad recae en todo el equipo, incluso cuando son las acciones de una sola persona las que pueden haber provocado que algo saliera mal.

En general, existe la idea de que no hay culpa.

Saben manejar bien los conflictos.

Un indicio claro de que un equipo es bueno es que sus miembros no se callan: se quejan. Y es que cuentan con un ambiente de total confianza en el que se sienten capaces de plantear las cosas que les preocupan.

Una última perla de sabiduría ágil

A falta de 30 segundos y sin previo aviso, ¿cuál sería su consejo más valioso para cualquiera que se embarque en un proyecto ágil?

Deténgase a reflexionar antes de que sea necesario.

Muchos equipos solo se reúnen para tratar el tema cuando este se convierte en un problema y, bueno, es fácil saltarse la retrospectiva cuando parece que todo va bien. Si lo ha hecho, es que no ha analizado la situación con detenimiento ni ha detectado aquello que podría causarnos un problema. Ya sea dentro de unas semanas o de unos días.

¡Gracias!

Queremos expresar nuestro más sincero agradecimiento a Jon Fazzaro por participar en esta entrevista.

Jon es un coach ágil full-stack y lleva más de veinte años dedicado al desarrollo de software. Es un firme defensor de las prácticas ágiles modernas, como la programación en equipo, el desarrollo basado en pruebas y la colaboración diaria con las partes interesadas. También es un gran defensor de la gestión de productos Lean y del pensamiento sistémico.

Jon participa habitualmente como ponente en congresos de software desde 2015. Puede visitar «Oh! The Humanity.», donde encontrará una visión detallada de su visión profesional actual.