Le 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.
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.
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.
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.
