shelidonJune 25, 2018Leave a Comment

Post originariamente scritto per il blog di Strategie Digitali, il 25 Giugno 2018.

«Tutti gli architetti sono essenzialmente risolutori di problemi di progettazione.»
«All architects are essentially design problem solvers.»
— Cliff Moser, BIM Scrum, part 1 on ConstrucTech Jan/Feb 2016

Approfondiremo la relazione tra BIM e Scrum nel convegno del 6 luglio a Roma: ulteriori informazioni qui.

1. Cos’è lo Scrum?

Siamo abituati a considerare la gestione di un progetto come qualcosa di estremamente lineare: viene stilato un progetto di esecuzione sulla base del quale vengono ripartiti ruoli e responsabilità. In BIM questo piano viene chiamato BIM Execution Plan e viene normalmente stilato dal BIM Manager in prima battuta, prima dell’assegnazione del contratto: viene poi manutenuto dal BIM Coordinator che, nel framework tradizionale, è il braccio BIM del Project Manager.

«Lo Scrum è un framework di processo utilizzato dai primi anni novanta
per gestire lo sviluppo di prodotti complessi.»
— Jeff Sutherland, Guida allo Scrum™

Lo Scrum diverge dal framework tradizionale per approccio e implicazioni. I suoi autori, Ken Schwaber e Jeff Sutherland, lo caratterizzano come framework AGILE per lo sviluppo del Software in situazioni ad alta imprevedibilità, che richiedono soluzioni creative e adattabilità da parte dei team. Il framework si adatta bene a situazioni in rapida evoluzione e si basa su un approccio euristico, empirico, che richiede la rapida iterazione di brevi cicli di produzione chiamati anche sprint.

Si basa sul principio che i team lavorano al loro meglio quando viene loro lasciata la possibilità di organizzarsi autonomamente intorno ai task e ruota intorno ai valori di coraggio, concentrazione, dedizione, rispetto e apertura mentale.

Buona parte dei problemi che il BIM mira a risolvere come metodo di produzione, tra cui l’incoerenza delle informazioni e lo spreco di risorse, vengono replicate cercando di adattarne le dinamiche a un framework di project management tradizionale, verticale, in cui le informazioni vengono condivise solo su un’arbitraria need-to-know basis e i ruoli all’interno dei team non tengono conto delle micro-dinamiche e delle condizioni al contorno. Lo Scrum al contrario incentiva i team ad essere comunicativi e cooperativi, li protegge da dinamiche distruttive, li spinge ad essere cross-funzionali e adattabili, si basa sui principi di miglioramento continuo cari al lavoro in Qualità.

2. Come funziona?

Lo Scrum si basa sul principio che non sia possibile prevedere tutte le variabili in gioco su un progetto per una lunga durata. La stima di ciò che è consegnabile nasce quindi da un’analisi delle richieste del cliente che suddivida il compito in task più brevi, sviluppabili in un’unità di tempo che va dalla singola alle quattro settimane e che è chiamata Sprint. Centrale al framework è il rispetto per le persone e per la loro capacità di organizzarsi autonomamente: si ritiene che laddove venga lasciata questa possibilità, un team responsabile e facilitato in modo corretto raggiunga una più alta capacità di risolvere problemi complessi rispetto a quanto non farebbe un team disciplinato guidato da un project manager tradizionale.

Il ciclo di lavoro inizia con una figura chiamata Product Owner che condivide con il team quelle che vengono definite Epics. Tenendo presente che lo Scrum nasce dal mondo del Software Development, le Epics sono storie complesse o collezioni di storie in cui viene narrata l’esperienza di un utente con il prodotto, spesso dall’inizio alla fine. Le storie che compongono un’epica vengono spesso ricondotte a una sintassi comune, estremamente schematica, del tipo “In quanto [X], voglio [Y] in modo da poter [Z]”. Un classico esempio potrebbe essere “In quanto [Cliente], voglio [costruire un nuovo flagship store a Milano] in modo da poter [rafforzare la nostra presenza sul territorio]”. L’epica si costituisce da multiple storie e in esse deve essere suddivisa per poter funzionare ed essere tradotta in obiettivi tangibili, misurabili e sufficientemente circoscritti per il team. Cosa significa “rafforzare la presenza sul territorio”?

Questo tipo di lavoro è alla base dell’impostazione di un progetto in BIM e si articola nella definizione degli obiettivi (BIM Goals) e nella loro successiva traduzione in usi del modello, a loro volta cruciali non solo in relazione ai deliverables ma anche alla definizione dei LOD e delle specifiche informative in genere.

In Scrum, il compito di suddividere le epiche in storie viene lasciato al team, che successivamente le suddivide ulteriormente in task. Ogni task deve poi essere analizzato e la sua fattibilità adeguatamente valutata. In BIM, abbiamo diversi strumenti per questo tipo di assessment e il più efficiente è certamente quello di Bilal Succar: ulteriori informazioni si trovano nell’episodio 24 del suo BIM ThinkSpace, in particolare alla sezione IV, Applying Model Uses in practice, che presenta un Implementation Template per gli usi del modello.

2.1 Model Uses Assessment in Scrum

Lo Scrum fornisce sistemi meno strutturati e più flessibili, come ci si aspetta, ma ugualmente applicabili allo scoping di un progetto BIM. Uno di questi è il metodo di analisi e prioritizzazione MoSCoW, che suddivide i requisiti del prodotto in quattro categorie:

• Must have, ovvero i requisiti che per forza devono essere inclusi all’interno del prodotto;
• Should have, ovvero quei requisiti fondamentali che dovrebbero essere inclusi all’interno del prodotto ma che per cause di forza maggiore potrebbe anche essere risolto altrimenti;
• Could have, ovvero le desiderata: si tratta di requisiti che il prodotto potrebbe avere e che saranno inclusi se consentito dal tempo e dalle risorse a disposizione, ma la cui assenza non pregiudica l’efficacia del prodotto;
• Would have: un requisito che il cliente o gli stakeholder accettano di non vedere implementato in questa iterazione ma che potrebbe eventualmente venire considerato in seguito. Dato che i requisiti in questa categoria vengono esclusi categoricamente dallo sprint di produzione, spesso questa categoria viene anche chiamata Won’t have.

Il metodo aiuta a mettere i requisiti in priorità analizzandone il business value.

Un lavoro simile viene normalmente portato avanti nell’analizzare la fattibilità degli usi del modello richiesti per quel progetto. In una situazione di implementazione acerba ad esempio, l’uso del modello per design authoring viene considerato un Must have, ma usi più spinti come la quantificazione preliminare possono essere considerati uno Should have. Altri usi desiderati ma poco impattanti, come la visualizzazione, potrebbero essere un Could have. Viceversa, è comune che usi estremamente impattanti come il computo siano un Would have: è chiaro che sarebbe ideale poter svolgere computi dal modello ma semplicemente non si è pronti a farlo, quindi l’uso verrà sperimentato in un progetto successivo.

I must have non dovrebbero superare il 60% dello sforzo necessario al team, mentre ai Could have dovrebbe essere riservato un 20%.

.

2.2 Come si valuta l’impegno?

Un metodo per la valutazione dello sforzo che sarà necessario per portare a compimento uno specifico task, è il Planning Poker, anche detto Scrum Poker. Si tratta di un sistema inventato da James Grenning nel 2002 e reso popolare da Mike Cohn nel suo Agile Estimating and Planning. Il suo obiettivo è mantenere il team al centro delle decisioni ed evitare che membri più forti del gruppo possano influenzare le valutazioni collettive con la loro opinione. In modo non troppo diverso da quello che si richiede di fare nel LEGO® SERIOUS PLAY®, le valutazioni devono essere fate individualmente, fissate in quella che in questo caso è una carta da gioco e poi condivise collettivamente in modo paritario.

Le carte comunemente sono organizzate intorno a una sequenza di Fibonacci da 0 a 89, e presentano quindi una frequenza maggiore dei numeri bassi per disincentivare l’utilizzo del metodo nella stima di elementi particolarmente impegnativi come dimensione.

Un processo di stima che utilizza questo metodo prevede ad esempio che sia il team stesso a valutare quanto tempo è necessario per portare a termine uno specifico task. L’innovazione del sistema risiede da un lato nell’evitare che le stime di tempo vengano imposte in modo unilaterale al team. Dall’altro lato, il sistema ha anche il vantaggio di livellare il terreno su un piano collaborativo limitando uno scenario in cui i task vengono svolti da una singola persona che quindi ha il potere rallentare l’intera produzione con le proprie tempistiche.

Le discussioni durante una sessione di Scrum Poker richiedono un facilitatore, ma il potere di fornire la stima definitiva è esclusivamente del team, che deve raggiungere un consenso.

3. Processo chiave: lo sprint

Anche se il framework è molto più ampio, lo Sprint è senza dubbio l’unità base più riconosciuta dello Scrum, con cui spesso viene identificato. Si tratta del core dell’attività, un periodo di tempo circoscritto che va dalla singola alle quattro settimane, durante il quale gli sforzi del team si concentrano per realizzare un’iterazione completa e utilizzabile del prodotto, che contenga le caratteristiche individuate durante la prioritizzazione.

A partire da un Product Backlog, che contiene tutte le caratteristiche, viene sviluppato uno Sprint Backlog che contiene quelle caratteristiche o quelle parti di caratteristica su cui ci si intende focalizzare durante l’unità di lavoro. Nel caso di un modello per il computo, ad esempio, potrebbe trattarsi di completare una certa categoria o una certa area. Anche a seconda del modello e del suo breakdown, alcune segregazioni potrebbero avere meno senso di altre.

La chiave dello sprint è che al termine dello sforzo il prodotto realizzato deve essere un tassello autonomo dello schema incrementale. Anziché procedere uniformemente con il lavoro attraverso una serie di condivisioni work in progress, lo Scrum sposta il focus su sforzi più focalizzati ma che producono un risultato in un tempo limitato e che quindi gratificano maggiormente sia il team che il cliente.

4. I ruoli tra Scrum e BIM

Un gruppo Scrum è poco strutturato e relativamente snello, per ovvi motivi. Si compone di quattro ruoli fondamentali:

• lo Stakeholder, detto anche Information Provider;
• il Product Owner, responsabile per la Qualità del Prodotto una volta consegnato;
• lo Scrum Master, responsabile per la Qualità del Processo;
• il Development Team, che nel suo complesso è responsabile per la Qualità del Prodotto in consegna.

Trovare analogie esatte non è fondamentale e non deve diventare un esercizio di stile, ma trasportare questi ruoli all’interno di un sistema BIM è relativamente semplice una volta che si analizza cosa ciascuno ha il compito di portare al progetto anziché concentrarsi su titoli e ruoli.

.

Lo Stakeholder ha il compito di fornire le informazioni necessarie a caratterizzare il prodotto, ovvero le epiche e le storie. Si tratta del cliente, anche se in Scrum il termine viene utilizzato in modo cauto e bisogna fare attenzione a differenziare il cliente dall’utente finale, che spesso è il soggetto delle “storie”. Per semplificare il concetto trasportando il framework in edilizia, si pensi alla differenza tra un developer residenziale e l’acquirente finale di un appartamento, o tra un developer nell’hospitality e il cliente-tipo dell’albergo.

Il Product Owner è l’unico a poter mettere le mani sul Product Backlog, ovvero sul registro completo delle caratteristiche che il prodotto deve avere. E’ il responsabile della qualità una volta che il team ha consegnato il prodotto ed è stato da lui approvato e validato. In una situazione collaborativa, questo ruolo di custode delle specfiche viene normalmente ricoperto da BIM Leading Consultant, ovvero dal BIM Coordinator del consulente che si occupa del coordinamento generale del progetto. Per alcuni progetti particolarmente importanti, che comportano un’aggregazione temporanea, si può parlare anche di Project BIM Manager, ma non amiamo questa espressione perché spesso viene utilizzata a sproposito.

Lo Scrum Master ha il cruciale ruolo di facilitatore del team. Deve assicurarsi che tutto il team abbia ben compreso gli obiettivi, lo scope del progetto e la sua natura, ma anche vigilare sulle riunioni propedeutiche agli Sprint, preservare l’integrità e la serenità del team, gestire il rapporto con il cliente. Sono molte caratterstiche che attribuiamo a un buon Task Team BIM Coordinator.

4.1 Il BIM Coordinator come Scrum Master

In una situazione che non prevede un team leader ma che si basa sulla capacità del team di auto-organizzarsi in modo consapevole e responsabile, lo Scrum Master è la persona che ha il potere di mandare in pezzi l’intero schema, interferendo in modo inappropriato con il processo.

Tra i suoi compiti:

• Assicurarsi che tutto il team abbia ben compreso le caratteristiche del progetto: questo tipo di informazioni proviene dalle storie e da ciò che è contenuto negli Employer Information Requirements;
• Facilitare il corretto svolgersi degli eventi e delle riunioni all’interno del team;
• Rapportarsi con il Product Owner nella gestione del Product Backlog: nel nostro caso, si tratta di collaborare con il BIM Lead nell’aggiornamento dei protocolli e dei documenti collaborativi, oltre che nel tracciamento degli stati di avanzamento.

Deve quindi trattarsi di una persona di grande esperienza che abbraccia il concetto di Servant Leadership: una leadership al servizio del team, che condivida un approccio olistico al lavoro, che promuova una cultura di condivisione all’interno del gruppo e che condivida il potere di prendere decisioni.

Tra i compiti di un BIM Coordinator in questo ruolo, cruciali diventano le attività di formazione e coaching che mirino a rendere il team indipendente, cross-funzionale e auto-organizzato. Si tratta di una figura che deve mirare a far sì che il team consegni un prodotto del più alto valore possibile e quindi i suoi sforzi non devono essere di debugging o patching, come spesso può accadere, ma di tutoring. Se le performance del gruppo sono sub-ottimali, è preferibile una strategia che rimuova gli impedimenti rispetto a strategie d’emergenza che mirano a salvaguardare il prodotto. In questo senso il Coordinator è responsabile per la qualità del processo, mentre la qualità del prodotto rimane unica responsablità del team.

4.2 Il ruolo del cliente

Molti dei framework per l’ottimizzazione di processo, dalle rivoluzioni di Toyota in poi, puntano ad un maggior coinvolgimento del cliente e lo Scrum non fa eccezione. Un cliente in Scrum ha il compito cruciale di fornire le epiche e le storie attorno alle quali vengono ricavate le caratteristiche del prodotto, ma anche una serie di doveri nei confronti del team. Il suo coinvolgimento è delicato, specie in un framework che affida ai team la responsabilità di autogestirsi: devono quindi essere ben separati gli aspetti su cui il cliente può e deve fornire un input da quelli, come l’organizzazione interna dei team durante lo sprint, in cui il cliente non può interferire.

I compiti del cliente vengono quindi generalmente riassunti in:

• partecipare attivamente al processo;
• fornire le storie e le epiche;
• fornire input concreti e di valore durante le discussioni;
• approvare le caratteristiche che definiscono “consegnabile” il prodotto.

Tra i suoi doveri:

• rispettare le regole del framework;
• non interferire con il team.

La necessità di un coinvolgimento del cliente in BIM è un argomento che non dovrebbe aver bisogno di spiegazioni e su cui già abbiamo avuto modo di esprimerci.

Ogni progettista lavora secondo un proprio asse paradigmatico, una propria serie di elementi base (siano essi forme geometriche o paradigmi funzionali) da cui attinge per creare il progetto. A tali elementi di base attiene la filosofia progettuale del singoli: essi costituiscono il linguaggio del progettista e non possono essere alterate dall’esterno.
Viceversa quello che potremmo chiamare asse sintagmatico, ovvero la sequenza con cui i paradigmi vengono scelti e assemblati, è variabile e viene tracciato in risposta alla domanda del committente.
Dato lo stesso progettista, con un suo linguaggio architettonico e una sua filosofia progettuale maturi e formati, il sintagma che nelle fasi concettuali coincide con il progetto viene composto in maniera diversa a seconda della domanda. Da domande diverse, quindi, scaturiscono progetti diversi.
Se questo è vero, il focus del progetto nasce quindi sì dalla sensibilità del singolo progettista ma in stretta correlazione alla formulazione di domanda precisa da parte del committente.

La precisione nella domanda, che in BIM si identifica con gli Employer Information Requirements / i Capitolati Informativi, non è sufficiente.

Il BIM ha incrementato la quantità di dati che un progettista può e deve processare durante il ciclo progettuale. In concomitanza, la fruizione stessa dei dati da parte degli altri attori nella filiera è diventata più veloce e immediata: non è più previsto lavorare per fasi, con i dati che vengono consegnati in chiusura delle stesse, ma il flusso di dati è costante attraverso l’intero processo progettuale, idealmente consentendo una fruizione dell’oggetto costruito anche prima della sua effettiva realizzazione.

Per usare un’immagine che ci è particolarmente cara, un processo strutturato per lunghe fasi, con un cliente esterno al processo che fruisce solo delle consegne al termine di ogni fase, si configura come il paradosso del gatto di Schrödinger. I progettisti lavorano in un ambiente separato e il committente non ha modo di sapere se il progetto sia coerente con il brief (vivo o morto) fino a quando, alla consegna, non gli viene consentito di visionarlo e quindi, per proseguire sullo stesso parallelismo, di aprire la scatola.

Un progetto BIM invece è tanto più efficace quando rende fluido lo scambio di dati attraverso le varie fasi: il committente può quindi porsi come parte attiva del flusso progettuale, se definisce le proprie modalità di interazione nell’Employer Information Requirements, limitando i rischi che il progetto si discosti dal brief e contribuendo al processo con una serie di input inediti e necessariamente esterni alle sfere di competenza del progettista. Lo scambio di informazioni tra il team di progetto e il cliente contribuisce a tenere vivo il gatto.

Questo continuo scambio è cruciale in Scrum, che fornisce il Product Backlog come strumento di interfaccia tra cliente e processo di produzione.
Ma questa è un’altra storia e dovremo parlarne in un secondo momento.

Bibliografia di Riferimento

• Ken Schwaber e Jeff Sutherland, Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust.
• Ikujiro Nonaka e Hirotaka Takeuchi, The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation.
• Geoff Watts, Scrum Mastery: From Good To Great Servant-Leadership.