Usare Scrum su larga scala: cosa cambia?

Craig LarmanLe implicazioni del cambiamento derivanti dall’applicazione del noto framework di sviluppo software anche a progetti di vasta portata

by Craig Larman

Nel 2003, quando ho pubblicato “Agile & Iterative Development” [1], molti “sapevano” che lo sviluppo agile di software era riservato ai team ristretti. Tuttavia, mi sono interessato – e ho anche ricevuto sempre più richieste – ad applicare Scrum a progetti di sviluppo su larga scala, di tipo multi-sito e offshore. Così, dal 2005 ho lavorato con alcuni clienti per scalare verso l’alto i progetti, spesso per sistemi “embedded” e di investment banking. Oggi, i due framework Large-Scale Scrum (LeSS) descritti nei nostri libri sono stati introdotti in grandi gruppi a livello mondiale operanti nei settori più disparati, tra cui fornitori di apparecchiature per infrastrutture di telecomunicazione come Ericsson [2] e a clienti di investment banking come Bank of America, Merrill Lynch e JPMorgan, oltre a numerosi altri.

Per quantificare il concetto di “larga scala”, abbiamo visto applicare il nostro LeSS framework-2 a gruppi fino a mille e 500 persone, coinvolgendo sette siti di sviluppo sparsi in tutto il mondo. La nostra esperienza mediana è di circa 800 persone operanti su un prodotto in cinque siti, con circa 15 milioni di linee di codice sorgente, di solito C++, C e Java. Sulla base di queste esperienze abbiamo pubblicato due volumi su come scalare verso l’alto lo sviluppo agile e sui framework Large-Scale Scrum, così riassunti: il volume 1, “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum” [3], spiega le modifiche nella leadership e nella progettazione organizzativa, mentre il volume 2, “Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum” [4], fornisce suggerimenti concreti per scalare aspetti quali il product management, l’architettura, la pianificazione, il multi-sito, l’offshore e il contracting. Ma non solo: presto pubblicheremo un’opera di sintesi più breve chiamata semplicemente Large-Scale Scrum, mentre questo articolo riassume alcune delle implicazioni del cambiamento trattate più diffusamente nelle opere appena elencate.

Leggi anche:  Step up your Analytics Game: a Milano e a Roma con SAS

Change Implications

Scalare Scrum verso l’alto implica capire ed essere in grado di adottare un vero Scrum standard con un unico team. Il Large-Scale Scrum richiede di esaminare le finalità degli elementi dello Scrum a singolo team e di capire come raggiungere lo stesso scopo pur mantenendosi entro i limiti delle “regole Scrum” standard. Se nell’intero gruppo R&S vi fossero state solo sette persone, le implicazioni del cambiamento nell’adottare un vero Scrum a singolo team non sarebbero state eccessive, dal momento che molti elementi sarebbero stati in atto “organicamente”, quasi come in una start-up. Ma quando un gruppo tradizionale di R&S di 500 persone passa a Scrum, ci sono importanti implicazioni in questo cambiamento, che necessitano di piena comprensione e sostegno da parte del senior management e di chi produce in concreto.

Scrum standard 

Un piccolo (5-9 persone) team cross-funzionale di membri del team multi-learning che esegue tutti i passi per sviluppare il prodotto (un vero e proprio team specifico [5]), senza alcun sottogruppo specializzato all’interno del team, con l’unico titolo di “membro del team” o “sviluppatore” [6]. Implicazioni del cambiamento o dell’aumento di dimensioni Nessun gruppo separato di analisi, test, architettura, esperienza utente, piattaforma o altro. E nessun “tester” o “architetto” all’interno del team. Ciò implica lo scioglimento dei gruppi con una sola funzione esistente e dei ruoli manageriali di supervisione, oltre all’eliminazione dei percorsi di carriera e delle cariche tradizionali.

Scrum standard 

Il “titolare del prodotto” (per esempio il lead product manager) responsabile del ROI e dei costi, e in grado di decidere autonomamente e modificare il contenuto e la data di rilascio del prodotto, diventa lo Scrum Product Owner. Il “product owner” guida lo sviluppo direttamente sulla base del metodo “ispezionare e adattare”, e così è in ultima analisi responsabile per il rilascio del prodotto, in quanto tiene saldamente il volante in mano. Implicazioni del cambiamento o dell’aumento di dimensioni -Tradizionalmente, il “product owner” ha negoziato un contratto interno con i manager R&D basato su precise tappe di scopo e di date, lasciando a tali manager la responsabilità del rilascio del prodotto. Dal momento che ora il “product owner” governa direttamente, non vi è alcun spostamento della responsabilità di R & S per sviluppare il rilascio, così come non vi è alcun “contratto interno”. Visto che ora il “product owner” guida direttamente ed è responsabile per il rilascio, non vi è più nessuna figura responsabile del rilascio come un program o project manager dell’R&D o dell’IT: tale ruolo viene eliminato.

Leggi anche:  Data management, dati perfetti per l’intelligenza artificiale

Scrum standard 

A ogni Sprint di 2-4 settimane, dalla prima, l’incremento del prodotto deve essere “Done” e potenzialmente consegnabile: si tratta di un incremento potenzialmente rilasciabile. A ogni Sprint, il sistema deve essere implementato, integrato, completamente provato, documentato e in grado di essere installato. Implicazioni del cambiamento o dell’aumento di dimensioni – Il concetto di “big release” e il vincolo “non è pronto fino alla fine” si dissolvono. Ciò implica l’eliminazione di tutti i sistemi di gestione, le pratiche , i ruoli e le politiche relative alla “big release” che sono basate su una lunga fase di sviluppo disordinato parzialmente svolto prima che il sistema sia pronto. Scrum non è per “la fase di programmazione” dopo l’analisi e prima dei test. Non c’è una precedente “fase di analisi“ o “fase architetturale” e nessuna seguente “fase di integrazione test”. Si eliminano lo sviluppo del ciclo di vita sequenziale e i gruppi che erano connessi a ciascuna fase (il gruppo di analisi…).

Scrum standard

Il Team è auto-organizzante (si gestisce da solo) e ha il potere di decidere autonomamente come raggiungere il proprio obiettivo nello Sprint. Implicazioni del cambiamento o dell’aumento di dimensioni – Non vi è alcun team o project manager che guida o segue i membri del team, il che implica l’eliminazione dei ruoli di team leader e di project manager. Non c’è più alcun processo standard a livello di intera organizzazione che tutti devono seguire. Questo è semplicemente Scrum standard a singolo team, ma la sua adozione pone sfide soprattutto nei confronti delle tradizionali assunzioni di R & S e della progettazione organizzativa su scala. Pertanto, la maggior parte dei gruppi non adottano un vero Scrum, ma invece lo “personalizzano” in “falso Scrum” o “Scrum, ma …”, invece di cambiare se stessi.

Leggi anche:  Salute, benessere e alimentazione. L’AI nella prevenzione dei disturbi

Conclusioni

Un vero sviluppo agile con Scrum implica un profondo cambiamento per diventare un’organizzazione agile: non si tratta di una pratica, ma di un framework di progettazione organizzativa. Un’adozione agile di Scrum su larga scala inizia assicurandosi che il management comprenda le implicazioni organizzative, e che si siano dimostrate adottabili su scala ridotta.

 

Note: 

[1] Larman, Craig. Agile & Iterative Development: A Manager’s Guide. Addison-Wesley, 2003.

[2] Ericsson R&D Center Finland, “How we learn to stop worrying and live with the uncertainties”.

[3] Larman, Craig & Vodde, Bas. Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum. Addison-Wesley, 2008.

[4] Larman, Craig & Vodde, Bas. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010.

[5] Larman, Craig & Vodde, Bas. Feature Team Primer.

[6] Vodde, Bas. “Specialization and Generalization in Teams”.

 

Craig Larman è un consulente che si occupa soprattutto di principi, pratiche e lean thinking da parte di grandi società di sviluppo software, oltre a essere coach di executive team per l’introduzione nelle aziende delle metodologie Agile e Lean. Questi argomenti sono stati trattati nelle sue due opere più recenti “Scaling Lean & Agile Development: Thinking & Organizational Tools” e “Practices for Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Product Development with Large-Scale Scrum”. Craig è tra l’altro stato uno dei primi consulenti al mondo a essere autorizzati ad agire da coach e a certificare nuovi ScruMasters.

Craig Larman presenterà a Roma per Technology Transfer i seminari: “Agile Software Development: Hands-on Practices, Principles, Agile Modeling, and TDD” il 12-16 maggio 2014, “Agile TDD and Refactoring” il 19-20 maggio 2014 e “Certified ScrumMaster Course PLUS” il 21-23 Maggio 2014.