Errori da evitare in un progetto Scrum

In qualsiasi progetto la possibilità di errore è sempre dietro l’angolo.

D’altra parte, sbagliare è umano e non è sempre addebitabile alla responsabilità di qualcuno.

Certamente con l’esperienza si cresce e si impara a sbagliare di meno.

Ci si sente più responsabili e attenti ai particolari dove possono nascondersi innumerevoli possibilità di sbagliare.

Si impara anche ad avere meno fretta che costituisce senza dubbio alcuno la principale causa di problemi per chi deve gestire un progetto.

Possiamo avere errori nelle stime, errori di pianificazione, errori di reporting, errori di comunicazione ecc.

Un progetto gestito con la metodologia Scrum, oltre ad essere soggetto ai suddetti problemi, è anche soggetto ad alcune difficoltà che possono insorgere se l’applicazione del metodo non viene intesa in modo corretto.

Tutte le discipline agili sono ancora “giovani” così come sono giovani molti Scrum Master e quindi può essere utile rivedere i principali errori in un progetto gestito con questo approccio.

Alle persone non importa nulla di Agile

In molti casi chi lavora in settori innovativi ed applica questi nuovi approcci si sente portatore di una nuova dottrina.

Alcuni Scrum Master commettono l’errore di usare troppo spesso le parole “Agile, Scrum, Kanban” per giustificare il da farsi.

Non è la metodologia che fissa gli obiettivi. Semmai dovrebbe aiutare a raggiungerli. Agile è solo una mentalità.

Alla gente non importa di Agile o Scrum. Vogliono realizzare qualcosa e hanno bisogno di qualcuno che dia loro una mano nell’ottenere ciò che vogliono.

Se Agile e Scrum non aiutano a raggiungere questi obiettivi, le persone saranno resistenti ad applicarli.

I membri dei team di sviluppo molto spesso non vogliono fare gli incontri previsti da Scrum.

Odiano le pianificazioni di sprint troppo frequenti. Retrospettive? Ancora peggio. Perché se fosse per loro si dovrebbe lavorare in un altro modo, indipendentemente da tutti i vantaggi che Agile o Scrum hanno portato.

Alcune persone hanno bisogno di tempo per comprendere l’importanza di avere dei meccanismi di controllo e di allineamento in un processo che altrimenti verrebbe lasciato all’anarchia.

Ma appellarsi alle parole Agile o Scrum non farà scomparire i problemi.

Uno Scrum Master dovrebbe porsi sempre le seguenti domande:

1. Cosa voglio ottenere?
2. Come sarà lo scenario quando il lavoro sarà completato?
3. Cosa potrebbe impedirmi di arrivarci?
4. Cosa devo fare per arrivarci?
5. Sono convinto di essere all’altezza?

Se si riesce a connettere Agile e Scrum ai 5 punti precedenti allora si può stare tranquilli che le persone ci seguiranno.

Non è solo una questione di management

Il fatto di dover gestire delle persone è fuorviante e di conseguenza è fonte di errore.

Uno Scrum Master non si deve preoccupare di gestire. Il suo particolare contributo consiste nel migliorare costantemente il sistema di lavoro, la cultura dell’azienda e rimuovere i colli di bottiglia.

A questo ruolo non corrisponde un rango particolare. E’ solo un distintivo mentre si è in servizio.

Lavora con le persone per aiutarle a fare bene il loro lavoro. Per fornire loro ciò di cui hanno bisogno in anticipo, prima che qualcosa possa diventare un problema, un fattore bloccante. E’ lì per comunicare con il management sugli impedimenti che il team non è in grado di risolvere da solo.

Mettere pressione alle persone è un errore

Un team ha bisogno di affiatarsi, di maturare, di trovare il ritmo e di scoprirsi capace di ottenere risultati gratificanti.

Tutto questo richiede tempo.

Uno Scrum Master deve agire da facilitatore di questo processo, Senza forzature, deve consentire ai membri del team di decidere come ripartirsi i compiti. Deve solo responsabilizzare sui risultati ed intervenire per eccezioni quando i risultati non sono soddisfacenti.

E’ molto comune per uno Scrum Master:

1. Assegnare compiti invece di responsabilizzare il team.
2. Inserire user story nel Product Backlog al posto del Product Owner.
3. Pianificare lo Sprint Backlog in anticipo al posto del Product Owner.
4. Fare delle stime anziché farle fare al team.
5. Aggiornare la scheda Kanban anziché farlo fare al team.
6. Fare calcoli per costruire grafici di burndown anziché utilizzare un software.
7. Sentirsi responsabile di tutti i problemi invece di coinvolgere anche il management.
8. Scegliere e configurare il software di gestione dei progetti invece di condividere la scelta con il Product Owner ed il management.
9. Decidere cosa è e cosa non è un impedimento anziché discuterne con il team.

Lo Scrum Master non è un capo. Deve agire come un allenatore e quindi deve esercitare Coaching e Mentoring nei rapporti con il team.

L’eccesso di burocrazia è un errore

Le modalità di lavoro vanno concordate con il team.

Semmai lo Scrum Master deve aiutare a migliorare gli standard e deve evidenziare in corso d’opera le eventuali violazioni rispetto a quanto il team ha precedentemente concordato. Questo aiuta il gruppo a crescere.

Inoltre, definire priorità e piani senza coinvolgere il Product Owner è un ulteriore errore.

Lo Scrum Master può suggerire, proporre, supportare, ma non è suo interesse sostituirsi agli altri. Finirebbe col sentirsi addossare scelte che non ha voluto condividere. Al danno del super lavoro finirebbe per sommarsi la beffa della presa di distanza degli altri stakeholder.

Fare micro-management è sempre un errore

Seguire molto da vicino la squadra è utile dal punto di vista della tempestività del supporto che si può fornire.

Ma eccedere nel dare continui input e suggerimenti è problematico.

L’importante è concentrarsi sul valore creato per il cliente. Questa è la metrica più importante.

Occorre ragionare end-to-end e lavorare sui colli di bottiglia. Aiutare il team ad individuarli per poi trovare insieme le soluzioni.