5 false speranze di Scrum e come risolverle

Come molti conflitti classici e senza fine, il dibattito su come i team di sviluppo dovrebbero organizzarsi e autogovernarsi infuria. Attualmente, sembra quasi che ci siano più critici che fan di Scrum. I tre reclami più comuni sono:

1. Il processo può essere al centro del lavoro.
2. Può essere facilmente confuso con la microgestione con un altro nome.
3. Il quotidiano stand-up può sembrare un incontro in cui bisogna giustificarne l'esistenza.

In altri casi, i ruoli di Scrum non sono rappresentati adeguatamente. A volte, il product owner vuole troppe cose all'interno di uno sprint o vuole cambiare le priorità durante lo sprint: uno Scrum master che è ossessivamente concentrato sul mantenimento della velocità e sull'adozione di ogni nuova cerimonia Scrum che impara. Dopo un po' di tempo con il framework, sembra sorgere una domanda comune: "Siamo noi o la metodologia?"

Le false speranze di Scrum

Sebbene ci siano numerose disfunzioni come quelle descritte sopra, una semplice causa principale per la maggior parte di esse è che Scrum non è stato progettato per risolvere i problemi sottostanti all'interno di un'organizzazione semplicemente seguendo il processo. Non riconoscere questo può mettere in pericolo le nuove squadre quasi non appena iniziano.

Falsa speranza n. 1: Scrum fa lavorare i team più velocemente

Scrum utilizza una terminologia che suona a un estraneo come se accelererà il processo senza aggiungere risorse aggiuntive. È facile impantanarsi nella terminologia come un nuovo team in Scrum (ad esempio, cos'è uno Scrum Master? Qual è la differenza tra un product owner e un product manager? Cosa sono gli story point e come vengono assegnati?)

Più preoccupante è che molti vedono termini come velocità e sprint e pensano "velocità". Tuttavia, lo scopo di qualsiasi metodologia Agile, incluso Scrum, è quello di fornire un prodotto finito. Alla fine, man mano che il tuo team diventa più competente con Scrum, sarai in grado di fornire nuove funzionalità più velocemente. Tuttavia, la velocità non è necessariamente l'obiettivo principale. Questa distinzione dovrebbe essere articolata all'interno del tuo team Scrum e anche quando crei consapevolezza all'interno della tua azienda per supportare la metodologia Scrum.

Non stai vendendo velocità; stai vendendo il completamento.

Falsa speranza n. 2: la stretta aderenza a Scrum risolverà i problemi di cultura aziendale

Ognuno ha stili di lavoro diversi. Ad alcune persone piacciono le riunioni. Altri usano frasi come "lavora duro, gioca duro". È essenziale riconoscere che qualunque stile di lavoro apprezzi la tua azienda, ne stai accettando sia i vantaggi che gli svantaggi. È probabile che un'azienda che apprezza le riunioni abbia difficoltà a far fronte alla situazione quotidiana. I team aggressivi e orientati alla velocità avranno problemi con lo scorrimento della portata all'interno di uno sprint.

A volte è facile perdere di vista il quadro generale, in particolare per le squadre di recente formazione. Ciò che conta è fornire un prodotto finito invece di seguire fino all'ultimo bit del processo. Invece di incolpare la metodologia, cerca sempre modi per perfezionare il tuo stile di lavoro per raggiungere i tuoi obiettivi.

Falsa speranza n. 3: i contributori critici possono inviare i loro delegati alle riunioni

Una volta avviata la metodologia, è fondamentale che il team originale partecipi anziché delegare. Se c'è una lamentela quasi universale che vedo dagli sviluppatori, è che gli Scrum Master ei Product Owner non erano disponibili quando necessario e i loro delegati non erano autorizzati. A nessuno piace venire a una riunione aspettandosi una decisione solo per sentirsi dire che la persona che può prendere la decisione non è disponibile.

La delega può essere una pratica comune, ma in Scrum devi anche dare potere ai partecipanti.

Falsa speranza n. 4: gli stand-up quotidiani costringeranno tutti a essere più concentrati

La riunione quotidiana in piedi non dovrebbe essere focalizzata esclusivamente su ciò che tutti hanno fatto nelle ultime 24 ore. È molto più importante dare priorità all'emersione di blocchi stradali o nuovi approcci per risolvere un problema.

Scrum richiede che alcuni ruoli, in particolare lo Scrum master, siano assertivi ma non prepotenti. È importante che lo Scrum master crei un ambiente positivo che porti a prodotti completati.

Falsa speranza n. 5: avremo successo al primo tentativo

Scrum implica congetture, pensiero deduttivo e commettere errori. Le persone raramente lo fanno bene al primo tentativo. Scrum è iterativo sotto tutti gli aspetti: non solo nel modo in cui raggiungi un prodotto finito, ma anche nel modo in cui governi e gestisci il processo. Scrum è progettato per avere una bassa barriera all'ingresso per l'adozione da parte dei team, ma richiede anche l'impegno di iterare e migliorare continuamente la partecipazione al framework.

Come Riparare un Processo Scrum Rotto

Scrum resiste alla fallacia del costo irrecuperabile. La natura iterativa di Scrum crea opportunità per adattare o scartare processi inefficaci. Considera alcuni dei seguenti suggerimenti se il tuo processo Scrum non è efficace come ti aspettavi.

Affina le tue aspettative

Che si tratti di ridurre il time-to-market, creare prodotti interessanti o aiutare i team a collaborare, il successo richiede impegno e tempo. Per i nuovi team, un traguardo ragionevole da raggiungere è se dopo ogni sprint è possibile introdurre codice funzionante e verificabile nel proprio ambiente di produzione.

I team avanzati possono misurare il successo in base alla loro capacità di creare, testare e distribuire su richiesta. Sei in grado di strumentare e quantificare le reazioni degli utenti alle nuove funzionalità? L'organizzazione più ampia è pronta a supportare i cambiamenti che il team sta apportando al prodotto?

Potenzia i tuoi partecipanti

È importante guidare i membri del team offline in termini di come possono aumentare il loro valore per il team. Se viene chiesto loro di prendere decisioni, aumenta la loro fiducia insegnando loro quando e come includere altri membri del team. I manager devono essere pronti a superare i blocchi stradali e supportare il team quando necessario.

Affrontare i problemi in modo proattivo

Scrum non è progettato per dare un nuovo look alla tua azienda. Se hai lasciato che i problemi non venissero affrontati, molto probabilmente scoprirai che questi problemi emergono nel processo di sviluppo del prodotto. Gli Scrum Master possono introdurre framework progettati per creare un modo positivo per i membri del team di strutturare il loro feedback per ridurre la sensazione di conflitto.

Uno di questi esempi è il quadro "Vorrei, mi chiedo, e se". Durante le discussioni di gruppo o le retrospettive, un membro del team può fornire un feedback aprendo la propria dichiarazione con una di queste tre frasi. Ad esempio, potrebbero dire: "Vorrei che le riunioni di stand-up potessero concentrarsi maggiormente sui blocchi stradali di cui potrei dover essere a conoscenza quel giorno". Puoi anche usare il tuo apriscatole come "Mi piace...".

Un'altra soluzione di feedback strutturato che può essere utile durante le riunioni è il metodo Triage di Holocracy, creato da Brian Robertson e utilizzato da aziende come Zappos. Ad esempio, i partecipanti costruiscono un'agenda di "tensioni" da discutere. Ogni partecipante descrive il proprio problema dicendo "Ho una tensione" e quindi elenca le persone e le risorse di cui hanno bisogno per risolverlo. Incoraggiando i partecipanti ad affrontare direttamente le questioni come "tensioni", l'Olocrazia consente ai partecipanti di comunicare liberamente senza creare un'atmosfera di conflitto.

Utilizzare le retrospettive per risolvere i problemi e ripetere il processo

In molte aziende, la retrospettiva non riceve la dovuta attenzione. Ciò è principalmente dovuto alla paura che molti hanno che la retrospettiva sia un luogo per vecchie discussioni, conflitti e lamentele. È fondamentale che il team sviluppi regole di base che riflettano i valori del team e la cultura aziendale.

Altrettanto importante è la necessità di evitare di investire in processi statici. Ciò che ha funzionato una volta potrebbe non funzionare per sempre. Molte squadre lottano con il turnover dei partecipanti. Questo è comune in molte aziende poiché i partecipanti vengono riassegnati ad altri team, vengono promossi o lasciano del tutto l'azienda. Con l'evolversi della composizione del team, è importante non rimanere impegnati sul fatto che tutto sia iterativo in Scrum. Si verificheranno errori, ma si spera che avranno vita breve durante l'iterazione.

Scrum funziona meglio quando sono presenti i Preside

Facendo parte della squadra, devi impegnarti per essere presente e disponibile. Lo sviluppo del prodotto è probabilmente il processo più cruciale che la tua azienda potrebbe intraprendere per migliorare la propria crescita a lungo termine. Pertanto, è importante che il processo Scrum, in quanto percorso principale per lo sviluppo di nuovi prodotti, riceva l'attenzione che merita. In molti ambienti, il team di sviluppatori lavora spesso indipendentemente dalle decisioni e dalle discussioni che guidano gli obiettivi dell'azienda. Scrum è diverso. Scrum è il luogo in cui decisioni, direzione e sviluppo si uniscono in un unico processo. In un processo è troppo importante inviare delegati o escludere i membri del team dagli incontri che si svolgono all'interno della metodologia Scrum.

Riepilogo: puoi correggere un processo Scrum interrotto

A causa della sua natura iterativa, Scrum aiuta a salvaguardare il business dall'andare troppo lontano e impegnarsi in ciò che potrebbe finire per essere una cattiva idea o un processo mal implementato. L'adesione a questo principio può aiutare a rilassarsi dagli errori passati e migliorare in modo iterativo il processo Scrum.

È importante concentrarsi sulle persone e sulla squadra che hai. I membri del team cambiano. Tutti i progetti sono diversi. La stretta aderenza a un processo non sempre produce i migliori risultati. Ciò che investi nei membri del tuo team al di fuori del processo è importante tanto quanto il modo in cui ti comporti all'interno del processo.

Scrum può essere flessibile. Se qualcosa non funziona, considera di incorporare elementi di altri framework sia all'interno di Agile che all'esterno. Identificare e adottare stili strutturati di comunicazione che discussioni conflittuali.

Scrum è vantaggioso per il ROI a lungo termine, consentendo ai team di creare prodotti completi in risposta alle mutevoli esigenze dei clienti. Scrum è probabilmente la metodologia migliore per impedirti di impegnarti eccessivamente in cattive idee dando allo stesso tempo un po' di spazio per sviluppare ulteriormente le grandi idee.