Gli sviluppatori amano sentirsi “importanti” e spesso si emozionano e si pavoneggiano quando sono insigniti del ruolo di firefighter, ovvero di pompieri chiamati a risolvere un’emergenza.
Ho letto, da più parti, che questa pratica è “supportata” da Scrum e dall’Agile in generale, a patto che sia attuata per un tempo limitato e che occupi solo una percentuale di tempo dell’iterazione.
Ebbene, tutto ciò è assolutamente falso! L’Agile non contempla minimamente la presenza di “firefighter” che, anzi, vanno in direzione opposta a quello che è il primo Valore dell’Agile Manifesto:
Gli individui e le interazioni più che i processi e gli strumenti
Tra l’altro, già il riferimento a tempistiche e percentuali, in modo così vincolante, dovrebbe far riflettere.
Un Team di Sviluppo (non solo Agile) è un’entità complessa, viva e con le proprie regole, su cui l’azienda ha investito ingenti risorse al fine di trasformarla in un ecosistema che produca Valore. Immaginare che qualcuno venga insignito del ruolo di “firefighter” mina il Team alle sue fondamenta, andando a creare membri di classe A e membri di classe B, creando fisiologiche frizioni interne e rendendo vano il lungo lavoro fatto per la sua costituzione e maturazione. A questo si aggiunge il fatto che tale approccio limita il know-how e la crescita ad un singolo componente del Team (o comunque ad un suo sottoinsieme), creando ulteriori disparità e demolendo l’idea stessa di Team cross-functional.
Inoltre, chi decide chi è un “firefighter”? Lo Scrum Master, il Team, il singolo Membro? Se il “firefighter” viene scelto, allora si passa ad un approccio command-and-control, all’antitesi dell’Agile, se invece viene (auto) nominato significa che il Team è ben lontano dal sentirsi tale.
Insomma, si evidenzia come questa pratica sia un vero e proprio Anti-Pattern che dà solo l’illusione di risolvere un problema nell’immediato, mentre crea grossi problemi in prospettiva, andando a degradare il Team e, di conseguenza, la sua capacità di creare Valore.
