Primi passi con SCRUM - step3

Continuando il mio studio su SCRUM e Agile planning in generale ho trovato un pò di materiale interessante che vorrei condividere in questo articolo generalista insieme anche a qualche mia considerazione personale.

Partirei con la fantastica vignetta presa in prestito da implementingscrum.com in cui viene spiegata la differenza tra i membri del Team di lavoro (completamente coinvolti sul progetto) e il resto del mondo (solamente interessato), ovvero nell’immaginario fumettistico di SCRUM i maiali e le galline.



Il senso di questa vignetta, al di la della battuta in se, non andrebbe mai sottovalutato. Stiamo dicendo che solo chi andrà realmente a lavorare sul progetto avrà in mente tutte le criticità e le stime migliori, quindi in generale devono essere il team con lo Scrum Master a governare le sorti del progetto stando attenti a non deragliare in seguito a interventi esterni da parte di gente “solamente interessata”.
Quello che succede nella realtà in effetti è che i “solamente interessati”, forse perchè dotati di maggior potere o visibilità all’interno del progetto, riescono quasi sempre a portarlo in una direzione ben diversa da quella ipotizzata all’inizio dei lavori e poi come in un incubo ci si trova ad inseguire date impossibili e scadenze assurde.

SCRUM come sappiamo, prevede la presenza di due figure particolari: lo Scrum Master e il Product Owner e in teoria sta a loro mediare l’intervento di tutte le altre “galline” interessate a determinati aspetti del nostro progetto.

Quello che ho capito fino ad ora è che in effetti l’adozione di SCRUM, come penso anche di altre metodologie, non può avvenire per imposizione di poche persone ma deve essere un percorso condiviso a tutti i livelli dell’azienda in cui si lavora.
Ho letto a proposito dei vari scenari possibili:

1. La scelta di SCRUM arriva dall’alto, l’azienda impone SCRUM ai gruppi di lavoro.
2. La scelta di SCRUM arriva dal basso, uno o più Project Manager che decidono di adottarlo all’interno dei progetti che seguono.
3. La scelta di SCRUM non è radicata ma dato che va di moda si decide di provare...

In tutti i casi, si perde in partenza dato che la scelta di SCRUM deve essere condivisa a tutti i livelli e la motivazione sull’utilizzo del metodo deve essere ben spiegata e capita da ogni livello della catena che riceve l’informazione.
Ciascuno avrà dei vantaggi specifici nell’adottare la metodologia ma questi vantaggi vanno adattati alle specifiche figure:

• Sviluppatori: lavoro più organizzato, maggiori responsabilità e potere decisionale sulle scelte applicative.
• Project Manager: maggiore adesione alle specifiche ed ai requisiti previsti per un determinato sprint. Per la serie “pochi ma buoni”.
• Marketing: rilasci cadenzati a tempo con demo funzionanti e roadmap ben definite.
• Dirigenza: progetti più rapidi e gestibili in grado di andare incontro ai repentini cambiamenti imposti dai clienti.
• Amministrazione: progetti maggiormente sotto controllo dal punto di vista di tempi e costi.
• Ufficio personale: persone più motivate e concentrate anche se “la pratica” di SCRUM può sembrare quantomeno insolita e singolare.

Tanto per parlare in concreto, il mio caso rientra nel precedente punto 2 ovvero comprendo le potenzialità del metodo ma non sono nella condizione di farlo partire concretamente a meno di pochi piccoli aspetti che ho inserito nel modo di lavorare mio e delle mie persone:

• Incontri settimanali di allineamento,
• Adozione di un portale documentale,
• Tentativo di introduzione dello sviluppo test driven sui nuovi progetti,
• Responsabilizzazione e autonomia del team di lavoro,
• Tentativo di ottenere rilasci a tempi fissi e pre-determinati.
• Gestione di un software per la gestione delle priorità sulle attività da svolgere.

Questo breve elenco ovviamente non porta a molto più che una discreta organizzazione del lavoro. I fattori sui quali non si riesce comunque ad agire sono:

• Il coinvolgimento delle persone individuate come potenziali Product Owner,
• L’imposizione degli sprint come unità di lavoro atomiche all’interno delle quali si rispettano gli accordi presi e si va dritti in quella direzione senza cambiare le carte in tavola,
• Tanti altri aspetti che non voglio nemmeno elencare :-)

Come si fa allora a sapere quando gli aspetti e gli accorgimenti introdotti sono ragionevolmente prossimi allo “SCRUM da manuale” ?

In effetti lo SCRUM da manuale prevede ovviamente molti aspetti diversi che ripercorrono i vari elementi e ruoli introdotti dal metodo, in particolare:

• Il Product Owner (PO) deve essere ben identificato e deve avere consapevolezza e competenza sul progetto in modo poter assegnare delle priorità funzionali allo svolgimento dello stesso. Naturalmente sarà l’interfaccia unica per il team di lavoro e gli attori esterni coinvolti nel progetto.
• Il Product Backlog (PBL) deve essere aggiornato dal Product Owner in base alle nuove priorità e richieste che possono arrivare dal cliente ma sempre tenendo conto delle stime fornite dal Team di lavoro. Gli elementi del PBL, le storie, saranno abbastanza piccole da poter essere inserite all’interno degli Sprint di tempo pre-fissato evitando quindi di avere delle “storie epiche”, così dette, a priorità alta. Al fine di rendere il PBL chiaramente compresibile per tutti, sarà utile non entrare troppo nei dettagli tecnici che stanno dietro ad una storia ma restare bensì ad un livello di astrazione che basti ad esprimere il tema in oggetto (es. “migliorare i meccanismi di cache per consentire accessi più rapidi alle pagine di un portale” si potrebbe tradurre con “ridurre i tempi di attesa per gli utenti che navigano il portale”, poi che questo venga fatto migliorando effettivamente la cache o ottimizzando il database non è un tema da far emergere a questo livello).
• Lo Sprint Planning Meeting (SPM) deve essere fatto con la presenza di tutto il Team di lavoro e del PO. Durante lo SPM vengono fatte le stime, date le priorità e alla fine ci si accorda su quello che sarà il lavoro effettivo da svolgere durante il singolo Sprint. E’ opportuno che emerga per ogni storia la “definition of done” ovvero il PO e il Team di lavoro devono essere d’accordo su quali sono le metriche che determinano che una particolare storia si possa considerare terminata. Questo dovrebbe evitare che a posteriori saltino fuori problemi del tipo “questo non basta, la funzione doveva prevedere anche...”. Se vi siete trovati almeno una volta in questa situazione direi che il concetto di DoD deve essere sicuramente apprezzato e condiviso senza particolari obiezioni.
• Lo Sprint Backlog (SBL) deve esistere ed essere aggiornato quotidianamente dal Team di lavoro.
• I Daily SCRUM, le demo e le retrospettive a fine sprint sono infine 3 aspetti assolutamente da non sottovalutare per garantire la motivazione del Team di lavoro, la visibilità di quello che si sta facendo, la presenza attiva sul progetto e la riflessione davanti a errori o situazioni critiche che si possono ripetere.

Io segnalo questa interessante checklist in italiano presa in prestito dal sito www.crisp.se che ripercorre i punti sopra elencati e altro ancora.

Inutile dire che il passo base è la presenza dei due principali protagonisti e la loro presa di coscienza. Parlo ovviamente del Product Owner e dello Scrum Masteri.
Il mio ruolo al momento sarebbe quello di Scrum Master ma non riesco a trovare un Product Owner con cui litigare :-) anzi quel che è peggio è che spesso i due ruoli convergono su me stesso e magari mi trovo anche a implementare qualche riga di codice...
Non credo di essere comunque un caso isolato o un’eccezione particolare penso che in tanti si possano ritrovare in questa situazione “molto italiana”.
Dato che il mio bicchiere è però sempre mezzo pieno mi sono ulteriormente divertito a immaginare gli scenari “american-corporate” descritti in questo ottimo libro tradotto anche in italiano: SCRUM e XP dalle trincee.
Il libro descrive l’adozione della metodologia e i problemi reali riscontrati e risolti.
Quello che emerge è che in effetti SCRUM più che una metodologia è un framework con oggetti, regole e strumenti. Come poi il tutto venga orchestrato per ottenere un buon risultato dipende esclusivamente dalla nostra esperienza e dalla voglia di portare a termine il compito di aderire nei fatti alla pratica di SCRUM.

Giusto per avere tutto sotto mano, ecco anche una scheda di sintesi che ripercorre le fasi fondamentalli dello SCRUM tutto in un’unica pagina.

Prossimamente, se trovo il tempo, proverò a descrivere alcuni aspetti di “agile planning” un tema interessante che se si ha a che fare con le stime di progetto può diventare veramente molto utile.

Hope this help, buono SCRUM a tutti.