Pensando de forma innovadora en Agile: crea tu propio patrón de Scrum

La conversión hacia Agile es una tendencia cada vez más popular entre los equipos de desarrollo de software. Sin embargo, hay una interpretación equivocada de lo que significa esa conversión, en la que se da por hecho que implementar un framework como Scrum te lleva automáticamente a “hacer” Agile. La realidad es que no debemos aspirar a “hacer” Agile sino Serlo.

Agile no consiste en hacer frameworks sino en cambiar la forma de ser,y trabajar de una manera diferente y más flexible; Esto permite adaptarte a las diferentes circunstancias que tu entorno puede ofrecer. Por desgracia, el mundo ideal no existe, lo que significa que hacer cosas siguiendo la teoría no siempre funciona. Por eso, a veces debemos ser lo suficientemente flexibles como para tratar de adaptar los procesos con los que trabajamos a nuestra situación actual.

El problema

Hace unos años, en una galaxia muy, muy lejana (siempre quise poner esto en algún sitio), algunos de nosotros trabajábamos en un proyecto Agile, en el que los equipos usaban Scrum. En ese momento, los equipos eran relativamente novatos en cuanto a Scrum y el proyecto en sí. En ese equipo, el Scrum Master y yo éramos los únicos miembros que habíamos estado más tiempo en el proyecto y, en cierta medida, nos hicimos cargo de que el equipo entero progresara hacia Agile.

Parecía que las cosas iban viento en popa, y al principio el equipo estaba congeniando bastante bien y realmente estábamos adquiriendo una velocidad decente. Sin embargo, eso pronto iba a cambiar. Nos pidieron que incorporásemos un nuevo miembro al equipo; pero, no éramos conscientes del impacto que tendría.

Sprint 1

Decidimos aplicar programación en pareja para acelerar su integración en el equipo. Estaba muy motivado y nos transmitía que estaba listo para despegar antes de lo que esperábamos. Pensamos: “¿Qué podría salir mal?”

Le asignamos una tarea y comenzó a trabajar en ella. Nos sorprendió que apenas pidiese ayuda en la standup, nos decía que todo iba por buen camino y que estaba progresando. Sin embargo, hacia el final del sprint, nos dimos cuenta al mirar nuestro burndown, que sus actualizaciones no reflejaban la realidad. La verdad era que necesitaba ayuda, pero no la estaba pidiendo. Huelga decir que cuando nos dimos cuenta era demasiado tarde, y ya no podíamos acabar su tarea a tiempo. En la retrospectiva del sprint, lo animamos a pedirnos ayuda cuando lo necesitaba y a ser honesto con sus mensajes, y que nadie lo culparía por no lograr acabar el trabajo.

Del Sprint 2 en adelante

El nuevo miembro del equipo prestó atención a nuestros comentarios en la retrospectiva y comenzó a pedir ayuda. El problema fue que comenzó a pedir demasiada ayuda. La gente estaba empezando descuidar sus propias tareas para ayudarle.

Tenía problemas serios para comprender tanto el código como los aspectos funcionales de lo que estaba haciendo. Muchas veces el resto de nosotros terminábamos desarrollando su código (o rehaciéndolo), mientras él miraba. Necesitábamos reducir la velocidad para atender sus necesidades y el resto del equipo comenzaba a sentirse frustrado, ya que tenían problemas para completar sus tareas, debido a la dedicación en darle apoyo. El nuevo miembro era muy dependiente y lo peor era que no mejoraba a medida que avanzaban los sprints.

Las retrospectivas ya no se centraban en lo que estábamos haciendo bien o mal, sino que, por toda la frustración en el equipo, comenzaron a convertirse en sesiones de “meterse con el chico nuevo”. El espíritu de equipo estaba en mínimos históricos y el nuevo miembro, en particular, se estaba viniendo abajo. Todos los comentarios que recibía en las retrospectivas estaban empezando a desmoronarlo, ya que carecían de ningún elemento constructivo con el que él pudiese comenzar a mejorar. Teníamos que darle la vuelta a la situación rápidamente.

Necesitábamos ayuda

Como miembros más veteranos del equipo, el Scrum Master y yo decidimos que era el momento de actuar. Sin embargo, no estábamos muy seguros de qué dirección tomar.

Sabíamos que el nuevo miembro tenía serias limitaciones, pero seguramente había algo que podíamos hacer para ponerlo al día con el resto del equipo, para que los demás no se viesen afectados. Comenzamos a investigar para descubrir qué hacer en un equipo de Scrum cuando hay un miembro con un rendimiento bajo.

Por desgracia, no había mucha información sobre desarrolladores que tuviesen un bajo rendimiento y cómo deberían ser administrados dentro del equipo para que funcionen. La guía de Scrum se basa en un mundo ideal, por lo que no existe una sección de bajo rendimiento. Incluso contactamos con un coach de Agile que conocíamos, que nos dijo que la mejor idea era simplemente sacrificar al nuevo miembro. Obviamente, eso no era lo que estábamos buscando, aunque fuese la salida más fácil. No teníamos nada que nos guiase, así que, nos gustase o no, estábamos solos.

Sin ayuda, así que hagamos Ri

Tocaba ser flexibles y encontrar vías fuera del framework para abordar la complicada situación en la que nos encontrábamos. El Scrum Master y yo éramos conscientes de eso y comenzamos a acercarnos al concepto de Shu Ha Ri. Habíamos leído sobre esto en varios lugares y parecía ser lo que estábamos buscando.

Lo fundamental es que, primero en la fase Shu, un equipo es rígido y sigue los procesos establecidos por un framework (por ejemplo Scrum) de forma estricta, sin cuestionar nada. La idea detrás de esto es establecer los mecanismos correctos. En esta fase, el equipo necesita orientación.

En la fase Ha, el equipo ya no necesita hacer las cosas de manera estricta, porque el framework ya está integrado en su forma de trabajar. Comienzan a dominar el framework y lo usan de forma natural (está en su naturaleza). En esta fase, el equipo no solo hace las cosas por seguir el procedimiento, sino que comienza a entender por qué lo está haciendo.

En la fase Ri, el equipo tiene un control completo y absoluto del framework y no solo es capaz de usarlo de forma natural, sino que también es capaz de ir un paso más allá y mejorarlo o adaptarlo a sus necesidades.

La sensación que tuvimos fue que antes de que el nuevo miembro ingresara en el equipo, estábamos alcanzando la fase Ri. Estábamos haciendo las cosas de forma natural, sin guía, porque creíamos en lo que hacíamos y empezábamos a contemplar la idea de hacer mejoras en cuanto a nuestra forma de proceder.

De hecho, habíamos leído un artículo unos días antes relacionado con los patrones de Scrum y cómo pueden ayudar a producir equipos hiperproductivos. Este artículo nos hizo reflexionar. Allí no había nada que pudiese resolver nuestro problema. Sin embargo, nos marcó un nuevo camino. Un día, en el tren de regreso a casa desde el trabajo, el Scrum Master y yo tuvimos una idea brillante: ¿y si creásemos un patrón de Scrum propio?

El patrón de retrospectiva de autoevaluación

Uno de los principales problemas a los que nos enfrentamos era que no estábamos dando al nuevo miembro ningún comentario constructivo en las retrospectivas, que le sirviese para mejorar. Pensamos que era un gran punto de mejora y que necesitábamos que el equipo enfocara sus comentarios de una manera más positiva.

Decidimos cambiar la forma en que íbamos a hacer la próxima retrospectiva. En lugar de hacer la retrospectiva como siempre (BUENO, MALO y Acciones), nos centramos en mirarnos a nosotros mismos como individuos.

Los miembros del equipo se turnarían para ser el portavoz. Este evaluaría su propio sprint, dándose una nota del 1 al 5 y describiendo por qué creía que merecía esa nota. De esta manera, podríamos ver si todos eran conscientes de su propio desempeño. Una vez hecho esto, se dejaba que el resto del equipo diera su opinión. Si algún otro miembro del equipo no estaba de acuerdo con esa nota, tenían que levantar la mano y responder 3 preguntas:

  1. Nota que creían que el orador realmente merecía.
  2. Por qué creían que el portavoz merecía esa nota (lo que les obligó a justificar lo que estaban diciendo y no solo a criticar por criticar).
  3. Qué debía hacer el orador para lograr un 5 (feedback positivo y una vía de mejora)

Para darle más credibilidad a nuestro patrón de retrospectiva, y que el equipo no cuestionara por qué estábamos haciendo las cosas de otra manera, les dijimos que habíamos leído un artículo de un gurú de Agile sobre este tipo de retrospectivas y que pensábamos que podría ser útil para nosotros (una mentira piadosa no hace daño a nadie).

¿Qué pasó?

El equipo aceptó la idea en buena medida y aplicamos el patrón a nuestra próxima retrospectiva. Lo que descubrimos fue que la gente era mucho más cautelosa de lo que decían. El hecho de que tuviesen que justificar su crítica les hizo preguntarse si estaban en lo cierto en primer lugar, y si realmente había algún beneficio en la crítica destructiva.

Otra cosa que descubrimos fue que hubo bastante consenso entre las notas y en algunos casos, cuando no lo hubo, fue para bien, lo que elevó la nota para algunos portavoces. Esto sirvió como motivación positiva para cada uno, ya que se dieron cuenta de que tal vez estaban siendo demasiado duros consigo mismos, y de que el equipo estaba de su lado.

También notamos que cuando no había consenso y bajaba la nota, la crítica era mucho más ligera en comparación con las retrospectivas anteriores, debido a la justificación necesaria detrás de ella, y que si la persona no estaba de acuerdo con la nota, se centraba más en dar pistas al portavoz de cómo tenían que mejorar para subir sus notas.

Después de la retrospectiva, el ambiente fue completamente opuesto al que había antes. La gente salió de la sala con una actitud más positiva y habiendo hablado con algunos de los miembros del equipo después de muchos años, sintieron que recuperamos el espíritu de equipo perdido con esta nueva estrategia. En cierto sentido, redirigimos nuestra frustración en un nuevo camino positivo hacia la mejora.

Respecto al miembro nuevo, nos dábamos cuenta de que era consciente de sus limitaciones, de que habíamos sido demasiado duros con él y que necesitábamos darle las herramientas adecuadas para progresar. Por primera vez, tuvo comentarios positivos, que le permitiría avanzar. Le subió la moral y comenzó a ver algo de luz al final del túnel.

¿Qué aprendimos?

Desgraciadamente, estaría mintiendo si dijera que logramos salvar al miembro nuevo. Aunque mejoró su rendimiento y su integración en el equipo, dejó la empresa aproximadamente un mes más tarde, por lo que no podemos predecir si realmente le ayudó a largo plazo.

Sin embargo, durante ese mes, conseguimos algunas cosas:

– La moral del equipo aumentó debido a que las cosas se abordaron con una actitud más positiva

– Comenzamos a aceptar las debilidades de otras personas y les brindamos formas de mitigarlas, lo que no solo mejoró nuestro rendimiento sino también mejoró las relaciones entre los miembros del equipo.

Finalmente, aprendimos que Scrum no tiene soluciones para todo y que los equipos deben ser lo suficientemente flexibles y creativos para buscar su propia salida de situaciones difíciles. También que al pensar más allá de lo establecido, tratando de innovar y adaptar nuestros procesos, alejándonos de las rutinas marcadas, pudimos pasar de estar en un escenario muy oscuro a uno que nos permitió sobrevivir y progresar como equipo.

 

Comment Area

  1. Interesting experience Jose, it’s also comforting to know that there is no magic wand in the agile world and the adaptation and willingness of the team to integrate new methodolgies is all part of the process.

GreenCoding

Con GreenCoding el desarrollo de software se convierte en parte integrante de tu programa de sostenibilidad

Más información