Asumir la responsabilidad de un proyecto en problemas siempre es un tema delicado. Algo no está funcionando como debería. Hay un grupo de personas en el lugar, que puede o no 1) estar trabajando como equipo, 2) tener los conocimientos necesarios y una actitud positiva, o 3) estar dispuestos a aceptar el cambio.
Entonces, ¿cómo hace un líder de proyecto nuevo para encarrilar al equipo lo más rápido posible?
Planificar, Hacer, Revisar, Mejorar
Todos conocemos historias de consultores arrogantes y jefes que no conocen del negocio, o reorganizan todo sin importar las consecuencias, o desaparecen rápido o son ascendidos, o dejan al equipo para que arregle todo el lio. No sólo hay que esperar algo de esceptisísmo, sino que es algo saludable. Así que la primer prioridad es ganar el apoyo y respeto del equipo. Una segunda prioridad es hacer que el equipo trabje en mejorar la situación.
Scrum nos brinda una herramienta muy poderosa: la Retrospectiva, que normalmente se realiza al terminar cada Sprint. Al comenzar el rescate de un proyecto, me gusta usar una Retrospectiva para conocer al equipo, identificar acciones a corto plazo, ganar su confianza, y plantar la semilla para hacer la transición hacia Scrum (y a la vez estar haciendo foco en las necesidades del proyecto, no en la metodología).
Scrum implementa el ciclo de Deming "Planificar-Hacer-Controlar-Actuar", y lo repite al menos una vez al mes. Prefiero llamarlo "Planificar, Hacer, Revisar y Mejorar" porque es una mejor descripción de lo que realmente ocurre. Así que, para un proyecto en problemas, se puede empezar con el paso de Mejorar, lo cual suena bastante lógico.
Las 5 preguntas
La Retrospectiva en general responde 5 preguntas:
- ¿Qué ocurrió?
- ¿Qué hicimos bien?
- ¿Qué podría mejorarse?
- ¿Quién tiene jurisdicción para realizar la mejora?
- ¿Cuál es la prioridad más alta?
En general, deberían estar presentes todos los involucrados en el proyecto, y no más de 15 personas en total.
El resultado son dos listas priorizadas de acciones para mejorar la productividad del proyecto. La primera lista contiene acciones que el equipo puede realizar por si mismos, es decir, el equipo tiene autoridad sobre el tema. La segunda lista contiene elementos que requiere de acuerdos o aprobación de alguien "de afuera", como ser la Gerencia, el Cliente, otro departamente, o quien sea.
¿Por qué hacer una Retrospectiva?
Al preguntarnos qué ocurrió, se construye un entendimiento común sobre el proyecto - una cultura en común. El solo hecho de reunir a las personas en una misma mesa, darles la oportunidad de hablar, y hacer que se puedan escuchar entre ellos es un avance enorme para reducir los conflictos emocionales. También se envia un mensaje de que todos tienen algo importante que decir.
Al preguntarle al equipo qué está haciendo bien, quitamos el riesgo de "tirar la ropa vieja con la biletera adentro". Se les está dando apoyo a todos. Enviamos el mensaje que comprendemos que las personas están trabajando por el bien del proyecto, y dejamos en claro que justo eso es lo que deberían hacer! El equipo va a responder y a trabajar mejor por el feedback y el respeto que les demos.
Más aún, tenemos una oportunidad para realizar preguntas. "Creia que en la lista de cosas que hacemos bien iba a aparecer la prueba del producto. ¿Qué tipo de pruebas hacemos antes de entregar el software?". O tienen una buena respuesta, o van a estar obligadas a hacer alguna sugerencia buena. Al hacer las preguntas correctas, podemos guiar el proceso de mejora en la dirección que queremos.
Al preguntarle al equipo cómo mejorar, obtenemos una lista de acciones a corto y mediano plazo que generan mejoras visibles en el estado del proyecto. Más aún, el equipo es el dueño de la lista, incluso de los elementos que hayamos sugerido nosotros mismos a través de preguntas inteligentes. Es por esto que el equipo apoya la lista y ayuda a implementarla.
Al determinar la jurisdicción, determinamos sobre qué elementos el equipo puede actuar por si mismo, y qué elementos necesitan de ayuda o negoción externa. Para aquellas ideas bajo la jurisdicción del equipo, pueden empezar inmediatamente con el primer elemento de la lista. Para el resto, se comienza con el pedido de más prioridad, y trabajamos para satisfacerlo.
Por ejemplo, un elemento de la primer lista puede ser hacer revisiones de código: dos desarrolladores se juntan y discute sobre su código. Nadie tiene que saber esto, ni mucho menos darles su aprobación. Tan sólo, háganlo! Los elementos de la segunda lista son más dificiles para aprobar, y debemos asumir la responsabilidad de gestionarlos para el equipo.
Algunos gerentes pueden asustarse de que el equipo haga peticiones frívolas ("¿el equipo entero necesita viajar a Malta para conocer al sistema?"), pero al priorizar la lista nos enfocamos en lo que realmente es importante ("Si, lo necesita, y es porque...."). Es importante que la gerencia esté presente, para que puedan ver la validez del proceso.
El equipo puede tener ideas para estar ocupados por dos o tres meses, así que vamos a necesitar enfocarnos en unos pocos elementos para que el equipo pueda continuar con el trabajo productivo. Los elementos menos importantes pueden postergarse para la próxima retrospectiva.
Y lo más importante... ¡hacerlo!
Las consecuencias de cada retrospetiva deberia ser un resultado concreto por lo menos - está bueno toda una lista de cosas a hacer, pero necesitamos resultados reales. Cuando el equipo logra hacer lo que se les pidió, se consigue un refuerzo positivo. Cuando hacemos que su petición de máxima, con responsabilidad conjunta, se haga realidad, vamos a ganarnos su respeto y confianza, lo que resulta en una vida más facil para el equipo y para nosotros.
Pero... si no les permitimos hacer las cosas que identificaron, vamos a generar desilución. Así que cuando lleguemos a la próxima retrospectiva, debemos haber implementado (o al menos estar en proceso de implementar) uno o dos elementos de cada lista. Y es mejor lograr terminar un elemento, que tener 5 en progreso.
Los resultados
En mi experiencia, los equipos siempre identifican potencial genuino para mejorar (todavía nadie me sugirió ese viaje a Malta). Los temas más importantes que surgen en la primer retrospectiva son generalmente organizacionales, y se solucionan facil con Scrum. Ese es el momento de comenzar a hablar con el equipo acerca de Scrum, y cómo les puede ayudar a resolver sus problemas.
Durante el año pasado estuve involucrado en tres "rescates". Dos resultaron exitosos, uno no. En este último caso, el equipo identificó muchos temas para mejorar (algunos muy triviales para implementar), pero no se les permitió implementar ninguno de los cambios que sugirieron, por lo que el esfuerzo fue en vano. Tres meses después, el proyecto "se estrelló contra la pared", tal y como lo habian predecido en la retrospectiva.
Uno de los rescates, aunque exitoso, lo inicié sin la retrospectiva. El equipo reaccionó de forma negativa y, a pesar de resultados objetivamente exitosos, no fue sino hasta que la mayoría de los miembros antiguos del equipo fueron reemplazados por gente nueva que el ambiente se tornó positivo.
El rescate más exitoso fue el que comencé con una Retrospectiva. El equipo tenía la autoridad para implementar la mayoría de los cambios que querían, así que la motiviación, la productividad y la calidad mejoraron rápidamente y de forma radical. La mayoría de los temas que propuso el equipo se resolvieron con Scrum y otras herramientas que queriamos usar, por lo que la aceptación fue alta desde el principio, y no hubo ninguna resistencia significativa a los cambios en la metodología.
¿Cómo hacer perdurar a los cambios?
No vamos a cambiar al mundo con una reunión. Los temas emocionales no desaparecen en una tarde. Recuerdo una retrospectiva (entre dos empresas "en cooperación") donde el único acuerdo de la primer retrospectiva fue que hiba a hacerse otra retrospectiva el mes siguiente. El truco es lograr pequeñas mejoras, de manera regular. Los temas emocionales en general no se "resuelven", sino que se disuelven con el tiempo. Así que la repetición es importante, especialmente cuando las emociones están involucradas.
En un contexto ágil, hacemos una retrospectiva luego de cada Sprint (por ejemplo, cada dos o tres semanas). Incluso aunque no usemos Scrum o XP, las retrospectivas son muy útiles y deberían hacerse a intervalos regulares de tiempo, y a pocas semanas de distancia. En cualquier caso, para la próxima retrospectiva se debe implementar la mejora más importante de cada lista (o al menos, gestionarla).