Introduzione
Quando si pensa ai progetto “Agili”, realizzati con un qualsiasi framework, il pensiero successivo è “perdo il controllo”. Non ho più date fisse e il budget non è sotto controllo. Me lo sono sentito dire molte volte, come se agilità fosse un sinonimo di improvvisazione.
Niente di più sbagliato!
Vedremo anzitutto come le date variabili possono essere fonte di incertezza e possono creare anche più problemi; allo stesso tempo chiariremo il dubbio su tempi e costi di un progetto agile.
Date, Budget, Scope
In un articolo a proposito della gestione delle date fisse nei progetti Agili, Ron Jeffries, scrive: ”It's not that we don't have enough time. We have too much to do.”
Mantenere i tempi ed aumentare il carico di lavoro prima o poi fa “scoppiare il team”: rende le comunicazioni pessime e diminuisce la proattività del team. Questi sono dati ottenuti da varie fonti autorevoli che si occupano di teamwork e di soft skills, cito Goleman piuttosto che Scharmer.
In questo tipo di situazione è il management che deve intervenire perché il suo compito è quello di identificare gli obiettivi e identificare risorse e persone necessarie a raggiungerli in modo razionale e pianificato. Non si tratta di puntare a caso il dito sul calendario, fissare una data e poi costruirci intorno un processo di sviluppo che, in molti casi, non la potrà soddisfare.
Del resto il management non può e non deve neanche delegare il team a identificare una data perché farlo vorrebbe necessariamente dire delegare anche l’autorità per gestire risorse e persone al fine di centrare la data. E’ chiaro che stiamo chiedendo al team di fare il manager. In realtà il team può solo fare il manager di se stesso e dei suoi compiti relativi al processo di sviluppo. Infatti per poter centrare una data di rilascio sarebbe necessario avere il controllo delle persone e delle features (dello scope).
Quindi il manager dovrebbe assumere un ruolo differente ed entrare in un’ottica di facilitatore. La responsabilità di gestione della data rimane la sua con l’aiuto del product owner.
Le variabili in gioco sono quindi tre, la data, lo scope ed il budget, rappresentabili con un triangolo:
Avere una data fissa per una certa release a volte aiuta, altre è proprio necessaria. Il rilascio di una funzionalità o di un prodotto potrebbe infatti coinvolgere più uffici, non solo il team di sviluppo, anche il marketing o la logistica che devono organizzare i propri piani di lavoro per arrivare all'obiettivo. Se non avessimo quella data stabilita potrebbe essere, ad esempio, impossibile far partire delle campagne pubblicitarie per il prodotto che stiamo rilasciando.
Stabilito quindi che è possibile gestire le date fisse, come gestiamo le altre due grandezze, budget e scope?
Anzitutto fissiamo il budget. In genere il business e l’it amano fissare il budget per ogni progetto al fine di avere quella sensazione di “ho tutto sotto controllo”. In realtà invece spesso si sfora con il budget perché le modifiche richieste sono spesso numerose ed impattanti. Consideriamo comunque, ai nostri fini, che il budget sia stato stabilito. In ogni caso stakeholder e eventuali sponsor dovrebbero sapere quanti soldi voglio investire nel progetto.
Come gestiamo lo scope?
Come per le altre due variabili possiamo fissarlo o renderlo variabile. Uno scope variabile ci permette di gestire i cambiamenti e le richieste di modifiche che, da manifesto agile, dovrebbero essere ben accolte. Ma accettare il cambiamento e accompagnarlo attraverso la rimodulazione dello scope, cosa che nell’agilità si fa attraverso il product backlog, è il primo passo per essere antifragili.
Quindi se il nostro obiettivo, mantenendo un focus variabile, è quello di avere una data ed un budget fissi, necessariamente dobbiamo avere il controllo sul team di persone, potendolo anche rinforzare, considerando sempre la legge di Brooks: aggiungere forza lavoro ad un progetto software in ritardo, lo farà ritardare ancora di più.
Conclusioni
Tenendo in mente il nostro triangolo e fissata la data ed il budget, manteniamo variabile lo scope di progetto.
Lo facciamo attraverso un backlog di prodotto che cambia nel tempo in base alle richieste del business e dei clienti e anche all’andamento del progetto stesso. Alcune features potrebbero ad esempio essere tolte dal pb se non sono di primaria importanza e se il tempo o il costo di progetto sta aumentando troppo.
Lo scope quindi è il nostro strumento per essere antifragili e per rispondere alle avversità che sicuramente incontreremo, siano esse tecniche, che di persone.
I progetti agili permettono di far variare forma al triangolo vedendo appunto lo scope variabile.
