Los héroes en desarrollo software (cuando escribía esto me ha venido a la cabeza una canción de la M.O.D.A.), uno de esos temas clásicos sobre problemas en equipos, uno de esos temas por los que no pasa el tiempo, de los que se ha escrito tanto.

Da igual trabajar en modelos clásicos que modelos Ágiles, es lo mismo… siempre hay y habrá héroes.

El héroe del desarrollo software es aquel del que todo el mundo depende, que es «el único que sabe de…», al que todo el mundo mira en las Dailys, el que cuando todo parece perdido resuelve los problemas, al que nadie discute una propuesta, aquel que ha ganado su fama release a release, paso a producción tras paso a producción, madrugada tras madrugada, sábado a sábado, update tras update.

¿Qué me ha inspirado escribir hoy sobre el tema de los héroes? Bueno, como puedes imaginar, ha sido Ms NoBody, que fue una heroína durante años, e incluso, yo creo, aunque no lo reconozca, que subconscientemente puede que disfrutase de serlo… hasta que se cansó y quiso dejarlo.

Pero no podía, porque, después de años, el resto del equipo eran peleles a su alrededor. Y lo intentó, de una manera, de otra, delegando cosas, intentando no tomar tantas decisiones, etc., pero no lo conseguía. Hasta que la única manera que encontró de potenciar al resto del equipo fue… marcharse.

Y entonces todo parecía el fin para aquel equipo, un «tod@s vamos a morir», un «qué haremos ahora»… pero sobrevivieron y ahora es cuando han aprendido a tirar todos y cada uno del equipo, sin esperar a que la heroína les resolviera los problemas

Y eso me recordó la de equipos que me encuentro con heroínas y héroes, rodeados de un equipo comparsa, que no quieren dejar de serlo… se sienten muy cómodos en ello, el héroe satisface su ego de esta manera y, en lo que más nos afecta, impiden a los equipos evolucionar, ser más multifuncionales, más auto-organizados, menos vulnerables, que aumente la auto-estima de todos los miembros, equipos más eficientes y más potentes.

Los dos pensamientos anteriores me llevaron a recordar, tómalo como consejo, al menos, valóralo, un viejo patrón de Scrum (la versión moderna remasterizada la puedes leer en A Scrum Book: The Spirit of the Game) llamado «elimina la sombra», que aconseja que, si tenemos un «problema» de héroes, lo mejor es… que la heroína o el héroe salga del equipo. Así, sin más temporadas de «transmisión del conocimiento» que no dejan de ser desperdicio.

El patrón viene a decir que mientras esté el héroes el equipo va estar en una zona de confort que le va a impedir desarrollar su máximo potencial. Y el héroe puede que, también, esté en una zona de confort-ego que también impida buscar maneras reales y efectivas de evitar de su dependencia.

El patrón (que lo firma, entre otros, uno de los padres de Scrum, por si había duda) habla, explícitamente, de que es el Scrum Master quien, después de probar soluciones infructuosas, tiene la potestad (o debiera tenerla, que ya sabemos que el Scrum Master está en peligro de extinción) de buscar una solución a este problema y tomar la decisión de que, si nadie toma otra acción y no hay soluciones, el héroe debe moverse a otro equipo (experimento, ya sabes).

Ver fuente