L’autogestione in Scrum è un concetto impegnativo, spesso difficile da tradurre e applicare, soprattutto per quei team abituati a gestire i progetti con metodologie classiche di project management, che si trovano ad affrontare una fase di transizione verso le pratiche Agile. Una delle differenze più significative tra l’approccio tradizionale alla gestione dei progetti e il framework Scrum risiede proprio nel concetto di autogestione.

A differenza dei gruppi di lavoro tradizionali, i team che si autogestiscono, non sono diretti o controllati dall’alto, piuttosto definiscono autonomamente chi, come e su cosa lavorare. L’autogestione rappresenta una sfida non solo per il team, ma anche per il management: la difficoltà risiede nel conciliare la necessità di ottenere risultati prevedibili con la richiesta di maggiore libertà e autonomia da parte del team. In sostanza, se il sistema tradizionalmente impiegato nelle organizzazioni è di tipo “push”, quello che si costruisce in Scrum è di tipo “pull”, in quanto il team ha la capacità di decidere autonomamente su quali compiti lavorare, senza aver bisogno che vi sia qualcun altro ad assegnare le attività da svolgere.

Ma come fare per guidare un team verso l’esercizio dell’autogestione?

Nel libro “Agile Project Management with Scrum“, Ken Schwaber (che, ricordiamo, insieme a Jeff Sutherland, ha creato e sviluppato il framework Scrum) parla proprio di quanto sia interiorizzata nell’essere umano la tendenza a soccombere e a preferire che siano sempre gli altri ad assumere decisioni:

“Essere gestiti da qualcun altro è totalmente radicato nella nostra vita e nella nostra esperienza lavorativa. Genitori, insegnanti e capi che ci insegnano ad autogestirci piuttosto che sforzarci di soddisfare le loro aspettative sono davvero rari. Allora perché, quando chiediamo ad un team di essere responsabile della gestione di sé stesso, dovremmo aspettarci che sappia di cosa stiamo parlando? Per quel team l’autogestione sarà solo una parola, ma non ancora qualcosa di reale. Prima di poter veramente capire come gestire sé stesso e come assumersi la responsabilità e l’autorità per pianificare e condurre le proprie attività, un team dovrà maturare un’esperienza concreta con Scrum.”

I principali ostacoli all’autogestione in Scrum

Guidare il team Scrum verso l’esercizio dell’autogestione è innegabilmente un percorso impegnativo e ricco di ostacoli, ma i benefici che comporta ripagano sicuramente lo sforzo.

Un team Scrum immaturo, appena formato e senza esperienza nell’esercizio dell’agilità, si ritroverà ad affrontare una serie di difficoltà, dalle quali però non si sottraggono anche i team già formati e che attraversano una fase successiva alla prima adozione del framework. Infatti, l’autogestione deve mantenersi viva sempre, in un’ottica di miglioramento continuo (continuous improvement).

Nella fase di adozione iniziale del framework, è possibile che il team si scontri con una serie di ostacoli legati a:

• inerzia del team – Inizialmente il team sarà entusiasta dell’adozione dei principi agili, soprattutto perché accoglie con favore il concetto di libertà che l’agile project management porta con sé. Tuttavia, presto inizieranno ad emergere le prime difficoltà, la cui risposta più semplice e comune è il ritorno alle vecchie modalità di lavoro. Il risultato? Il team tenderà ad adottare solo le pratiche agili ritenute più semplici e convenienti. Questo approccio potrà reggere però solo nel breve periodo, perché alla lunga i risultati non saranno quelli sperati;
• la personalità dei membri del team – Nel contesto lavorativo incontriamo persone diverse: alcune solitarie che riescono a lavorare sulla loro tastiera tutto il giorno senza avvertire il bisogno di interagire con gli altri, altre più socievoli potrebbero invece passare ore ad interagire, discutere e confrontarsi. Nella gestione tradizionale del progetto, sarà il project manager, con le sue doti da leader, a trovare il modo migliore per gestire le diverse personalità e far in modo che possano lavorare insieme armonicamente. In Scrum tutto ciò dovrà essere bilanciato dallo stesso team;
• il cambio di mentalità degli stakeholder – Una delle sfide più difficili per gli stakeholder è capire, accettare e mettere in pratica nuovi approcci e procedure. In un progetto Scrum, una volta che lo sprint è iniziato, non è possibile introdurre modifiche, a meno che queste non supportino lo sprint goal. Nella metodologia tradizionale, invece, i dirigenti e tutti gli altri stakeholder, hanno il potere di richiedere in qualsiasi momento le modifiche ritenute necessarie. Dal momento che Scrum non contempla questa possibilità, eventuali richieste di modifiche sollevate dagli stakeholder, potrebbero facilmente sfociare in conflitti perché, da un lato, il team si sentirà spodestato della libertà di autogestione, dall’altro gli stakeholder si sentiranno privi di controllo;
• dislocazione geografica – Nel caso di team dislocati geograficamente ma che operano all’interno della stessa organizzazione, il problema principale è la ridotta interazione. Anche se oggi la tecnologia mette a disposizione strumenti che permettono di superare tale ostacolo, la comunicazione face to face resta la modalità di interazione da preferire;
• assenza di responsabilità individuale – In Scrum è il team l’unica entità responsabile della selezione degli elementi del Product Backlog, da includere e realizzare nello sprint. Di conseguenza, la responsabilizzazione di ciascun membro è fondamentale per il successo del progetto.

Le strategie per un esercizio corretto dell’autogestione

Per gestire con successo l’adozione iniziale del framework, è importante che i principi Scrum espressi dagli autori nella Scrum Guide, siano chiaramente resi noti e recepiti da tutte le parti interessate. Sarà lo Scrum Master a promuovere la comprensione della teoria e delle pratiche Scrum, sia all’interno del team sia all’interno dell’organizzazione.

A tal proposito, ricorda i seguenti principi essenziali del framework:

• i ruoli, gli artefatti, gli eventi e le regole Scrum sono immutabili;
• il Product Owner è una sola persona, non un gruppo. Egli è l’unico responsabile della gestione del Product Backlog;
• il team, nell’esercizio dell’autogestione, sceglie il modo migliore per svolgere il proprio lavoro, senza interferenze provenienti dall’esterno;
• lo Scrum Master è un servant leader per il team di Scrum.

Trovi un approfondimento su eventi, strumenti e principi del framework Scrum in questo articolo.

Sebbene sia forte la tentazione di adottare solo parzialmente le pratiche prescritte in Scrum, soprattutto nella fase di iniziale di implementazione, sarebbe bene evitare questo tipo di approccio. Al contrario, è preferibile lavorare proprio sulla diffidenza e convincere tutti dei vantaggi che Scrum è in grado di apportare al team e all’intera organizzazione, se applicato nella sua interezza.

Un aspetto da non sottovalutare è la scelta dello Scrum Master. Lo Scrum Master ideale ha una spiccata attitudine al lavoro di squadra e una propensione alla collaborazione. Ad esempio, investire del ruolo una persona fortemente convinta delle potenzialità della cultura del comando e del controllo, potrebbe rivelarsi un problema. Un altro requisito che lo Scrum Master deve necessariamente possedere è una profonda conoscenza e comprensione del framework. Come dice la Guida Scrum: “Scrum è semplice, facile da capire ma estremamente difficile da padroneggiare“.

Se cerchi un corso di formazione per Scrum Master, dai un’occhiata qui.

Una volta che un team inizia ad autogestirsi, il viaggio è solo all’inizio. Sarebbe infatti un errore trascurare l’esercizio dell’autogestione nelle fasi successive alla prima implementazione del framework. Ricorda che l’agilità richiede un lavoro continuo verso il miglioramento e la crescita del team deve essere sostenuta anche nel lungo termine. Una possibile strategia da impiegare per mantenere alta la motivazione del team è la job rotation.

I benefici dell’autogestione

I benefici dell’autogestione derivano principalmente dalle frequenti interazioni tra i membri del team (vedi gli eventi Scrum) che promuovono la condivisione delle informazioni, alimentando un flusso di apprendimento continuo. Incontrarsi e confrontarsi frequentemente fa nascere nel team un forte legame di squadra, quindi è essenziale la partecipazione attiva di tutti i membri del team in tutti gli eventi Scrum.

L’autogestione produce una serie di ulteriori benefici:

• maggiore agilità e velocità di consegna: poiché i team autogestiti non hanno bisogno di un manager per portare avanti il ​​progetto, sono molto più agili e in grado di rispondere alle mutevoli esigenze e priorità del progetto;
• maggiore responsabilizzazione e motivazione: gli individui possono scegliere i propri compiti e stabilire le proprie scadenze, pertanto i team Scrum tendono ad essere più motivati ​​e soddisfatti del proprio lavoro;
• flusso di lavoro continuo: i team autogestiti sono autosufficienti, il che è l’obiettivo finale del metodo Scrum. Il risultato è un flusso di lavoro continuo, che funziona senza interruzioni e sprechi di risorse.

Per costruire un team basato sull’autogestione, oltre che dalla Scrum Guide, lasciati guidare dal Manifesto Agile e, in particolare, ricorda e fai tuo questo principio:

“Costruisci i progetti su individui motivati. Dai loro l’ambiente e il supporto di cui hanno bisogno e confida nella loro capacità di portare il lavoro a termine.”

E tu, hai mai lavorato in un team Scrum? Parliamone nei commenti!