Introduzione

Anni fa — a dire il vero, parecchi anni fa — un collega di allora “confessò” ad alcuni di noi che stava seguendo un “corso” per smettere di fumare. Si trattava in realtà di una serie di incontri in cui figure professionali diverse, tra cui uno psicoterapeuta, aiutavano un piccolo gruppo di persone, seriamente intenzionate, a superare i momenti iniziali del distacco e a rafforzare la motivazione di chi aveva deciso di abbandonare la sigaretta.

Quando chiedemmo al nostro collega di che cosa si trattasse, ci colpì un aspetto della “pratica” che lui aveva colto e metteva in grande risalto: tutto aveva un’impronta “positiva”. Piuttosto che sugli ovvi e ben conosciuti danni derivanti dal fumo di sigaretta, coloro che stavano smettendo venivano fatti concentrare sui miglioramenti al benessere generale che sarebbero derivati dall’abbandono del fumo. Piuttosto che rafforzare la motivazione con frasi come “Non devo fumare perché mi fa male”, “Voglio smettere di fumare” e cose del genere, venivano proposti ai partecipanti dei “mantra” che suonavano più o meno così: “Il fumo è noioso”, “Fumare è un interesse secondario” e cose del genere, che al momento non ricordo perfettamente nelle parole esatte, ma il cui tono era proprio questo, di sufficienza e non di negazione.

“Concentrarsi sugli aspetti negativi, sugli errori commessi” — ci diceva il nostro collega — “finisce per riforzare proprio quegli aspetti e non favorisce un miglioramento e una svolta nella propria condizione”. Questa era la motivazione che era stata data all’approccio “positivo” di tutto il percorso, o perlomeno questa era quella che il nostro collega aveva colto. Non ho alcuno strumento per ritenere se la cosa avesse un senso e una base scientifica ma, di fatto, il nostro collega — persona peraltro molto metodica e determinata sul lavoro — smise in effetti di fumare come si era prefisso e, almeno per gli anni prima che le nostre strade professionali si separassero, mai tornò a farlo.

Pattern e antipattern

Questo episodio avvenne nel periodo in cui nel mondo IT, in senso lato, ci si occupava primariamente di linguaggi e architetture di sistema. In quel panorama, era pratica consueta studiare i pattern architetturali — e se sfogliaste gli “arretrati” di MokaByte risalenti a dieci/quindici anni fa trovereste decine di articoli che ne parlano — nonché i cosiddetti antipattern, ossia dei “modelli negativi”, tanto tipici quanto diffusi perché apparentemente risolutivi, che però andavano a rovinare tutte le migliori intenzioni nel realizzare sistemi che si accordassero ai canoni architetturali più sensati.

E questo episodio mi è tornato in mente proprio in questo periodo a proposito della pratica Scrum: meglio concentrarsi solo sul proporre e favorire modelli positivi, oppure ha senso anche individuare errori tipici che a più riprese e in gruppi diversi si riscontrano nell’adottare e mettere in pratica Scrum?

Indicazioni dalla Scrum Guide

Non è un caso se proprio la Scrum Guide ufficiale [2] definisca Scrum come “semplice da comprendere, difficile da padroneggiare”. E proprio in queste brevissime affermazioni si potrebbero trovare le motivazioni per dire che ha senso anche mettere in luce errori tipici insiti nella messa in atto dei vari elementi di Scrum.

Come sanno tutti coloro che conoscono la “infrastruttura” di Scrum, in Scrum abbiamo una serie di elementi costitutivi. Oltre al non secondario elemento dei valori, nella sua ultima edizione la guida individua

• il team Scrum: Product Owner, Scrum Master, gruppo di sviluppo, ossia quelli che in precedenza venivano definiti ruoli;
• gli eventi Scrum: Sprint Planning, Sprint, Daily Scrum, Sprint Review e retrospettiva, ossia quelle che in precedenza venivano definite “cerimonie”
• i “manufatti” Scrum: Product Backlog, Sprint Backlog e incremento, generalmente chiamati artefatti con una erronea traduzione dall’inglese.

In ognuna di queste tre aree potremmo sicuramente riscontrare degli errori tipici e ricorrenti, che una volta messi in evidenza possono portare a una rimozione delle “cattive pratiche” e a un miglioramento del processo.

In particolare, cercheremo di seguire i comportamenti delle persone che ricoprono i ruoli e individuandone gli errori nel corso delle varie “cerimonie” che essi conducono all’interno dell’infrastruttura metodologica.

Errori tipici e dove trovarli

Chiaramente si tratta di un tema trattato a più riprese e da più autori, specie nelle conferenze dedicate al mondo Agile, al punto che c’è chi si è spinto a parlare dei “sette peccati capitali” in Scrum [2] o chi ha realizzato delle carte degli antipattern in Agile [3] in cui vengono illustrate pratiche che, per quanto sembrino anche adeguate, in realtà rappresentano dei passi verso la disfunzione e la non riuscita.

Nella nostra breve trattazione, presenteremo alcune disfunzionalità effettivamente riscontrate e le commenteremo in maniera stringata. Crediamo infatti che già un elenco ragionato di tali errori ricorrenti possa aiutare a individuare quello o quelli in cui il nostro gruppo di lavoro ricade più frequentemente — non è detto che tutti siano protagonisti di tutti gli antipattern presentati — e, magari dopo attenta retrospettiva, a determinare le azioni da intraprendere per liberarsene e per continuare sulla strada del miglioramento continuo.

Ad ogni modo, non ci stancheremo mai di dire che, prima ancora che su pratiche, errori, antipattern e via dicendo, occorre concentrarsi sullo sviluppo di una mentalità improntata ai valori e ai principi dell’agilità.

E poi occorre ricordare che, per ovvie ragioni, spesso chi “interpreta” un determinato ruolo è portato a non vedere con chiarezza i comportamenti potenzialmente “distorti” che lo riguardano, ma è capace di osservare quelli che si evidenziano negli altri. Da questo sguardo incrociato — tradizionalmente destinato a sfociare in recriminazioni e accuse con il dito puntato — può invece nascere un franco ma costruttivo dialogo e una presa d’atto di certi comportamenti che portano a un loro miglioramento.

Errori tipici che riguardano il Product Owner

Il principale campo di azione di un PO è l’area del Product Backlog e del suo raffinamento, ma non significa che certi errori non vengano commessi anche in altri ambiti. Vediamoli di seguito

PO e Product Backlog

Un primo, significativo, errore ricorrente per il PO è quello di non essere davvero lui a stabilire le priorità, ma di fungere da “passacarte” nel senso che si limita a recepire e trasmettere le priorità stabilite dagli stakeholder. Succede a volte, e anche in maniera inconsapevole, ma deve essere chiaro che questo inficia tutto il lavoro: stabilire le priorità nel backlog spetta al PO e questo deve essere chiaro a tutti fin dal principio.

Un altro comportamento potenzialmente molto pericoloso è quello di non prendersi cura a sufficienza del Product Backlog. Il Product Backlog è un’entità “viva” e — passatemi il paragone — come con un animale domestico, non può essere abbandonato a sé stesso: ha bisogno di cure e attenzioni continue e quotidiane. Deve essere curato, riordinato, raffinato, controllato.

Qualche segnale di mancanza di cura del Product Backlog è però abbastanza facile da riscontrare e può consentire aggiustamenti. Ad esempio, se il Product Backlog è troppo grosso e contiene più elementi di quelli che il Dev Team potrà realizzare nell’ambito di alcuni sprint (tre, quattro, cinque?) vuol dire che è stato un po’ lasciato a sé stesso ed è diventato più un “ripostiglio” che non un vero e proprio backlog. Stesso dicasi se ci sono dentro elementi “invecchiati” che non vengono toccati da più di tre o quattro sprint o se ci sono elementi non bene definiti, che hanno solo il titolo e nient’altro.

Accanto a questi, c’è un altro potenziale comportamento “pericoloso”, quello del superPO che fa un po’ tutto lui… Da chi non crea le storie insieme al team di sviluppo in un processo collaborativo, a chi pur collaborando con il team, impone anche il modo in cui le storie debbano essere implementate, magari con precise indicazioni tecniche — è questo un compito del Dev Team, invece —, a chi, infine, pensa di essere onnisciente e non interroga gli stakeholder o degli specialisti tecnici per supportarlo nel processo di raffinamento.

PO e Sprint Planning

Anche nell’ambito della pianificazione dello sprint il PO può compiere errori tipici e ricorsivi.

Uno dei più comuni consiste nel non essere in grado di fornire un obiettivo chiaro, focalizzato e misurabile per lo sprint in questione: senza questo, il Dev Team avrà difficoltà a definire la sua parte di Sprint Planning.

Altro errore piuttosto comune da parte del PO consiste nel non valutare esattamente lo “stato di forma” del Dev Team e spingere affinché esso accetti in carico più lavoro di quanto realisticamente possa completare. Magari alcuni precedenti indicatori potrebbero far pensare che ce la faranno, ma non sarà così.

PO e Sprint

Il PO può compiere errori anche nel corso dello Sprint vero e proprio. Un tipico esempio è quello del PO assente: dopo aver svolto correttamente il suo lavoro nelle fasi di raffinamento del Product Backlog (che deve continuare) e di Sprint Planning, il Product Owner diventa assente, lasciando il team di sviluppo a “sbrigarsela da sé”.

A ben guardare è un po’ una sorta di riedizione del waterfall e, sebbene il team debba effettivamente lavorare in autonomia, il PO deve essere sempre disponibile a rispondere a domande e interrogativi che possano sorgere.

Sempre nell’ambito di una sorta di micro-waterfall 2.0 ricade il caso in cui il PO divenga inflessibile nell’aggiustamento dei criteri di accettazione una volta che questi si dimostrino inadatti alla situazione nelle mani del team di sviluppo.

Si suole dire che, finché gli elementi da sviluppare stanno nel Product Backlog, essi sono di pertinenza del PO, ma una volta che entrano nello Sprint, è il team a diventarne “padrone”. Esiste, ed è un problema a cui fare attenzione, la tendenza da parte del PO a continuare a considerare sua “proprietà” gli elementi che sono in sviluppo, con la conseguenza, ad esempio di allargare lo scope della storia una volta che essa già sia in lavorazione, altro tipico errore.

PO e Daily Scrum

Un evento in cui il PO può fare pochi danni, se è presente, è quello del Daily Scrum, fortunatamente. Qui il tipico antipattern è quello di trasformare la riunione stand-up del mattino in una sorta di estensione dello Sprint Planning in cui si discutono nuovi requisiti o si raffinano le storie utente.

PO e Sprint Review

Per concludere, un errore tipico del PO si manifesta in fase di Sprint Review, che non viene sfruttata al massimo come opportunità per migliorare la collaborazione tra PO, portatori di interesse e team Scrum.

Questo errore consiste nell’impiegare la Sprint Review per l’accettazione delle user stories implementate dal Dev Team; ma in realtà, tale accettazione andava fatta in concomitanza con la loro realizzazione e il soddisfacimento dei criteri di accettazione.

Come è possibile vedere da questa lista, il ruolo del Product Owner è giustamente considerato il più difficile nell’ambito della infrastruttura metodologica Scrum. Tante e tali sono le interazioni e la complessità che si genera a partire da esse, che è più facile che si evidenzino errori.

Errori tipici che riguardano lo Scrum Master

Probabilmente il ruolo dello Scrum Master è quello che può commettere errori per le più svariate ragioni: può accadere che ci siano Scrum Master molto bravi che però si trovano a interagire con un team disfunzionale o non all’altezza da un punto di vista tecnico, oppure, viceversa, che chi viene chiamato a ricoprire il ruolo non abbia le caratteristiche e/o la necessaria preparazione per svolgerlo al meglio.

Non è facile, infatti, mettere insieme quei tratti di pazienza, flessibilità, mancanza di dogmatismo, autorevolezza e al contempo capacità di comprendere la situazione nel suo complesso che sono necessari a un bravo Scrum Master.

Un errore che riguarda lo Scrum Master in senso generale è quello di intenderne la figura come quella di un manager in senso classico da organizzazione del lavoro taylorista: lo Scrum Master non è un “supervisore”, non è un “guardiano dei tempi e dei modi”, ma agisce con un approccio che deve favorire l’auto-organizzazione del team e far emergere le qualità, le capacità e l’assunzione consapevole di responsabilità da parte di tutti i componenti del Development Team.

Chiaramente, non si deve cadere neanche nell’errore opposto, quello di diventare lo Scrum Master “chioccia” o “mamma” che risolve in prima persona i problemi o che, per garantire l’importante aspetto dell’armonia della squadra, non mette in luce e non affronta eventuali problemi o conflitti che si manifestino, chiaramente sempre nell’ottica della risoluzione e non della recriminazione.

SM e Sprint Planning

L’errore più tipico dello Scrum Master in fase di Sprint Planning consiste nel non dimensionare adeguatamente lo Sprint Backlog.

Se regolarmente il team accetta dal PO troppi elementi, più di quanti sia in grado effettivamente di “digerire” durante lo Sprint; se buona parte (la metà?) degli elementi da implementare in uno Sprint finisce regolarmente per “avanzare” per lo Sprint successivo; se magari si riesce anche a completare il 100% delle storie, ma regolarmente non c’è mai tempo “libero” per colmare il debito tecnico che si accumula di Sprint in Sprint, significa che che lo Scrum Master non sta svolgendo bene il suo ruolo, che contempla anche il fatto di mettere un limite a quello che si può fare in uno Sprint. Ricordiamoci sempre che sono necessarie anche delle “casse di espansione” in cui far “tracimare” le “piene” che inevitabilmente il flusso degli eventi ci proporrà.

Altro errore tipico è quello di accettare storie non sufficientemente dettagliate: se il PO fornisce storie che non sono state raffinate a sufficienza, il problema è a monte e non è con l’accettazione passiva da parte del Dev Team, senza l’intervento dello Scrum Master, che questo problema sarà risolto.

SM e Sprint

Lo Sprint è la “fase di gioco” di Scrum in cui la presenza e l’azione dello Scrum Master emerge forse in maniera più evidente. In quanto tale, è anche una di quelle in cui si rischiano i più comuni errori ricorrenti. Una chiave per la riduzione di tali errori da parte dello Scrum Master può essere — rimanendo alla metafora sportiva — di ricordarsi sempre che Scrum è uno sport di squadra: mentre le conoscenze e le capacità individuali sono importanti ed è bene che emergano, gli atteggiamenti e i comportamenti da “primedonne” sono un sicuro indicatore di fallimento.

Di tutti gli errori che uno Scrum Master può commettere nell’ambito dello Sprint, forse il più comune e sfaccettato è quello di consentire l’interruzione del flusso di lavoro. Lo Scrum Master sa che, una volta che sia stato decretato l’avvio di uno Sprint, questo non deve essere disturbato o interrotto, se non per casi eccezionali. Sta quindi a lui “proteggere” — anche se il verbo non è proprio il migliore — l’integrità dello Sprint e la “tranquillità” del Development Team: gli stakeholder, inevitabilmente, porranno in atto comportamenti che rischiano di disturbare o interrompere il flusso di lavoro; e non lo fanno perché sono “cattivi”, ma semplicemente perché vedono le cose dalla loro prospettiva che non sempre è la stessa del Team Scrum.

Uno Scrum Master commetterà l’errore di consentire l’interruzione del flusso di lavoro se avrò un atteggiamento troppo arrendevole nei confronti del modo in cui “le alte sfere” possono disporre dei vari elementi del Dev Team (spostandoli, convocandoli per interminabili riunioni, assegnando loro direttamente altri compiti, ingerendo nella composizione dello Sprint Backlog a Sprint iniziato, intervenendo al Daily Scrum e trasformandolo da stand-up meeting in qualche altro tipo di riunione). Ricordiamocelo sempre: il team di sviluppo si auto-organizza, altrimenti non è Scrum.

Altro errore tipico dello Scrum Master è quello di non intervenire tempestivamente: se ci sono dei task che non avanzano di stato nel giro di due giorni, qualcosa non va. Magari chi se li è presi in carico ha delle difficoltà di qualsiasi tipo e non deve essere lasciato da solo: la ragione per cui si aggiungono i “pallini rossi” ai task che non avanzano non è legata a una colpevolizzazione di chi li sta facendo, ma all’esatto contrario, cioè al fatto che lì ci sono dei problemi che necessitano di sostegno.

Altro errore tipico è quello di non raccogliere dati utili per la retrospettiva. E con questa annotazione, che non necessita di spiegazioni, passiamo al paragrafo successivo.

SM e retrospettiva

Sul tema delle retrospettive al termine dello Sprint (e non solo quelle) rimandiamo sicuramente alla lettura della Parte V di Guida Galattica per Agilisti [4] dove sono trattate estensivamente le ragioni, le tipologie e le modalità per condurre una retrospettiva, e dove non mancano anche indicazioni sugli errori tipici che si possono commettere.

In questo paragrafo, vediamo quindi solo brevemente il tema degli errori nelle retrospettive di Sprint in relazione al ruolo dello Scrum Master.

Il primo e più evidente errore ricorrente è… non fare la retrospettiva. Magari lo Sprint è andato benissimo, magari non c’è tempo, magari si farà comunque al termine del prossimo Sprint. Se “inspect & adapt” è uno dei principi cardine di Scrum, è anche vero che Scrum è un sistema ordinato e con poche regole, chiare, che però vanno applicate. La retrospettiva è un momento fondamentale dell’infrastruttura metodologica Scrum, e va fatta.

Un secondo errore è fare retrospettive di bassa qualità: non cambiare mai formato, durata o luogo di svolgimento; non tenere una documentazione — per quanto stringata, anche solo con un po’ di testo scritto e qualche foto — che funga da memoria di quanto è stato fatto e deciso.

Ancora più in là ci si spinge con l’errore di fare retrospettive sbagliate, ossia retrospettive che, in fin dei conti non sono tali ma diventano qualcosa di diverso. È il caso della retrospettiva “processo” o “recriminatoria” in cui, invece di riflettere sui problemi evidenziati per adottare soluzioni in grado di garantire il miglioramento, si finisce per incolpare qualcuno delle eventuali criticità manifestatesi, oppure si degenera in una sterile sessione di recriminazioni e accuse incrociate.

Sappiamo che questi sono meccanismi assolutamente da disinnescare e il bravo Scrum Master deve avere nel suo repertorio tante possibilità per far sì che questo importante momento non diventi un potenziale “talk show televisivo” ma sia un punto fondamentale per garantire il miglioramento continuo, oltretutto scandendo il passaggio da uno Sprint concluso alla successiva pianificazione dello Sprint che seguirà.

La retrospettiva deve essere un momento in cui si avverte una sorta di “sicurezza psicologica”, in cui nessuno offende nessuno, né tantomeno è preponderante sull’intero gruppo. In tal senso, occorre ricordarsi che, a differenza di altre fasi in cui si favorisce il dialogo continuo con i portatori di interesse, quello della retrospettiva sullo Sprint è un momento in cui gli stakeholder non devono intervenire. Lo Scrum Master conosce questa regola e deve farla rispettare, indipendentemente dalla direzione da cui provenga la richiesta di partecipazione degli stakeholder: in qualche caso potrebbe addirittura essere il Team a chiederla, per “sviare” la necessità di un confronto interno e coinvolgere un elemento “esterno” verso cui riversare attenzione e responsabilità.

Errori tipici che riguardano il Development Team

Anche il gruppo di sviluppo può ricadere in tipici comportamenti disfunzionali. E va anche considerato che, a differenza che con il PO e lo SM, qui stiamo parlando di gruppo: il Dev Team è un’entità di per sé complessa anche per il fatto di essere composta da un certo numero di persone (che tipicamente è maggiore di 3 e minore di 9), ognuna con le sue esigenze, la sua personalità e la sua propensione alla e capacità di comunicazione.

Se spetta allo Scrum Master lavorare per mettere il Dev Team nelle condizioni migliori affinché comprenda sempre meglio Scrum, si autoorganizzi e si assuma le responsabilità che gli competono, solo i membri del team di sviluppo possono nel concreto adottare i comportamenti individuali che, opportunamente armonizzati, ne fanno una vera e propria squadra con obiettivi comuni e buona comunicazione interna ed esterna.

Dev Team e Sprint Planning

Un primo, banale ma pericoloso errore ricorrente è quello dell’assenza dei componenti del Dev Team in fase di Sprint Planning. Che si tratti di un solo assente o di più assenti, o addirittura di mancanza totale del team in questa fase (vedi sopra a “PO e Sprint Planning”), siamo nelle condizioni per cominciare uno Sprint nella maniera peggiore. Il Dev Team è parte integrante e fondamentale dello Sprint Planning.

Altro errore ricorrente è quello di dare per scontata la propria capacità di carico. Non è detto che, siccome si è fatto un determinato quantitativo di lavoro negli Sprint condotti fin qui si sarà in grado di fare lo stesso nel prossimo. Ci sono svariati elementi che possono entrare in campo e rallentare la velocità di sviluppo: l’ingresso di nuovi elementi nel team, l’assenza per malattia o per motivi più positivi di un elemento, l’abbandono di alcuni elementi che cambiano azienda o vita… Il Dev Team deve essere consapevole di tutto questo e sviluppare la capacità di autoorganizzarsi, rilevando la diminuzione temporanea della propria consuetà capacità di carico e manifestandola chiaramente al PO in fase di pianificazione dello Sprint.

Anche per il Dev Team (vedi sopra “SM e Sprint Planning) c’è l’errore di contribuire a non dimensionare adeguatamente lo Sprint Backlog. Se si carica eccessivamente lo sprint con le feature da implementare, non resta tempo per colmare il sempre presente debito tecnico, per lavorare alla correzione dei bug, per condividere “scoperte” e apprendimenti, per supportarsi tra colleghi nelle urgenze o nei casi di difficoltà che possano emergere senza che fossero previsti.

Di questo deve essere consapevole da un lato il PO, ma dall’altro ci deve essere la “rivendicazione” continua da parte di SM e Dev Team: un Team Scrum regolarmente sovraccarico — lasciamo stare l’occasionale situazione che può verificarsi di tanto in tanto — finirà per ridurre qualità e quantità del valore che rilascia, e questo è un dato di fatto misurato in tante situazioni differenti.

Un errore non troppo diffuso, ma piuttosto pericoloso, è poi quello di lavorare su sprint di durata irregolare. Invece di stabilire una precisa cadenza per lo Sprint (due, tre, quattro settimane), in fase di Sprint Planning si imposta una durata dello Sprint in base a “quello che c’è da fare”, ossia sono le storie scelte per lo Sprint che determinano la sua lunghezza. È l’esatto contrario di quello che Scrum propone con i suoi Sprint time-boxed, vale a dire che invece si devono scegliere le storie che è possibile implementare all’interno di un dato sprint di cadenza regolare e prestabilita.

Poi ci può anche essere la situazione in cui magari si decide di modificare, per quella sola occasione, la lunghezza standard dello Sprint, per ragioni contingenti. Ma la cadenza regolare degli Sprint e di tutte le attività ad essi connesse è una delle chiavi di volta dell’infrastruttura metodologica Scrum.

Dev Team e Sprint

Uno degli errori più comuni, più ricordati e comunque sempre commessi è quello di non tenere aggiornata la board. Se i ticket non vengono opportunamente mossi in maniera da riflettere lo stato corrente dello Sprint, se non si comunica chiaramente quello che si sta facendo, indicando le ragioni per cui si prende in carico un determinato task invece di un altro, il meccanismo dello Sprint si incepperà. Chiaramente è responsabilità anche dello SM che tutto questo venga facilitato e avvenga in maniera regolare, ma di fatto è il team che si auto-organizza e provvede a queste operazioni.

Altro errore tipico è quello di non porre un WIP limit sensato. Il Work In Progress deve avere un limite, secondo il principio dello “Stop starting, start finishing”, che sarà anche scontato, ma resta valido e importante. Lo Sprint deve rilasciare un incremento di prodotto potenzialmente consegnabile che fornisca valore agli stakeholder, e non risolversi nell’inizio di un numero indefinito di attività che non si sa se saranno concluse. C’è un numero massimo di task su cui il team può lavorare contemporaneamente in un certo momento, va compreso e va rispettato per migliorare il flusso ed evitare code. Creare code lunghe aumenta il periodo di tempo che intercorre tra la presa in carico di un task e il suo completamento.

Infine c’è un errore tipico che collochiamo qui e che potremmo chiamare fischi per fiaschi… Si tratta del caso, peraltro non raro, in cui lo Sprint procede bene, si lavora e si consegna qualcosa di funzionante… ma non era quello che il PO si aspettava e aveva richiesto. Qui il problema è principalmente di comunicazione e non dipende primariamente dal team di sviluppo.

Da un lato, il Dev Team deve chiedere lumi per ogni minimo dubbio al PO, e questo non sempre è facile quando i due ruoli si trovino lontani o il PO si assenti e così via. Dall’altro, probabilmente il PO ha raffinato la storia al punto tale che quando l’ha presentata al Dev Team, questo non si è reso conto di tutto quello che poteva esserci dietro. Quindi l’ha implementata ma senza avere una visione di insieme che comunque è sempre necessaria. Le retrospettive servono a chiarire queste incomprensioni, nell’ottica di evitarle in futuro.

DevTeam e Sprint Review

Durante la Sprint Review ci sono dei comportamenti tipici che non fanno rendere al massimo questa attività. Un tipico errore è di trasformare la demo in una presentazione o in un report. Non si tratta infatti di “presentare” qualcosa, magari con PowerPoint, e nemmeno di spiegare per filo e per segno che cosa e come è stato fatto. Si tratta invece di mettere gli Stakeholder nelle condizioni di provare qualcosa di funzionante e di utilizzare questa occasione per dare e ricevere feedback.

Può essere fatto ricadere in quanto appena detto, oppure essere considerato a sé, anche il comportamento tipico dell’impiegare un portavoce. Non è un buon segno per il Dev Team se a partecipare alla Sprint Review sono sempre le solite due persone, e magari solo una di queste parla. Sebbene non sia necessario — ma neanche vietato — che l’intero team prenda parte alla Sprint Review, è importante che ci sia una rotazione dei compenenti che partecipano alla demo e ricevono feedback. Un segno di grande maturità del Dev Team e quando questo non accade sulla base di “turni” decisi in maniera automatica e obbligatoria, ma si sviluppa da esigenze che di volta in volta cambiano e vengono discusse nel gruppo, nel vero spirito dell’autoorganizzazione.

Dev Team e retrospettiva

Vale in generale quanto detto sopra (vedi “SM e retrospettiva”) a proposito delle retrospettive di Sprint dal punto di vista dello Scrum Master (non fare la retrospettiva, fare retrospettive di bassa qualità, fare retrospettive sbagliate).

Ma se cambiamo prospettiva — perdonate il gioco di parole — e ci mettiamo nell’ottica del Development Team, emergono anche altre tipologie di errore.

Il primo è quello di considerare il tempo per la retrospettiva come un tempo supplementare per lo Sprint: in pratica, “Ci manca solo mezza giornata e poi avremmo finito le cose che dovevamo completare in questo Sprint! Quindi prendiamoci il tempo che era stato riservato alla retrospettiva per concludere il lavoro “serio” e… al diavolo la retrospettiva, tanto lo Sprint è stato concluso e pure bene. La faremo un’altra volta”. Non c’è molto da aggiungere: sembra una scelta sensata ma non lo è.

Il secondo è quello di trasformare la retrospettiva in una lamentazione collettiva: chiaramente la retrospettiva deve servire anche a tirar fuori ciò che non va, ma non deve diventare un rito collettivo di vittimismo, magari assecondato dallo Scrum Master. Alla fine della retrospettiva devono essere individuate collettivamente alcune azioni realisticamente realizzabili e che poi vanno messe in atto. Se c’è solo la fase dell’elencazione dei problemi, senza quella dell’individuazione del cammino per arrivare alle soluzioni, la retrospettiva serve a poco.

Per questo, in fase di retrospettiva, è anche buona cosa verificare cosa è stato fatto delle azioni da intraprendere che erano state individuate nella precedente retrospettiva: sono state implementate? Hanno dato qualche risultato? Le cose sono cambiate in meglio? Occorre rimanere sempre nel dominio del realistico: il cambiamento è possibile, ma è un processo lungo, che si fa passo dopo passo.

Conclusioni

Certamente qualche lettore avrà sicuramente individuato qualche errore tipico che il suo gruppo di lavoro commette: penso — e mi auguro — che ne siano stati riscontrati ben pochi.

Ma l’elencazione, invero un po’ pedissequa, di certi comportamenti ha avuto lo scopo di stimolare e motivare a cambiamenti che sono possibili sulla strada del miglioramento continuo. Sbagliando si impara, ma continuando a sbagliare si sbaglia…