Uno dei dodici principi dell’Agile Manifesto recita così: “Una conversazione faccia a faccia
è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team”. Per i firmatari del Manifesto questo aveva certamente senso, perché la maggior parte dei team non aveva alternativa che lavorare nello stesso ufficio o quantomeno nello stesso stabile.
Oggi la situazione è diversa: la tecnologia e la banda larga consente di fondere in un unico team persone appartenenti a sedi differenti della stessa azienda, oltre che acquisire nuovi talenti all’estero, dove sono presenti mercati più competitivi e competenze davvero evolute.
E’ possibile formare un team agile con un gruppo di persone distribuito in varie zone del mondo? Certamente è una cosa fattibile, ma a può funzionare efficacemente solo se si usano alcuni accorgimenti.
Il primo: definire e mantenere degli standard condivisi. Uno di questi è sicuramente la lingua utilizzata nei momenti comuni del team. Se sono presenti team members provenienti da paesi esteri è necessario e tassativo utilizzare una lingua compresa da tutti. Questo anche nel caso in cui ci fosse anche un solo collaboratore estero: parlare internamente una lingua e tradurre solo le comunicazioni dirette verso l’esterno aiuterebbe solo ad aumentare le barriere culturali. Oltretutto far parte di un team multiculturale il più delle volte si traduce in un occasione di fare un salto culturale, il che è già un miglioramento a prescindere dal progetto in cui il gruppo è coinvolto.
Condividere degli standard significa però anche accordarsi su convenzioni, pattern, processi e procedure comuni. Se incanalate in processi chiari e semplici le persone possono ridurre la dipendenza reciproca. E sarà anche più facile per loro condividere il proprio lavoro coi compagni di squadra, se questo fosse necessario. Oltre a minimizzare l’onere di mantenere una documentazione dettagliata della propria parte di progetto: “Il software funzionante più che la documentazione esaustiva”. A tal proposito, è consigliabile creare una wiki di progetto, dove annotare informazioni come lo scheletro dell’architettura, le procedure di troubleshooting, e così via.
Il secondo consiglio è quello di mantenere i canali di comunicazione sempre aperti al massimo. Non ridurre la qualità dei meeting solo perché non tutte le persone sono presenti. Piuttosto, fare in modo che l’esperienza sia il più possibile simile ad una riunione in presenza. Nelle sedi dove è presente più di un membro del team, vale sicuramente la pena di predisporre monitor a parete di dimensioni generose, webcam obbligatoriamente HD, e microfono ambientale di ottima qualità, che azzeri i rumori ambientali sgraditi. E’ tassativo invece non isolare le persone nella propria postazione, con le classiche cuffiette con microfono. Questo non promuove la collaborazione aperta e lo scambio di informazioni allargato. Del resto anche in questo caso il principio è sempre “Una conversazione faccia a faccia…”: finché è fisicamente possibile, rimane assolutamente valido.
Terminati i momenti comuni di condivisione (daily meeting, sprint retrospective, etc…), è necessario mantenere un contatto aperto tra i membri del team. Si può facilmente aprire un gruppo di discussione o una chat su software come Skype o Google Hangouts. Le comunicazioni rilevanti vanno trasmesse all’interno di questi gruppi, in modo che siano immediatamente a disposizione di tutti, anche di chi non è presente in quell’ufficio.
Naturalmente avere team distribuiti significa dover condividere la board con il dettaglio dello sprint. Per questo risultano molto efficaci i software che consentono di gestire board online. Questo non significa necessariamente abbandonare tabelloni e post-it: basta solo mantenere aggiornati quelli online sulla base di quelli fisici.
Ancora, è necessario prestare particolare attenzione a comunicare efficacemente. Quando le persone si scambiano pareri e punti di vista senza potersi vedere di persona, le dinamiche comunicative cambiano in maniera molto sottile in quanto si fa sentire la mancanza della conferma visiva della reazione dell’interlocutore. E se a questo si aggiungono differenze culturali, si può sfociare molto facilmente in fraintendimenti ed incomprensioni. Per questo è fondamentale modulare forma e contenuto della comunicazione, con una particolare sensibilità nel cogliere in anticipo le reazioni dell’interlocutore.
Altro punto di attenzione è l’orario lavorativo. L’ideale sarebbe poter avere orari completamente sovrapponibili tra tutte le sedi di lavoro, così da essere tutti insieme sempre virtualmente presenti. Questo naturalmente dipende dal fuso orario: con i paesi più vicini è certamente è fattibile, ma più ci si allontana e più le difficoltà aumentano. In questi casi è necessario poter sovrapporre almeno il tempo necessario per condurre i meeting comuni programmati per la giornata (daily, planning, retrospettive, review…) e poi assicurarsi che ci siano le condizioni necessarie per andare avanti in totale autonomia. Questo significa ottenere in anticipo le informazioni necessarie per condurre la propria attività, rimuovere eventuali impedimenti immediati o molto prossimi, ed in ogni caso spianare la strada per poter lavorare in tutta tranquillità.
Un altro aspetto importante è mantenere il più possibile aggiornate le User Story che compongono lo sprint corrente. E’ evidente che ogni cambio di requisito dovrà essere comunicato al più presto a chi sta lavorando, anche a chi non è direttamente coinvolto in una User Story. Il focus sul prodotto deve essere sempre mantenuto da tutti. Vale infatti il principio del Manifesto che recita: “Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.”. Ma naturalmente il cambiamento nei requisiti deve essere prontamente percepito da tutti.