I Gatekeepers

Come i team Acquisti, Legal e Risorse Umane sono importanti per un team Agile

Sappiamo che un team Scrum deve essere, idealmente, multifunzionale per poter consegnare a fine sprint un incremento potenzialmente consegnabile (Potentially Shippable Increment). Il team è, di solito, composto da alcuni membri che sono dedicati completamente al progetto (o almeno un 80% del loro tempo) e da altri membri che partecipano al progetto in maniera parziale, in alcune fasi o su chiamata.

Ci sono dei ruoli che sono dei veri e propri enablers per far lavorare bene un team. Ruoli e funzioni che spesso non consideriamo quando formiamo un team Agile perché non hanno un impatto diretto e visibile sul prodotto ma del cui impatto ci accorgiamo nel corso del progetto. Mi riferisco a tre funzioni in particolare: le Risorse Umane (HR), il team Legale e gli Acquisti. Vediamo che impatto hanno queste tre funzioni su un team Agile, quali sono i problemi che emergono dal non coinvolgere i rappresentanti di questi team in un progetto e come aumentare l'efficacia di un team coinvolgendo queste figure.

Possiamo immaginarci il gatekeeper come l'ufficiale di guardia alla porta di una città medievale, colui che conosce le regole e i costumi della città e che ha l'autorità per far accedere a questa città gli stranieri e i viandanti.

Innanzitutto il nome: gatekeepers. Non è una mia definizione, l'ho letta da qualche parte nella vasta letteratura Agile. In italiano potremmo tradurre il termine con "custode". Possiamo immaginarci il gatekeeper come l'ufficiale di guardia alla porta di una città medievale, colui che conosce le regole e i costumi della città e che ha l'autorità per far accedere a questa città gli stranieri e i viandanti. Ed in effetti le tre funzioni di cui parlavo sopra, HR, Legale e Acquisti sono come delle città indipendenti, con delle proprie regole, ognuna delle quali con un valore che può donare al team Agile. Vediamo queste città nel dettaglio.

Iniziamo dagli Acquisti. Lo scopo del team Acquisti è quello di trovare i materiali di cui ha bisogno l'azienda al costo adeguato. Molte volte questo team lavora con una logica di efficienza, che mette in primo piano il costo del materiale. Spesso, nelle grosse organizzazioni, gli Acquisti sono centralizzati al fine di avere delle procedure standard e robuste per poter consolidare i quantitativi delle singole divisioni al fine di negoziare un prezzo migliore con il fornitore. Con un team che lavora in Agile questa logica deve essere rivista per dare maggiore enfasi all'efficacia e al valore piuttosto che alla sola efficienza. Ci sono due punti dolenti per un team Agile nel campo della fornitura di materiali: la disponibilità di avere materiali in tempi brevi e la necessità di avere materiali sperimentali che non sono ancora stati approvati dagli Acquisti. Il più delle volte queste esigenze sono ostacolate dal funzionamento dell'Ufficio Acquisti che non è in grado di assicurare rapidità nella fornitura e varietà dei materiali fuori da quelli standard.

Cosa serve, dunque, a un team Agile nell'ottica acquisti? Innanzitutto il team deve poter avere un proprio budget, anche limitato, da poter utilizzare per le spese necessarie. Ho assistito al caso di team che sviluppavano prodotti complessi dover attendere mesi per avere del materiale comune del valore di qualche decina di euro perché il processo di richiesta d'acquisto prevedeva il passaggio attraverso un ufficio centrale globale. Inoltre il team Agile deve potere scegliere dei fornitori e prodotti fuori dal parco standard senza passare per i processi di validazione. Si può conciliare questa necessità del team con il bisogno dell'azienda di avere dei processi robusti dando al team la possibilità di testare dei materiali con autorizzazioni minime nella fase di creazione di prototipi per poi avere il processo di validazione standard nella fase di produzione di massa; oppure si potrebbe creare, per i prodotti in via di sviluppo con modalità agili, dei processi di validazione rapidi di fornitori e materiali.

Il Team Legal è un altro gatekeeper importante che viene spesso dimenticato dal team Agile fino a quando questi non si scontra con delle barriere legali o contrattualistiche. Sarebbe opportuno coinvolgere un rappresentante del Legal nelle prime fasi del progetto, quelle in cui si definisce l'obiettivo, la roadmap, il coinvolgimento degli stakeholder, etc. Soprattutto nel caso in cui il team Agile lavori con dei fornitori o collaboratori esterni in maniera costante, è importante che il quadro legale della collaborazione sia ben delineato. Presento due situazioni che ho visto capitare spesso lavorando con dei team Agile.

In un'ottica tradizionale si stabilisce cosa deve essere consegnato e con che tempistiche; con un team Agile occorre avere la flessibilità di poter dare dei feedback ai fornitori per cambiare cosa deve essere consegnato

Capita spesso che nei prodotti hardware lo sviluppo di un componente (spesso quello software) sia assegnata ad un team esterno che interagisce con il team Agile in maniera continua. Lascio per un altro momento la discussione su come un team Agile possa lavorare con dei fornitori esterni, mi limito qui a discutere gli impatti legali. Uno dei problemi grossi riguarda cosa il fornitore debba consegnare al team Agile. In un'ottica tradizionale si stabilisce cosa deve essere consegnato e con che tempistiche; con un team Agile occorre avere la flessibilità di poter dare dei feedback ai fornitori per cambiare cosa deve essere consegnato. O magari chiedere al fornitore di fare un test, accettando la possibilità che ci sia un fallimento. Chiarire con un quadro legale, anche leggero ma preciso, le attesa di un team Agile permette al fornitore di poter lavorare con serenità e non pensando sempre a "tutelarsi" da eventuali reclami che potrebbero essere fatti dal cliente. Collaborare con i clienti piuttosto che negoziare i contratti: questo è vero ma si deve ufficializzare almeno la forma della collaborazione.

Un altro tema è come dei fornitori di servizi possano lavorare con il team. Molte grosse aziende richiedono che queste figure non entrino in contatto con il proprio personale, che siano segregati in locali dedicati, che i loro PC siano di proprietà dell'azienda, che non ci sia un accesso ai drive dell'azienda... insomma avete capito cosa intendo. Queste condizioni, se possono iscriversi in una logica di politica aziendale, non facilitano il lavoro di un team Agile, in cui i membri devono poter comunicare e interagire nella maniera più efficace possibile. Un'efficace collaborazione all'interno del team Agile parte spesso dal team Legal che abbatte questi ostacoli fra "esterni" e "interni", magari partendo dall'accesso ai locali dell'azienda per i fornitori di servizi.

Quest'ultimo esempio introduce il terzo dei gatekeeper, le Risorse Umane, la cui azione spesso sconfina nel terreno del Legale per quel che riguarda l'accesso ai locali e l'interazione con i fornitori esterni. Ma il team HR ha soprattutto la responsabilità di abbattere i silos che possono formarsi all'interno di un team e di rimuovere dei blocchi creati dalle varie aree di competenza dei responsabili dei membri del Team stesso. Quest'ultimo, per essere autonomo, deve avere la possibilità di prendere delle vere decisioni, senza dover necessariamente coinvolgere i responsabili delle funzioni rappresentate nel Team Agile.

L'azione da parte dell'HR deve aiutare i manager a capire qual è il loro ruolo per supportare un Team Agile deve indirizzarsi a creare delle aree di libertà in cui il team possa sperimentare ed essere autonomo, soprattutto nel caso in cui la trasformazione Agile stia facendo i primi passi e sia necessario favorirla.

Infine, rientra nella sfera di azione dell'HR rendere i decision maker dell'azienda accessibili al Team Agile secondo le necessità e le forme opportune: ad esempio facilitarne la partecipazione alle review di sprint nel caso un team lavori in Scrum o trovare un canale veloce per fare escalation degli ostacoli su cui un team Agile si imbatte e che non possono essere risolti dal team stesso per motivi di budget, di organizzazione o di rapporti con i clienti.

Secondo il tipo di progetto, il ruolo di gatekeeper può essere preso anche da altre funzioni, quali la Qualità. È importante riconoscere fin dall'inizio quali sono quegli elementi che possono favorire, o danneggiare, un progetto e coinvolgerli nella giusta misura al fine di creare un ambiente favorevole al lavoro del team Agile.