La comodidad de echar la culpa a otro equipo

Él dice que se le ocurrió un domingo sobre las 22:00, en algún lugar mucho más al norte de la Comunidad de Madrid. Me impresiona la exactitud con la que algunos recuerdan ciertas cosas. También me contó que el día anterior había leído aquel viejo post del equipo gelatinizado (lo cual me enorgullece, aunque las gracias debió dárselas a DeMarco) y que eso le inspiró la idea.

En su empresa, Mr. NoBody lleva lidiando con la llamada transformación Ágil desde hace años. Muchos años de esfuerzo, recaídas, vueltas a empezar y, después de muchos meses, algunos éxitos que le habían dado oxigeno para continuar.

Pero había algo que no había podido resolver. Varios equipos de creación de producto dependían de otro equipo de operaciones (pasos a producción, instalaciones, testing final).

Técnicamente aquellos equipos no eran multifuncionales y las consecuencias eran de libro. Los de creación dejaban a «casi terminar» los productos, porque no tenían la responsabilidad de entregarlos a los clientes, y el de operaciones se pasaba la vida quejándose de lo mal que le llegaban los productos y lo mal que estaban desarrollados.

El desperdicio, aunque pareciese que nadie lo viera, era más que evidente: volver a trabajar sobre una tarea que, en principio, estaba cerrada por los equipos de creación pero que volvía a abrir el equipo de operaciones.

Muchas culpas y poco objetivo común, muy poco objetivo global. Mucho yo lo hice bien y la culpa es tuya.

Mr. NoBody me contó que sus intentos de que creación y operaciones dejaran de ser dos equipos para ser uno fueron como chocar contra un muro. Nada. La resistencia al cambio era inmensa, nadie quería moverse, ni los managers estaban interesados, hasta había cierta comodidad trabajando así, viviendo constantemente en la queja en el otro equipo.

Aquel domingo a Mr. NoBody se le ocurrió lo que el llama una «chapuza ágil». A falta de poder crear un equipo multifuncional propuso que la velocidad, el número de trabajo terminado por Sprint (aun sabiendo que ningún equipo terminaba realmente trabajo porque dependía del otro), se midiera en global, no una velocidad por cada equipo, sino un «burndown» común, que sólo contaba cuando se entregaba a cliente, no cuando un equipo pasaba la pelota a otro.

Los primeros «burndown» de velocidad «global» fueron, obviamente, un desastre, pero, realmente, mostraban la realidad, ponían en un gráfico lo que realmente estaba pasando.

Interiorizada la evidencia, la realidad, el desastre, algo cambió. Siempre decimos que un grupo de personas es un equipo cuando, entre otros, tiene un objetivo común, pero, más allá, debiera haber un objetivo común a varios equipos. Sino cada uno luchará por su cuenta.

A falta de lograr equipos multifuncionales, la «chapuza ágil» sirvió para que operaciones se involucrara en los Sprint de los equipos de creación para que las cosas quedaran bien terminadas antes, sin esperar tiempo después, casi esperando que llegaran mal para quejarse.

Y los equipos de desarrollo vieron con muy buenos ojos contar con operaciones mientras estaban desarrollando, interesaba que no volvieran bugs tiempo después, restando en el gráfico de velocidad global.

Fue cuestión de tiempo que aquellos equipos separados decidieran ellos mismos que quizá era mejor reestructurarse en equipos multifuncionales. Tener un objetivo común cambia las cosas.

Grande Mr. Nobody.

1 comentario en “La comodidad de echar la culpa a otro equipo”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba