Gli ostacoli nel percorso di un progetto (si, anche in quelli gestiti agilmente) possono essere molteplici. La forza dell’Agile sta nella pronta e flessibile risposta alle criticità da parte di un team affiatato e, soprattutto, auto-organizzato.
Alla base del successo di un progetto Agile c’è proprio il corretto funzionamento delle logiche presenti all’interno del gruppo di lavoro.
Ecco perché ritengo che il punto più importante da affrontare quando si vuole passare alla gestione Agile dei progetti sia il coinvolgimento delle risorse che faranno parte dei team.
Utilizzo il termine “coinvolgimento” nella sua accezione più forte, ossia come traduzione di quel “commitment” inglese utilizzato nella famosa favola del pollo e del maiale (la trovate qui “The Chicken and the Pig“): un progetto non potrà avere successo senza il supporto, l’impegno e la presenza di una forte motivazione, anche personale, delle risorse coinvolte nel team.
Faccio un esempio concreto per meglio esprimere il concetto.
Un caso in pratica
Immaginiamo un’azienda manifatturiera il cui direttore della divisione IT, avendone sentito parlare, decide di introdurre l’Agile sul progetto di evoluzione del proprio software dedicato alla gestione clienti/ordini/fornitori. Progetto già in carico al gruppo di sviluppo interno, ma bloccato nella spirale della raccolta requisiti di business (sappiamo tutti cosa vuol dire non riuscire a chiudere le specifiche a causa delle continue richieste di introduzione di nuove funzionalità da parte dei vari attori in gioco).
Il direttore IT parla quindi con il resto del top management, spiegando che l’introduzione delle metodologie snelle porterà a rilasci più veloci del software con nuove funzionalità e con cadenza costante. Segnala anche la necessità di introdurre alcune linee guida e alcune regole che DEVONO essere accettate da tutti i partecipanti al progetto (sia quelli coinvolti sia quelli, solo, interessati). Questo a fronte di una fase di formazione iniziale sulle metodologie agili. Budget alla mano il direttore IT ritiene che il tutto porterà una serie di benefici organizzativi e economici all’azienda. Il top management approva!
Da qui abbiamo due possibili evoluzioni prese, appositamente, agli antipodi tra loro.
Se tutto andasse davvero bene
Il direttore IT indìce una riunione plenaria con il suo staff nella quale presenta la stessa idea proposta al top management, comunicando il riscontro positivo ricevuto. Quindi introduce il Coach Agile, un consulente esterno che sarà a disposizione del team in tutte le fasi di adozione delle metodologie snelle. Direttore e Coach, insieme, mostrano le caratteristiche principali dell’approccio Agile, descrivendo le linee guida e le regole da seguire, rispondendo inoltre ad una sessione aperta di domande. Alla fine della plenaria il direttore offre la possibilità ai partecipanti di prendere parte al nuovo progetto, in base alla loro predisposizione ed in completa libertà, chiedendo loro di comunicare l’interessamento tramite email o di persona.
Con l’aiuto del Coach il direttore effettuerà quindi una prima scrematura tra le persone che hanno espresso il desiderio di partecipare al progetto. Seguiranno poi alcuni colloqui individuali per arrivare alla creazione effettiva del team di progetto.
A questo punto il team è stato creato ed è necessario introdurre i valori fondamentali su cui si baseranno i prossimi mesi di lavoro: qui trovi una sintesi dei valori Agile.
Il passo successivo è la scelta da parte del team, con il supporto del Coach, del framework da utilizzare (Scrum, XP, Crystal, ecc.) nonché il suo eventuale adattamento alle procedure aziendali interne e quindi l’avvio effettivo delle attività di progetto.
Le singole persone sono effettivamente coinvolte, compongono il cuore pulsante del progetto e sanno di essere i responsabili del suo esito finale.
Se tutto andasse davvero male
Il direttore IT decide a priori chi parteciperà al progetto, creando il team senza consultare preventivamente le persone coinvolte e, men che meno, motivarle. Indìce quindi una riunione del gruppo di lavoro, spiegando in prima persona come sarà condotto il progetto, facendosi promotore dello stesso, indicando quali solo i compiti dei partecipanti. Senza lasciare spazio a eventuali domande e imponendo le scelte fatte.
A questo punto il team è stato creato ed è necessario introdurre le regole su cui si baseranno i prossimi mesi di lavoro. In questo caso il direttore IT si presenta come responsabile di prodotto/cliente interno nonché come Agile Coach.
Il passo successivo è la scelta, nonché l’eventuale adattamento, del framework da utilizzare (Scrum, XP, Crystal, ecc.), sempre da parte del direttore IT, relativa comunicazione al team e quindi l’avvio delle attività di progetto.
Le singole persone sono effettivamente precettate, compongono la criticità principale del progetto e restano comunque i responsabili del suo esito finale, in questo caso probabilmente negativo.
In conclusione
Esistono una serie di possibili sfumature tra il primo ed il secondo scenario, ma il concetto fondamentale resta comunque valido: senza un team motivato e coinvolto in prima persona non è possibile ottenere i benefici sperati dalla pratica Agile.
Avete esperienze dirette di integrazione delle metodologie Agile in azienda? Con quali risultati? A voi la parola.
Una risposta a "Coinvolgere il team e dargli fiducia: la prima regola della pratica Agile!"