Output, Outcome e Impatto in Scrum

Output, Outcome e Impatto in Scrum

Output, Outcome e Impatto in Scrum sono termini fondamentali per comprendere il valore reale che un prodotto può portare ad un’azienda. Sebbene spesso utilizzati in modo intercambiabile, ciascuno di questi termini ha un significato specifico e distintivo. In questo articolo, esploreremo le differenze chiave tra output, outcome e impatto, e come questi concetti si collegano alla gestione del prodotto, con particolare attenzione a come Scrum, attraverso Sprint e Product Backlog, aiuta a fare queste distinzioni.

Guarda il video

Ascolta il podcast

output outcomes impatto scrum

Output: Il Prodotto del Lavoro

L’output è il risultato tangibile e immediato del lavoro svolto. Rappresenta ciò che viene prodotto, creato o consegnato dai Developers. Nel contesto di Scrum, gli output sono spesso definiti come incrementi del prodotto consegnati, al più tardi, al termine di ogni Sprint. Gli output possono includere:

  • Nuove funzionalità o aggiornamenti di un prodotto.
  • Documentazione o guide per l’utente.
  • Codice scritto per un’applicazione software.
  • Report o analisi di mercato.

Gli output sono spesso facilmente misurabili e quantificabili. Ad esempio, il numero di nuove funzionalità rilasciate in un trimestre o il numero di bug risolti. Tuttavia, gli output da soli non forniscono una misura del successo o del valore per l’azienda. Sono semplicemente il risultato delle attività svolte dallo Scrum Team durante uno Sprint.

Output Outcome Impatto in Scrum
Output Outcome Impatto in Scrum

Outcome: Il Risultato del Cambiamento

Gli outcome rappresentano i cambiamenti o i benefici derivanti dall’uso degli output. In altre parole, sono i risultati desiderati che si ottengono quando gli utenti interagiscono con il prodotto. Nel contesto di Scrum, gli outcome sono spesso supposizioni del Product Owner, raggiungibili attraverso una strategia visibile nel Product Backlog, che elenca tutte le funzionalità, i miglioramenti e le correzioni che il team intende sviluppare. Gli outcome possono essere:

  • Aumento della soddisfazione dei clienti.
  • Maggiore engagement degli utenti con il prodotto.
  • Riduzione del tempo necessario per completare un compito grazie a una nuova funzionalità.
  • Miglioramento della retention degli utenti.

Gli outcome sono più difficili da misurare rispetto agli output, ma sono cruciali per comprendere il valore reale che un prodotto porta ai suoi utenti. Misurare gli outcome richiede spesso feedback qualitativi e quantitativi dagli utenti, analisi di metriche di utilizzo e altri strumenti di valutazione dell’impatto. Per poter apprezzare un outcome, spesso, è necessario rilasciare il prodotto in produzione rapidamente per alimentare il feedback loop.

Impatto: Il Valore Complessivo per l’Azienda

L’impatto è la misura in cui gli outcome contribuiscono agli obiettivi strategici dell’azienda. Rappresenta il valore complessivo che un prodotto apporta all’organizzazione. Gli impatti possono includere:

  • Aumento dei ricavi o della redditività.
  • Espansione della quota di mercato.
  • Miglioramento della reputazione dell’azienda.
  • Incremento della fedeltà dei clienti.

L’impatto è il livello più alto di valore che si può misurare ed è spesso collegato agli obiettivi a lungo termine dell’azienda. Per valutare l’impatto, è necessario collegare gli outcome agli obiettivi strategici dell’azienda e misurare come e quanto questi risultati influenzano il business nel suo complesso. In Scrum, il Product Owner ha un ruolo strategico per l’azienda, in quanto è la persona che collega il lavoro quotidiano alla strategia aziendale.

Collegare Output, Outcome e Impatto nel Product Management

Per un Product Owner, è essenziale comprendere come gli output del team possono tradursi in outcome desiderati e, infine, in impatti significativi per l’azienda. Utilizzando Scrum e lavorando con frequenze di ispezione e adattamento regolari (Sprint) che realizzano la strategia visibile nel Product Backlog, è possibile collegare questi concetti in modo efficace. Ecco alcuni passaggi chiave:

  1. Definire chiaramente gli output: in Scrum ciò significa assicurarsi che gli output siano ben definiti nel Product Backlog e rendano trasparente la strategia del Product Owner per raggiungere il Product Goal.
  2. Stabilire gli outcome desiderati: Identificare quali cambiamenti o benefici si aspettano come risultato dell’uso degli output. Il Product Backlog dovrebbe riflettere queste aspettative nel Product Goal.
  3. Misurare e monitorare gli outcome: Utilizzare metriche e feedback per valutare se gli outcome sono stati raggiunti. Le Sprint Review sono momenti chiave per questa valutazione, ma anche Evidence Based Management.
  4. Valutare l’impatto sull’azienda: Collegare gli outcome agli obiettivi strategici e misurare l’impatto complessivo sul business. Questo può essere fatto attraverso l’analisi delle metriche di business post-rilascio.

Esempi che illustrano le differenze tra output, outcome e impatto nel contesto di un prodotto digitale, come un’applicazione mobile.

Output

Esempio: Una nuova funzionalità di messaggistica istantanea aggiunta all’applicazione mobile.

  • Descrizione: lo Scrum Team ha lavorato per due Sprint per implementare una funzionalità che permette agli utenti di inviare messaggi istantanei tra di loro.
  • Dettagli: questa funzionalità include l’interfaccia utente per la chat, l’integrazione con il server di messaggistica

Outcome (valore creato per gli utenti)

Esempio: (ipotesi) aumento dell’engagement degli utenti grazie alla nuova funzionalità di messaggistica istantanea.

  • Descrizione: dopo il rilascio della nuova funzionalità, si osserva che gli utenti trascorrono più tempo nell’applicazione e interagiscono di più tra di loro.
  • Dettagli: Le metriche mostrano che il numero di sessioni per utente è aumentato del 30% e il numero di messaggi inviati quotidianamente è salito del 50%.

Impatto (per l’azienda, spesso in termini economici)

Esempio: crescita del numero di abbonamenti premium grazie all’aumento dell’engagement.

  • Descrizione: l’aumento dell’engagement ha portato ad un incremento nel numero di utenti che passano alla versione premium dell’applicazione, che offre funzionalità aggiuntive e vantaggi esclusivi.
  • Dettagli: il numero di abbonamenti premium è cresciuto del 20% nei tre mesi successivi al rilascio della nuova funzionalità, portando ad un incremento del 15% nei ricavi trimestrali dell’azienda.

Riassunto degli esempi

  • Output: Implementazione della funzionalità di messaggistica istantanea.
  • Outcome: Maggior engagement degli utenti (aumento del numero di sessioni e messaggi inviati).
  • Impatto: Crescita del numero di abbonamenti premium e incremento dei ricavi aziendali.

Questi esempi mostrano chiaramente come gli output (ciò che viene prodotto) possano portare ad outcome significativi (cambiamenti nel comportamento degli utenti) e, infine, avere un impatto positivo sul business dell’azienda (aumento dei ricavi e degli abbonamenti premium).

Output, Outcome e Impatto in Scrum – Conclusione

Capire la differenza tra output, outcome e impatto così come sono articolati fra di loro è fondamentale per il successo nel product management. Gli output sono i prodotti del lavoro, gli outcome sono i risultati ottenuti dall’uso di questi output, e l’impatto è il valore complessivo che questi risultati portano all’azienda. Utilizzando Scrum, con Sprint e Product Backlog, il Product Owner può aumentare la probabilità che il lavoro svolto quotidianamente contribuisca efficacemente al successo strategico dell’organizzazione. Un approccio olistico che tenga conto di tutti e tre questi aspetti permette agli Scrum Team di creare prodotti non solo efficaci, ma anche di grande valore strategico per l’organizzazione.

Per approfondire l’argomento

5 Livelli di feedback in Scrum

5 livelli di feedback in Scrum

5 Livelli di feedback in Scrum

5 livelli di feedback in Scrum aiuta a capire uno dei problemi principali che osservo nei team che praticano Scrum, cioè la qualità del feedback ricevuto sul lavoro fatto durante lo Sprint. In questo articolo ti invito ad esplorare 5 livelli di feedback in Scrum, dal meno efficace al più efficace per uno sviluppo empirico di prodotto.

Nel seguito dell’articolo parlo spesso di Sprint Review, segui il link se non sai cos’è o vuoi rinfrescarti la memoria!

1 – Persone disinformate

Feedback in Scrum
Clicca l’immagine per ascoltare il podcast

Al livello meno efficace di feedback posiziono i team che invitano in Sprint Review delle persone interne all’azienda. Queste persone, quando si presentano all’evento, non sanno cos’è Scrum e perché partecipano (sigh). Ma visto che in azienda non è visto di buon occhio rifiutare una riunione, vengono con il computer e lavorano invece di partecipare.

lo Scrum Team, in generale, non riesce a coinvolgere i presenti e non capisce perché la magnifica presentazione power point non sta avendo successo.

La conclusione è tanta frustrazione per il team che non ottiene feedback di qualità e per i partecipanti, che continuano a non capire perché sono stati invitati ed hanno la sensazione di aver perso del tempo.

Rimaniamo su una nota positiva: spesso questo capita ai team che sono agli inizi con Scrum. Quindi anche il livello 1 di feedback è un buon inizio, da migliorare rapidamente!

2 – Stakeholders Feedback

Il team ha capito che i partecipanti alla Sprint Review devono sapere quale contributo possono dare. I partecipanti rimangono esclusivamente dipendenti dell’azienda, in generale manager ai quali il team deve rendere dei conti.

Sprint Review
5 livelli di feedback in Scrum – Sprint Review Checklist

Un miglioramento che puoi sperimentare, è quello di introdurre la Sprint Review spiegando ai partecipanti perché sono stati invitati. Idealmente iniziando dall’invito calendario, fino ad occupare i primi dieci minuti dell’evento, l’aspetto pedagogico è importante.

Le aspettative ed i vincoli per partecipare devono essere chiari. Le persone presenti sono invitate a prestare massima attenzione, oppure autorizzate a non partecipare. Se il computer non è indispensabile, specifico che non è necessario portarlo con sé 😙… se l’evento si svolge a distanza, telecamera accesa per tutti e facilitazione inclusiva dell’evento.

Se hai bisogno di migliorare la tua capacità a facilitare gli eventi Scrum (in presenza o a distanza), puoi dare un’occhiata a questo corso.

Lo Scrum Team, invece di preparare una presentazione Power Point, fornisce a tutti i partecipanti l’ultima versione del prodotto, che sarà utilizzata dai partecipanti per fornire feedback.

Fra lo step 1 e 2 possono passare diversi Sprint, è importante fare questo miglioramento il più rapidamente possibile.

3 – User Feedback

Per Scrum uno Stakeholder è qualsiasi persona esterna alla Scrum Team. L’utilizzatore del prodotto è un tipo di Stakeholder particolare. La persona che ci interessa di più dal punto di vista del feedback. Dobbiamo capire rapidamente se il lavoro fatto ha creato valore come l’avevamo ipotizzato.

Questo è uno step importante e molto spesso mancante in uno Scrum Team. Non avere utilizzatori in Sprint Review limita in maniera considerevole lo sviluppo empirico del prodotto e, di conseguenza, l’efficacia di Scrum.

Sento una vocina alzarsi e dire: “si ma, Fabio, per noi è impossibile avere degli utilizzatori in Sprint Review”… ok allora lo Scrum Team deve chiedersi come poter ottenere un feedback di qualità in modo asincrono.

Di conseguenza, dovete trovare il modo di arrivare in Sprint Review con gli utilizzatori del vostro prodotto, oppure con i dati generati durante lo Sprint che parlano per i vostri utilizzatori.

Il feedback utilizzatore è alla base dello sviluppo empirico dei prodotti e quindi di Scrum. Lo ripeto, perché è importante.

4 – Osservazione dell’utilizzatore

Ma si può fare meglio… osservare l’utilizzatore, capire come usa il prodotto. O come vorrebbe utilizzarlo.

Non c’è niente di peggio per un utilizzatore di doversi adattare ad un prodotto mal pensato, che non tiene conto delle necessità dell’utilizzatore.

Un’altra esperienza: nello sviluppo di uno smartphone per agenti pubblici (polizia, pompieri, ecc.), abbiamo fatto tutti i test dell’altoparlante in laboratorio. Il volume dell’altoparlante era alto, il team e gli stakeholders in Sprint Review erano soddisfatti.

Alla prima utilizzazione in un incrocio pieno di traffico, con il volume al massimo, si faceva fatica a capire cosa dicesse il nostro interlocutore!

Dall’esperienza raccontata in precedenza, con il team, abbiamo capito quanto importante fosse avere feedback, ma non solo, essere anche in condizioni reali ed osservare l’utilizzatore per poter confermare la creazione di valore!

5 – La prova del mercato

Il livello più avanzato di feedback, lo si ottiene grazie ai dati relativi all’utilizzo del prodotto ed alle sue funzionalità, alle vendite e relativi guadagni generati.

La prova del mercato è assolutamente indispensabile nello sviluppo empirico di un prodotto. Purtroppo, in certe aziende nelle quali c’è la cultura del prodotto finito (!!!), ho spesso assistito a battaglie interne per impedire la vendita di prodotti considerati non finiti. Senza che nessuno sapesse darmi la definizione di prodotto finito (sigh).

In questo caso l’azienda si espone agli stessi rischi di uno sviluppo waterfall: si usa Scrum per sviluppare tante ipotesi, mai confermate dal mercato e si rilascia in produzione dopo un anno o due di sviluppo. È chiaro che questo modo di fare elimina i benefici di Scrum e dello sviluppo empirico di un prodotto.

Empirismo e Scrum
Clicca l’immagine per ascoltare il podcast

Per esempio, nemmeno noi da Collective Genius, nelle Sprint Review del podcast Scrum Italia, abbiamo gli ascoltatori presenti. Però abbiamo i dati degli ascolti passati, facciamo esperimenti per capire in quali episodi abbiamo più ascolti. Abbiamo più ascolti sulle interviste? Oppure quando leggo gli articoli del blog? Quale durata è migliore? Ecc.

Non aspettiamo di aver registrato 1000 episodi per poi cominciare a pubblicarli, ne abbiamo 2/3 in stock (quando va bene) e per il resto ci affidiamo agli ascolti per decidere cosa fare.

Quindi, per ricollegarmi al punto precedente, anche questo è un caso di osservazione che può avvenire attraverso dati generati dal prodotto, non necessariamente da interviste dell’utilizzatore o una sua partecipazione in Sprint Review.

Ma bisogna pensarci, capirlo ed implementare le sonde corrette nel prodotto.

5 livelli di feedback in Scrum – Conclusione

In conclusione, ti suggerisco di riflettere (magari con il team nella prossima Retro) a quale livello di feedback siete in questo momento e capire come potete passare dal livello attuale al livello successivo. Specialmente se sei Scrum Master, questo articolo dovrebbe permetterti di aiutare il team ad aumentare il livello di qualità del feedback ottenuto!

Fammi sapere, mi farà piacere… Scrum On!

5 livelli di feedback in Scrum – Risorse utili relative all’argomento

Ma Scrum Funziona Veramente?

Ma Scrum funziona veramente?

Ma Scrum funziona veramente? Questa domanda un pò provocatoria è venuta fuori come tema in una delle puntate del podcast Scrum 🇮🇹.

Scrum funziona veramente?
Clicca l’immagine sopra per ascoltare il podcast

Ho avuto il piacere di sedermi con alcuni dei più brillanti Scrum Master professionisti per discutere di un argomento che ci sta a cuore: l’agilità e, in particolare, Scrum.

Grazie di ❤️ a Silvia, Emanuele, Alessandro e Mike per essersi prestati all’esercizio!

Ma Scrum funziona veramente?
Podcast Scrum Italia – Ep. 40 – Ma Scrum funziona veramente?

Ma Scrum funziona veramente? – Ecco i punti forti della nostra chiacchierata.

🚀 Cultura e Mindset: Alessandro ha sollevato un punto cruciale sulla necessità di un cambiamento culturale nelle organizzazioni. Lontani dai Gantt e dai rigidi controlli, è tempo di abbracciare l’autonomia e l’empirismo.

🔍 Empirismo vs Predizione: Io stesso ho sottolineato come molti affermino di usare Scrum senza abbracciarne la natura empirica. Ricordate, prevedere il futuro in un mondo complesso è un’illusione; ciò che conta è rimuovere gli ostacoli e cambiare mentalità.

👥 Autonomia del Team: Michael ha condiviso una storia di successo su come l’empowerment di un giovane team ha portato alla consegna anticipata di un prodotto funzionante. Piccoli cambiamenti possono fare la differenza!

📈 Disciplina nell’applicazione: Alessandro ha ribadito che l’applicazione rigorosa dei concetti può portare al successo, coinvolgendo i clienti e dimostrando l’efficacia del nostro approccio.

🌱 Cultura di squadra: Silvia ha parlato dell’importanza di coltivare una cultura di comprensione e di possesso del metodo Scrum a livello di team, mentre Emanuele ha evidenziato come le retrospettive genuine abbiano rafforzato il senso di squadra.

Questi sono solo alcuni degli spunti che abbiamo esplorato nel nostro ultimo episodio. Se sei curioso.a di scoprire come queste idee possano essere applicate e di ascoltare le storie personali dei miei ospiti, non puoi perderti questo episodio del podcast.

Sintonizzati per un viaggio nel cuore dell’agilità e scopri come piccole modifiche possano portare a grandi risultati. Non vedo l’ora di condividere con voi queste conversazioni illuminanti!

Un abbraccio e fino al prossimo ascolto,
Fabio 🎙️

P.S. Ricordate, l’agilità è un viaggio, non una destinazione. Siate coraggiosi, sperimentate e adattatevi. Il vostro team vi ringrazierà!

comprensione teorica e pratica di Scrum, come colmare il divario?

In questo articolo, Stefano Milanesi e Fabio Panzavolta, attraverso la loro esperienza da Scrum Master, offrono spunti di riflessione su come colmare il divario tra comprensione teorica e pratica di Scrum e qualche esperimento da provare al lavoro!

Introduzione

Discutiamo un tema che è abbastanza sentito, che abbiamo vissuto personalmente e che ci sta a cuore. Cioè quello di uno Scrum Master che si sente frustrato perché vede che Scrum non sta funzionando all’interno della propria azienda, si rende conto che non sta facendo le cose nella maniera corretta ed ha la volontà di migliorare, di capire, di trovare una soluzione sia all’interno del team che nell’organizzazione.

Questo articolo è la trascrizione adattata del video qui sopra

Comprensione teoricA e pratica di Scrum – Come capire quando Scrum è Scrum?

Come fa uno Scrum Master a capire se quello che si sta applicando in azienda è Scrum Professionale, oppure Scrum meccanico (applicato come una metodologia)?

Prima di tutto partire dalle basi di Scrum, cominciando a capire se quello che si è praticato fino ad ora è Scrum. Questo lo si riesce a capire con una buona conoscenza di base, teorica, da fonti affidabili, corrette. Un po’ tutti abbiamo fatto il fai da te, sicuramente avere delle fonti attendibili, un supporto attendibile, è importante.

Avere un mentore con cui parlare, confrontarsi, che abbia già avuto un’esperienza reale è un altro ottimo passo per maturare una certa coscienza.

Come far capire Scrum all’azienda?

Il passo successivo consiste a far capire Scrum Professionale agli altri, colleghi e azienda, necessario per abbattere certi ostacoli organizzativi e burocratici per praticare Scrum correttamente.

Inizialmente è utile e naturale aggrapparsi ai principi fondamentali di Scrum, non perché siano scritti nella Scrum Guide, ma perché Scrum è uno strumento per rivelare quello che non funziona in azienda. Se si vuole diventare più agili, quindi, ci vuole coraggio.

Prima di tutto bisogna capire che cosa è Scrum e che tipo di problemi aiuta a risolvere, perché se hai un martello e cerchi di usarlo per tagliarti le unghie arriverai alla conclusione che il martello non funziona. Quindi il primo passo è capire che strumento è Scrum e come lo puoi usare.

Comprensione teoricA e pratica di Scrum – Non concedere distorsioni a Scrum

Inoltre è importante non concedere troppe distorsioni a Scrum, perché altrimenti non funziona più. Non eliminare elementi da Scrum, al limite aggiungerne. In questo modo si creeranno dei piccoli conflitti, situazioni nel quale la gente ti chiederà ma perché ti comporti così? Perché ci dici di fare così, eccetera eccetera.

Si creano opportunità per aiutare i colleghi e l’azienda a capire come ci si può migliorare.

La nostra esperienza coincide nel fatto che, in certi contesti, bisogna passare attraverso dei momenti, a volte, difficili. È per questo che non bisogna rimanere soli, è molto importante non rimanere soli.

E incassare il supporto del team e dell’organizzazione.

Scrum è fattibile veramente?

Il messaggio che passiamo in formazione è positivo, è difficile, bisogna avere personalità per stimolare il cambiamento. Si può cominciare formulando domande, perché far domande non costa niente, non ci si mette in pericolo e si stimola la riflessione negli altri.

Un esempio di domanda potrebbe essere : “pensate veramente che siamo agili al 100%?” Sì, no, ma allora cosa possiamo fare per diventarlo? Cominciare a far domande è un buon inizio per cambiare le cose.

Comprensione teoricA e pratica di Scrum – Applicazione meccanica di Scrum, corretto?

Un’altra esperienza vissuta con diversi team è stata quella di trovare persone che erano fin troppo ligie nell’applicazione di Scrum, nel senso che lo applicavano in maniera meccanica. Rispetto stretto di sequenza e durata degli eventi, responsabilità che si trasformano in belle etichette piazzate su ogni persona all’interno del team. Peccato che poi si perde la ragione per la quale si sta facendo tutto questo e ritornare alle basi per capire il perché lo sto facendo è sicuramente il punto chiave.

Come dicevamo prima, fare domande a chi ci sta attorno, ma fare domande anche a Scrum, che può indicarci la direzione da prendere in qualsiasi situazione.

Perché sto facendo questa cosa? Perché questa cosa non funziona? Molto spesso la risposta la troviamo consultando la Scrum Guide, a volte lo troviamo con l’esperienza, quindi provando, facendo esperimenti e ottenendo feedback e risposte che poi ci guidano in qualche modo su quello che è il prosieguo della nostra esperienza.

Ep. 3 - Scrum Guide Scopo della Guida Scrum
Clicca l’immagine per ascoltare il podcast

L’applicazione stessa del framework è decisamente qualcosa di complesso. Un’applicazione meccanica non è corretta e non aiuta se non si capisce il perché si fanno le cose!

Acquisire sicurezza come Scrum Master

Acquisire sicurezza come Scrum Master è una cosa fondamentale per capire come comportarsi. Se io sono sicuro di quello che posso dire (o fare) per stimolare l’uso di Scrum poi posso anche esprimermi in un certo modo e sperimentare, ottenere feedback da questi esperimenti. Gli esperimenti servono per rivelare ciò che non funziona per correggerlo e progredire.

Questo è fondamentale.

Comprensione teorica e pratica di Scrum – Come si applica Scrum?

A volte si cerca di fare tutto subito, per tante ragioni. Procedere in questo modo non aiuta a capire realmente i feedback, perché vengono mescolati. Ho fatto quattro, cinque esperimenti tutti in una volta, per accelerare l’adozione, ma le persone non mi capiscono.

Il segreto (!!) è avere pazienza, la pazienza del giusto o di chi comunque conosce ed applica. Una certa logica iterativa ed incrementale, come ci insegna Scrum.

Rendere trasparente un backlog di impedimenti che impediscono Scrum Professionale, renderlo visibile a chiunque è un primo passo che si può sperimentare.

Molto spesso l’esperienza ci ha mostrato che primi ostacoli sono i più facili da eliminare, poi, man mano che si va avanti i successivi sono sempre più difficili. Capire come come si può progredire è effettivamente l’approccio più proficuo.

Errori tipici nell’applicazione di Scrum

Un errore tipico, osservato sul campo, di chi applica Scrum in modo meccanico è quella delle scorciatoie, per comodità o facilità.

Fare un buon coaching come Scrum Master, rispetto all’organizzazione ed al team, significa fare leva sui valori di Scrum, che ci aiutano ad ottenere tante risposte.

Trovare un “accordo” per lavorare con fiducia, che emerge grazie alla comprensione dei valori di Scrum, facilita tantissimo buona parte del processo di adozione di Scrum.

Evitare l’errore di “dimenticare” i valori Scrum è sicuramente necessario, in qualsiasi contesto.

I cinque valori fondamentali di Scrum illustrati
Clicca l’immagine per ascoltare il podcast

Spesso usiamo il parallelo con un team sportivo. Se si vuole progredire bisogna farlo in un ambiente di lavoro in cui ci si sente al sicuro. Gli anglofoni parlano di Psychological Safety.

Quando arriviamo in aziende nuove, ci comportiamo in accordo con i valori Scrum e, per questo, siamo percepiti come “diversi”, un pò strani 😊. Un Professional Scrum Master usa i valori Scrum costantemente, questi guidano il suo comportamento in modo tale che sia adatto alla risoluzione di problemi complessi. Leggi il nostro articolo Leading with Values.

È importante essere i primi ad essere strani, stimolare la curiosità per rispondere alle domande e mettere in moto il cambiamento.

Un altro errore classico è quello di fermarsi allo Scrum Team. Invece far capire all’organizzazione, in primis, che non siamo un corpo estraneo ma che lo Scrum Master esiste per una ragione ben precisa (che è quello di generare valore e farlo nella maniera migliore possibile) è importantissimo.

Qualcosa che è basilare per lavorare bene è essere felici. Persone felici, soddisfatte e motivate a raggiungere obiettivi saranno più produttive. Questa è anche la nostra funzione di Scrum Master. Perché questo accada, bisogna che effettivamente le cose siano molto chiare per tutti.

Chiarire, tramite un accordo generale (aziendale) su quelli che sono gli obiettivi del “come facciamo le cose” dovrebbe essere esplicitato, non può essere qualcosa che serpeggia. È molto importante che l’uso di Scrum per lo sviluppo di un particolare prodotto sia dichiarato, perché ci dà la legittimità per praticare correttamente in seno all’azienda.

A volte questa legittimità bisogna prendersela, senza aspettare di essere incoronati!

Questo fa parte della sicurezza che si è acquisita come Scrum Master. Se siete sicuri di voi, allora spingerete di più per ottenere quello che sapete sia giusto fare!

È un po come un allenatore di calcio che sa che se ci si allena in un certo modo con questo tipo di squadra allora puoi vincere. Se hai questa sicurezza poi la trasmetti anche agli altri.

Tutto quello che avviene all’interno di un’organizzazione dovrebbe essere umano centrico quindi, se attendiamo sempre difficilmente riusciremo a cambiare qualcosa.

Agire dando l’esempio e iniziare a fare quello che ci stiamo proponendo di fare perché abbiamo deciso di farlo è probabilmente la mossa migliore che che puoi fare per attuare in maniera effettiva un cambiamento.

Lo Scrum Master aiuta l’azienda, non solo il team.

È importante sottolineare che uno Scrum Master Professionale non aiuta solo lo Scrum Team. Necessariamente deve aiutare anche il resto dell’azienda a capire Scrum.

Direi che aiuta anche i clienti, fornitori, i manager e tutte le persone interessate a capire meglio un approccio diverso alla risoluzione di problemi complessi.

È abbastanza normale, all’inizio, concentrarsi sul team però bisogna anche avere questa forza di volontà di andare a eliminare gli impedimenti che rapidamente emergono al di fuori del team e che bisogna trattare in qualche modo.

Come fare quando ci sono più Scrum Team?

A volte, ci si trova a dover aiutare più team. L’esperienza ci ha mostrato Scrum Master molto scollati fra di loro, quindi poca anche unità di intenti nel nell’andare a fare coaching a livello organizzativo. Quindi, sicuramente, se la tua organizzazione ha più Scrum Team e siete più Scrum Master, parlarsi e cercare di fare emergere successi e difficoltà comuni e sperimentare soluzioni insieme può essere di grande valore.

Come dimostrare che stiamo facendo un buon lavoro come Scrum Master?

Dimostrare che uno Scrum Master ha valore per un team e un’azienda è possibile. Anche se l’apporto è spesso indiretto e non molto visibile.

I fatti devono parlare per noi.

Una cosa molto semplice, evidente a tutti, è quella di dimostrare che ad ogni Sprint lo Scrum Team realizza incrementi “Done”, regolarmente. Secondo Ken Schwaber questo è il miglior indicatore possibile.

Altro indicatore è un team felice, che si diverte al lavoro.

Un buon modo per colmare quel gap fra la teoria e la pratica è quindi quello di misurare quello che stiamo producendo.

Senza voler andare nel dettaglio, ci sono metriche specifiche, grazie ad Evidence Based Management, che possono dare indicazioni precise su quale sia il valore del nostro prodotto.

Quindi fare Scrum bene vuol dire anche innescare un circolo virtuoso che migliora il prodotto e migliora anche noi stessi, come persone, come individui e come team.

Questo approccio empirico non solo sul prodotto ma anche su noi stessi ci permette di adattarci in continuazione a qualsiasi situazione.

Non c’è niente da fare, bisogna lavorare per capire come usare questo strumento che si chiama Scrum. Un pò come quando si vede un martello per la prima volta. A quelli che dicono che il martello non funziona, bisogna chiedere per quale obiettivo lo vogliono usare. Se lo usi per tagliare le unghie, ovviamente il risultato sarà deludente… forse anche un po’ doloroso 😊.

Comprensione teoricA e pratica di Scrum – Conclusioni

Per praticare Scrum Professionale è necessario colmare il divario tra comprensione teorica e pratica di Scrum stesso. E un lavoro continuo, che non finisce mai, in quanto anche Scrum evolve nel tempo, i problemi da risolvere cambiano ed evolvono.

Poco importa la seniority, uno Scrum Master Professionale dovrebbe avere sempre l’umiltà di rimettersi in discussione, imparare dagli altri e, quando richiesto, condividere le proprie esperienze.

Il primo passo rimane comunque la comprensione teorica e, in seguito, un’applicazione pratica perché l’esperienza è alla base dell’apprendimento.

Immersion Training per Scrum Master

Vuoi farti accompagnare nella riduzione del gap tra conoscenza e esperienza di Scrum Professionale? Abbiamo una proposta che stiamo sperimentando. Si chiama l’Immersion training.

Questo formato permette di alternare teoria e pratica in azienda. Il contenuto è uguale a quello della formazione Professional Scrum Master, ciò che cambia è il modo di imparare.

Proponiamo 7 sessioni di mezza giornata (la prima e l’ultima in presenza, le altre a distanza), fra una sessione e l’altra forniamo degli esercizi pratici da svolgere in azienda per mettere in pratica la teoria vista durante il corso.

Nella sessione successiva, prendiamo le esperienze e forniamo feedback su come ti puoi migliorare.

Per saperne di più visita la pagina web dove trovi anche le prossime date e puoi iscriverti se lo desideri!

7 ostacoli a Scum

7 ostacoli a Scrum

Continuo ad osservare 7 ostacoli a Scrum nelle aziende che aiuto nell’evoluzione verso la Business Agility. Piccoli o grandi che siano, questi ostacoli sono spesso l’eredità di una cultura aziendale nata e sviluppatasi negli anni della rivoluzione industriale.

Sono convinto che molto dipenda anche dal sistema scolastico (pur non avendone la prova, è solo un’intuizione) che non ci prepara a lavorare insieme, a collaborare.

7 ostacoli principali all'implementazione di Scrum nelle organizzazioni
Clicca l’immagine per ascoltare l’episodio del Podcast

E questo è un grosso freno quando dobbiamo risolvere problemi complessi.

Ecco un elenco, non esaustivo ed in ordine casuale, degli ostacoli che riducono i benefici che Scrum può portare all’azienda.

Sei d’accordo? Se vuoi aggiungerne altri, lascia un commento!

7 ostacoli a Scrum – Persone, non risorse

La cultura industriale ci ha portato a considerare le persone come macchine. Bisogna essere sempre performanti, non portarsi al lavoro i problemi che abbiamo a casa, sempre sorridenti, infallibili, perfetti al primo colpo.

In questa cultura il dirigente è il primo a dover essere infallibile, avere risposta a tutto, mai nessun dubbio… un robot.

Scrum e l’Agile rimettono l’essere umano al centro, ammettendo che si possono avere giorni positivi ed altri no; che si può dubitare di una soluzione (o di se stessi) e che il dubbio è positivo perché stimola la sperimentazione.

7 ostacoli a Scrum – Gerarchia

La gerarchia è utile quando non si ha necessità di prendere decisioni velocemente. Pertanto è un fattore limitante dell’Agile, dove si vuole agire prima di tutto, osservare il risultato ottenuto per poter capire se la strada intrapresa è quella giusta o no.

Agile significa movimento, sperimentazione, collaborazione… le decisioni che si prendono riguardano rischi limitati ad un mese al massimo, durante il quale si sperimenta per capire meglio la soluzione ad un problema dato.

Dover aspettare la decisione di qualcuno per poter fare qualcosa limiterà la vostra agilità.

Hai già visto un giocatore di Rugby aspettare l’autorizzazione del coach per poter agire? Quanto competitiva sarebbe una squadra del genere?

7 ostacoli a Scrum – Ego

I cinque valori fondamentali di Scrum illustrati
Clicca l’immagine per ascoltare l’episodio del Podcast

Contribuire allo sforzo del team con umiltà e dire il più rapidamente possibile quando si ha bisogno di aiuto. Mostrarsi infallibili e senza dubbi è abbastanza sospetto in un contesto di complessità.

Se l’ambiente di lavoro è sano, ci si sente al sicuro e non giudicati, probabilmente l’ego personale potrà essere messo da parte.

Considero l’ego come uno dei 7 ostacoli a Scrum, perché limita la trasparenza (uno dei pilastri dell’empirismo) e contraddice i valori Scrum, in particolare l’apertura.

Abbiamo tutti un certo livello di ego, chi più chi meno. Ci sta. Ciò che è importante è rendersene conto e lavorare per fare in modo che non sia deleterio per il team.

Il video qui sotto mi ha personalmente aiutato a capire perché l’ego può essere un problema, soprattutto quando ci impedisce di imparare (perché pensiamo di sapere già tutto).

Growth Mindset, perché è cosi importante oggigiorno?

7 ostacoli a Scrum – Dipendenze

Le dipendenze, di qualsiasi tipo, creano vincoli rischiosi che limitano l’agilità. Per esempio, se si è dipendenti da una sola persona per un certo tipo di competenza, quando questa persona sarà in vacanza è probabile che si potrà rimanere bloccati.

Ovviamente ci sono anche le dipendenze tecniche, che possono essere problematiche.

Essere agili significa essere resilienti alle situazioni più difficili, le dipendenze limitano la resilienza. Per questa ragione parliamo di Scrum Team cross-functional, che hanno tutte le competenze necessarie a risolvere un problema complesso.

Lo Scrum Team lavora per assicurarsi che nessuno sia indispensabile, ma tutti siano necessari!

Silos

Praticamente tutte le aziende con cui ho lavorato sono organizzate in silos. La logica è quella di ottimizzare un settore di attività, come il marketing per esempio.

Questa strategia funziona bene quando un prodotto è statico, evolve lentamente nel tempo. Come un tostapane 😊. In un mercato dove le novità sono lente ad arrivare al consumatore finale.

Nel settore informatico, per esempio, essere organizzati in silos è un problema grosso. Che diventa gigantesco quando combinato con la forte gerarchia e un pizzico di ego.

Il silo impedisce la collaborazione e, di conseguenza la trasparenza, con un impatto negativo sulla Business Agility.

Per questa ragione uno Scrum Team è auto-gestito, mette tutti sullo stesso livello e si focalizza su un obiettivo comune da raggiungere.

7 ostacoli a Scrum – Politica interna

L’organizzazione in silos obbliga a fare politica, alleanze, per portare acqua al proprio mulino (fare in modo che la priorità del Team diventi priorità di tutti).

Porta il focus delle persone su problemi interni, su decisioni che sono (forse) utili per fare carriera, ottenere un bonus… ma che distraggono dalla ragione per la quale lavoriamo, ossia creare qualcosa di utile per qualcuno (valore).

La politica interna, conseguenza abbastanza normale dell’organizzazione in silos, porta a perdere di vista l’obiettivo principale dell’azienda: creare valore per gli utilizzatori dei propri prodotti.

7 ostacoli a Scrum – Burocrazia

La burocrazia, un’altro dei 7 ostacoli a Scrum, utile per garantire il controllo del lavoro ripetitivo (contabilità, rischi operativi, ecc.), è una catastrofe per l’agilità dell’azienda. Obbligare uno Scrum Team a sottostare alle stesse regole burocratiche del servizio contabilità (per esempio) è un grave errore.

In contesti complessi, la burocrazia dovrebbe essere ridotta al minimo. Favorire linee guida e regole semplici ed incrementali basate sull’esperienza è una migliore soluzione, più agile.

Conclusioni

Mi sono divertito a fare come nell’agile manifesto, mettendo in contrapposizione ciò che favorisce un contesto agile da ciò che l’ostacola, ecco il risultato.

Favorevole all’agilitàSfavorevole all’agilità
PersonePiuttosto cheRisorse
Auto-GestionePiuttosto cheGerarchia
UmiltàPiuttosto cheEgo Personale
AutonomiaPiuttosto cheDipendenze
Cross-FunctionalPiuttosto cheSilos
ValorePiuttosto chePolitica interna
Linee GuidaPiuttosto cheBurocrazia
A sinistra riconosco i fattori stimolanti per l’agilità aziendale, pur riconoscendo che gli elementi a destra possono essere necessari in contesti non complessi.

Ti ritrovi nei 7 ostacoli a Scrum che ho descritto? Li osservi nella tua azienda? Nulla di grave, è piuttosto normale perché questo permette di far funzionare correttamente il lavoro quotidiano. In ogni caso ha permesso di farla funzionare fino ad oggi 😊.

Tuttavia, bisogna prendere coscienza che la perdita di competitività dovuta all’incapacità di reagire rapidamente alle domande del mercato è un problema che stanno affrontando diverse realtà.

Uno Scrum Master Professionale ha la responsabilità di rivelare e far capire che ciò che funziona bene in un contesto ripetitivo e prevedibile non è in realtà molto utile per risolvere problemi complessi.

Allora non perdere tempo, costruisci argomenti solidi per far capire ed utilzzare Scrum correttamente. Questo permetterà di limitare i rischi e aumentare la Business Agility aziendale. Scrum On! 💪

Per ricevere i nuovi articoli in anteprima, abbonati. Pubblichiamo più o meno un articolo al mese. Puoi annullare l’iscrizione in qualsiasi momento.

Scrum performance e risultato

Scrum: performance e risultato

Scrum: performance e risultato è una riflessione su quanto sia necessario distinguere la performance e la “casualità” del risultato.

Recentemente, durante una formazione Applying Professional Scrum, ho condiviso la differenza che esiste fra performance e risultato con un esempio sportivo.

Scrum performance e risultato
Clicca l’immagine per ascoltare il podcast

La performance, se pensiamo alla corsa a piedi, corrisponde al passo che riusciamo a riprodurre regolarmente, per esempio 6min/km di media.

Questo dato ci permette di dedurre che una semi-maratona è fattibile in poco più di 2 ore.

Il risultato dipende da tanti fattori, alcuni dei quali al di fuori del nostro controllo. Sono i famosi “unknown/unknown”… o semplicemente la sfiga 🙂

Il giorno della semi-maratona ci si sveglia con il mal di pancia, la corsa probabilmente non andrà come previsto (esperienza personale 😊).

Il risultato è diverso dalle performance passate. Questo è imprevedibile e fa parte dell’incertezza che non possiamo controllare. Ma che si deve accettare.

In un contesto complesso, il risultato non si può comprare. Se cercano di vendervelo, scappate!

Fabio

Performance

Scrum: performance e risultato
Scrum: performance e risultato

Definizione del dizionario: in senso generico, realizzazione concreta di un’attività, di un comportamento, di una situazione determinata (ref Treccani)

La performance è qualcosa che richiede allenamento, perseveranza, miglioramento continuo. Un team, per poter diventare performante, ha bisogno di tempo, di sicurezza psicologica, di commettere errori per imparare. Nel mondo professionale in cui viviamo, si esige la performance dal primo giorno. Ovviamente è impossibile. Ancora peggio, non si fa nulla per aumentare la performance del team, si guarda al risultato individuale.

È l’accountability dello Scrum Master quella di aiutare il team a capire e usare Scrum correttamente per ottenere un team performante. A seconda del contesto lavorativo e delle persone nel team per ottenere una performance accettabile ci vorrà più o meno tempo.

Qui sotto trovi l’episodio del nostro podcast Scrum 🇮🇹 nel quale parlo dello Scrum Master.

Scrum Master servant leader
Clicca l’immagine per ascoltare il podcast

Scrum: performance e risultato – come si riconosce uno Scrum Team performante?

Ci sono tre fattori che, secondo me, rivelano un team performante.

  1. Uno Scrum Team performante è capace di rilasciare uno o più Increment Done nel corso di uno Sprint, ad ogni Sprint. Esattamente come per la corsa a piedi, inizialmente un Increment Done sarà composto da pochi elementi del Product Backlog, con il tempo, il team sarà capace di realizzarne sempre di più, a qualità costante o migliore.
  2. Un’altro segno distintivo che la performance esiste, è un team felice e motivato a fare meglio. Un team che trova autonomamente e rapidamente correzioni agli ostacoli che incontra.
  3. Altra caratteristica di un team performante: nessuno chiede il permesso di fare qualcosa, tutti sanno qual’è l’obiettivo e il lavoro da fare per tentare di raggiungerlo (trasparenza).

Per ottenere un team di questo tipo, l’apporto di uno Scrum Master è fondamentale. È un lavoro che richiede tempo, competenza, dedizione.

Se lo Scrum Master lavora anche come Developer o, addirittura, su più prodotti allo stesso tempo, ovviamente il tempo per ottenere un team efficace si allungherà.

Nell’episodio del podcast Scrum 🇮🇹 che trovi qui sotto, condivido vantaggi ed inconvenienti della doppia responsabilità Scrum Master / Developer.

Risultato

Risultato: ciò che risulta come esito definitivo e conclusivo di un’azione, un’attività o un’operazione (ref. Treccani)

Il risultato è una cosa diversa dalla performance. È perfettamente possibile ottenere risultati mediocri con un team performante e viceversa (grazie alla fortuna). Le due cose sono sconnesse.

Product Owner in Scrum
Clicca l’immagine per ascoltare il podcast

Un team performante avrà più probabilità di ottenere buoni risultati se il Product Owner capisce la propria responsabilità: massimizzare il valore del prodotto. Che vuol dire avere il coraggio di fare piccoli esperimenti per capire se la direzione presa è quella giusta.

E qui si dovrebbe capire come Scrum, nella sua semplicità, è potente.

Un Product Owner incapace (per diverse ragioni) di fornire una direzione chiara, che non ha il gusto della sperimentazione, probabilmente porterà il team ad avere risultati mediocri oppure, tutt’al più equivalenti a quelli che già si hanno.

Un Product Owner sostenuto e rispettato dall’azienda, capace di prendere iniziative coraggiose, di sperimentare e osare probabilmente otterrà uno dei due risultati possibili che mi vengono in mente: successo o esperienza necessaria ad ottenere successo in futuro.

Nel video qui sotto, un pò datato ma ancora d’attualità, condivido quanto le tre responsabilità di Scrum siano necessarie per la performance.

Scrum: performance e risultato – come si ottengono i risultati?

Uno Scrum Team ottiene una migliore comprensione dei risultati che può raggiungere quando:

  • ha una visione e un Product Goal chiari, quindi un Product Owner che condivide una strategia
  • è capace di “ascoltare” i propri utilizzatori, per proporre soluzioni
  • ha l’umiltà di pensare che le soluzioni sono ipotesi di successo e necessitano il feedback dell’utilizzatore per sapere se “funzionano”
  • è capace di fornire incrementi di prodotto di qualità impeccabile
  • sa rimettersi in discussione e trovare nuove soluzioni

Conclusione

In conclusione, performance e risultati sono due cose diverse. Darsi il tempo per crescere e sperimentare è importante per ottenere un team performante e, forse, ottenere risultati.

Il successo non si compra, il successo è il risultato di un duro lavoro. Chiedere agli sportivi di professione per conferma.

Scrum professionale ci prepara alla performance e ci fa comprendere ed accettare che il risultato è spesso frutto di un duro lavoro di collaborazione fra il produttore ed il consumatore.

Continua ad imparare Scrum Professionale

Superare il concetto di ritardo con Scrum

Superare il concetto di ritardo con Scrum è possibile! In un mondo in cui le scadenze sono spesso un pilastro cruciale, l’approccio di Scrum può inizialmente suscitare dubbi e scetticismo. La flessibilità apparente delle funzionalità da sviluppare può sembrare controintuitiva, ma è proprio questa caratteristica che rende Scrum un approccio ideale per affrontare problemi complessi in modo empirico. Questo articolo esplora come il concetto di “ritardo” si trasforma in un’opportunità di crescita, quando Scrum è applicato con competenza. Clicca qui, o nell’immagine qui sotto, per ascoltare l’episodio del Podcast Scrum 🇮🇹.

superare ritardo scrum
Clicca l’immagine per ascoltare il podcast

Affrontare la complessità empiricamente

L’idea di essere in ritardo presuppone una conoscenza completa e certa delle variabili coinvolte in quello che si sta facendo.

In tutta onestà, nel tuo progetto, puoi immaginare una cosa del genere? Nel contesto aziendale, le variabili sono spesso innumerevoli e i percorsi da seguire sono, molto spesso, incerti. Bisogna farsene una ragione.

L’approccio Scrum sfida questa prospettiva. Accetta l’incertezza come un dato di fatto e si basa su iterazioni brevi e feedback costante per adattarsi alle sfide emergenti. Questo significa che le “scadenze rigide di un’insieme di funzionalità” vengono trasformate in obiettivi, consentendo al team (ed al cliente!) di adattarsi ai cambiamenti e di affrontare la complessità con una mentalità aperta. Le funzionalità diventano variabili, in quantità e granularità (nel senso finezza di sviluppo).

Superare il concetto di ritardo con Scrum. Dal contenuto fisso all’obiettivo da raggiungere

Il Product Owner riveste un ruolo fondamentale nell’orientare il team verso il successo. Invece di considerare le scadenze come funzionalità statiche, il focus si sposta sugli obiettivi del prodotto. Il Product Owner, grazie alla sua conoscenza del contesto business e dei clienti, è capace di fissare Product Goals, stabilendo un legame chiaro tra le attività del team e l’obiettivo attraverso il contenuto del Product Backlog.

Superare il concetto di ritardo con Scrum, significa avere un Product Owner che sia libero di fissare Product Goals chiari e misurabili.

L’Empirismo in azione: Sprint dopo Sprint

Superare il concetto di ritardo con Scrum - cos'è Scrum?
Le Basi di Scrum – Cos’è Scrum?

Un aspetto distintivo di Scrum è lo Sprint, in cui il team affronta una parte specifica del lavoro in un periodo di tempo definito. Ogni Sprint è un passo in avanti verso un Product Goal e realizza le funzionalità del Product Backlog coerenti con questo obiettivo.

L’empirismo è alla base di ogni Sprint. Le funzionalità vengono sviluppate in modo iterativo, consentendo al team (e agli Stakeholders) di apprendere e adattarsi man mano che la conoscenza e l’esperienza cresce. Il coinvolgimento del cliente alla fine di ogni Sprint garantisce un feedback tempestivo, orientando ulteriormente il percorso del progetto.

Costruire Fiducia e Valore

L’approccio Scrum, se implementato con maestria, produce risultati che spazzano via l’angoscia del ritardo. Oltre a raggiungere i tradizionali obiettivi di progetto, il processo crea elementi di valore che vanno oltre il mero rispetto delle scadenze:

1. Fiducia: Ogni Sprint dimostra il progresso costante del team, costruendo fiducia sia internamente che verso i clienti o gli stakeholder.

2. Prodotto Funzionante: ogni Sprint porta a un incremento di prodotto funzionante, anche se non corrisponde esattamente alla visione iniziale. Questo approccio guidato dal feedback produce un prodotto di valore reale.

3. Agilità per il futuro: la flessibilità di Scrum consente al team di adattarsi rapidamente ai cambiamenti. Man mano che si apprende e si cresce, il team può perseguire nuove direzioni o eliminare funzionalità superflue.

Superare il concetto di ritardo con Scrum: affrontare le Sfide Comuni

Sebbene Scrum offra un approccio valido, le sfide possono emergere. La mancanza di risorse, la mancanza di interazione con il cliente e altri ostacoli possono minare l’efficacia dell’approccio. In queste situazioni, la collaborazione diventa fondamentale. I membri del team, gli stakeholder e l’azienda devono lavorare insieme per comprendere le priorità reali, mantenendo la qualità e il benessere del team al centro dell’attenzione.

In sintesi, Scrum si dimostra un’arma potente per affrontare il concetto tradizionale di “ritardo”. Il suo approccio empirico, basato su feedback costante, flessibilità e adattabilità, trasforma le sfide in opportunità di crescita e successo. Se applicato con dedizione e competenza, Scrum guida il team verso la fiducia, il valore e una gestione più efficace dei progetti complessi.

Con scrum.org, la nostra missione consiste ad aiutarvi a risolvere problemi complessi, qui sotto trovate alcuni dei corsi che potranno aiutarvi a capire meglio come superare il concetto di ritardo con Scrum!

Scrum e la reazione autoimmune aziendale

Scrum e la reazione autoimmune aziendale è una riflessione sulla mia esperienza dell’applicazione di Scrum professionale in azienda. Rivela i meccanismi socio-aziendali, ai quali ho assistito, che impediscono di trarre massimo beneficio dallo sviluppo empirico di un prodotto.

Scrum e la reazione autoimmune aziendale
Clicca l’immagine per ascoltare il podcast

Ovviamente non sono un esperto in campo medico, mi scuso in anticipo se certi paralleli o nozioni sono incorrette da questo punto di vista.

Il parallelo fra Scrum Professionale (considerata come “sostanza sana” quando si pensa allo sviluppo di prodotti complessi) e gli anticorpi aziendali (che dovrebbero riconoscere Scrum come “amico”, ma non lo fanno, scatenando una reazione anomala di distruzione autoimmune) mi è venuto da tempo e penso possa essere una buona metafora per rappresentare le sfide che ci aspettano in azienda.

Qual’è un ambiente di lavoro considerato come “sano” in un contesto di complessità?

Un ambiente di lavoro “sano” consiste in pochi principi, ma importanti:

Scrum e la reazione autoimmune aziendale - un anticorpo
Anticorpo
  • Servant Leadership: dei dirigenti e manager che sono al servizio delle persone che lavorano, per aiutarle ad abbattere gli ostacoli che impediscono di creare prodotti complessi (burocrazia, procedure, silos, gerarchie, etc.)
  • Psychological Safety: trovarsi in un ambiente di lavoro che permette di imparare velocemente, eventualmente celebrando gli errori che fanno parte del processo di apprendimento
  • Responsabilità chiare: un capitano, il Product Owner, delle competenze per dirigere la nave e esplorare soluzioni (i Developers), una persona che conosce bene le regole del gioco (lo Scrum Master)
  • Capacità a fissare obiettivi chiari e misurabili: per fare focus e scelte coscienti e motivate
  • Competenze: per fare quello che si deve fare
  • Focus alla risoluzione di problemi o opportunità: capire bene per chi si lavora e come si può soddisfare
  • Ownership condivisa: grazie ad obiettivi chiari
Video un pò datato, ma ancora valido. Scusate il suono orribile.

Il sistema immunitario aziendale

Un’azienda tradizionale è stata concepita secondo un modello di produzione industriale, trarre massimo profitto dalla produzione di massa. È il sistema immunitario aziendale. Di conseguenza, è normale osservare:

  • Command & Control: il management dice ai lavoratori cosa (e, a volte, come) devono fare il lavoro
  • Sanzione dell’errore: se non si mantiene la parola data, o qualcosa va storto, saltano teste
  • Responsabilità sparsa: su diverse persone, con due risultati possibili (decisioni lente, oppure immobilismo)
  • Carriera: le persone gerarchicamente di alto livello hanno uno stipendio migliore, concorrenza interna, politica
  • Focus su funzionalità: senza pensare o chiedere agli utenti il loro feedback
  • Silos: ossia funzioni ottimizzate per produrre un certo tipo di output come, per esempio, marketing, informatica, sales, etc.
  • Burocrazia: processi e procedure per assicurarsi che ogni tipo di input crea un preciso output in qualsiasi situazione

Scrum e la reazione autoimmune aziendale

Quando Scrum Professionale arriva in azienda, si osserva la reazione autoimmune aziendale, che lo riconosce come una minaccia e lo attacca, in maniera più o meno evidente.

Fabio Panzavolta

Nella mia esperienza ho potuto osservare le reazioni autoimmuni seguenti, in ordine casuale e non esaustivo:

  • L’adattamento di Scrum all’azienda: ossia modificarlo profondamente per farlo entrare nei processi aziendali, mantenere le gerarchie ed i controlli esistenti. Qualche esempio:
    • Nominiamo due Product Owner, uno business e uno tecnico. Invece di una sola persona, con la conseguenza di creare disordine e difficoltà a prendere decisioni.
    • Selezioniamo gli eventi Scrum che ci fanno più comodo. Limitando la capacità a lavorare in modo empirico e, di fatto, mantenendo il lavoro a cascata (waterfall)
    • Imponiamo una quantità di lavoro ai Developers, gli obiettivi sono inutili. Annullando l’autogestione, l’ownership e la responsabilità
    • Facciamo a meno dello Scrum Master, non serve a niente. Alimentando il massacro di Scrum, in quanto non c’è più nessuno che può aiutare a combattere gli anticorpi.
  • L’autogestione da noi non funziona: continuiamo a scrivere specifiche, assicurandoci che siano seguite alla lettera e nei tempi stabiliti. E poi serve comunque qualcuno che gestisca il team, altrimenti il lavoro non va avanti
  • La pressione è necessaria per far lavorare le persone: quindi imponiamo date di fine all’inizio del progetto, su scope fisso e chiediamo il commitment a tutto il team. Sacrificando la qualità e l’innovazione
  • Il reporting è fondamentale: dobbiamo sapere come vanno le cose per poter prendere decisioni. Il team non è in grado di farlo. Controllare le persone è più facile rispetto al controllo degli obiettivi e delle performance del prodotto.

Ci sono tante altre reazioni autoimmuni, quali osservi nel tuo lavoro? Scrivilo nei commenti!

Quali sono le cure alla reazione autoimmune?

Se hai riconosciuto almeno una reazione autoimmune fra quelle elencate, non tutto è perduto, esistono delle cure 😊. Più o meno invasive.

L’ideale consiste a cominciare a lavorare con Scrum per scatenare le reazioni autoimmuni, osservarle e renderle trasparenti. In poche parole bisogna avere il coraggio di non seguire la corrente.

Fabio Panzavolta

Un piccolo team, di qualche persona, che lavora secondo i principi di Scrum, rivelerà molte cose che non funzionano in azienda.

Una volta rivelati i disfunzionamenti aziendali, l’obiettivo è quello di curare la reazione autoimmune, non cambiare Scrum.

Bisogna fare tutto ciò che è necessario per far riconoscere Scrum come “sostanza sana” e far progredire la sua comprensione/applicazione, per l’interesse dell’azienda e degli utilizzatori dei prodotti.

La brutta notizia è che la soluzione miracolo non esiste, bisogna sperimentare approcci diversi, a seconda del contesto, per capire cosa funziona meglio.

La buona notizia è che, dal momento che si vedono progressi nel sistema azienda, anche minimi, allora vuol dire che le cose evolvono. Ci vuole pazienza e perseveranza ed anche un buon grado di accettazione che la reazione autoimmune potrebbe vincere.

Vediamo qualche cura possibile da sperimentare.

Ristabilire la Psychological Safety – Team Manifesto

Per prima cosa lavorare nel contesto dello Scrum Team, che deve assolutamente capire che certi comportamenti e decisioni sono necessari quando si crea un prodotto complesso. Quindi la nozione di quello che è “giusto o sbagliato” cambia. Questa può essere una vera sfida per quei team composti in parte da dipendenti e in parte da contractors.

Questo è un lavoro che si fa mettendo al centro i Valori Scrum (coraggio, rispetto, apertura, focus, commitment), assolutamente fondamentali per comportarsi in modo consono ad un contesto complesso.

Scrum e la reazione autoimmune, un workshop per scoprire i valori Scrum
Scrum e la reazione autoimmune aziendale – Clicca l’immagine per accedere al contenuto

Il Team Manifesto è necessario per rendere trasparente la nozione di coraggio (ad esempio) per ogni membro del team, riconoscere e mettersi d’accordo su cosa vuol dire avere coraggio per il team ed impegnarsi a comportarsi di conseguenza.

Questo aiuta a capire che il comportamento del team, di fronte a certe situazioni, sarà uniforme e contribuisce ad aumentare la sicurezza psicologica.

Ovviamente il Team Manifesto è qualcosa che evolverà nel tempo, un ottimo strumento per accogliere un nuovo arrivato, per esempio.

Comprensione di Scrum

Comprendere perché Scrum è uno strumento adatto alla risoluzione di problemi complessi è assolutamente necessario.

Scrum e la reazione autoimmune - Un esempio di adozione di Scrum
Clicca l’immagine per accedere al contenuto

Le regole del gioco sono descritte nello Scrum Guide, disponibile anche nel nostro podcast Scrum Italia.

Applicare Scrum secondo le regole permetterà di rivelare ciò che disfunziona in azienda (attivare gli anticorpi aziendali per riconoscerli) e che è necessario correggere, col tempo, per rimanere o diventare competitivi in un contesto di complessità.

Un’esempio di come ho aiutato un’azienda ad adottare Scrum si trova qui a destra (in inglese).

Come riconoscere la guarigione dalla reazione autoimmune

La guarigione prenderà tempo, a seconda della cultura aziendale. Aziende che esistono da decine d’anni, con strutture gerarchiche piramidali forti avranno più difficoltà ad evolvere. A volte evolvono fino ad un certo punto, per poi tornare improvvisamente ai vecchi metodi di lavoro. Altre volte evolvono solo in certi dipartimenti, non a livello globale.

I segnali che considero come positivi e che permettono di riconoscere un certo successo sono:

  • Meno burocrazia: si semplifica il lavoro, concentrandosi e mantenendo unicamente i processi utili alla creazione di valore
  • Personale più felice: meno assenze per malattia, ambiente più sereno e quindi più produttivo
  • Clienti più felici: i clienti acquistano fiducia, si sentono ascoltati e credono in noi per risolvere i loro problemi
  • Qualità del prodotto in crescita: meno interruzioni dalla produzione, quindi più focus per creare nuove cose
  • Rapidità nell’arrivare sul mercato: capacità del team a mettere in produzione più rapidamente e regolarmente
  • Capacità di reazione alle difficoltà: il team è capace di trovare soluzioni a qualsiasi cambiamento, da solo, dimostrando la capacità di adattamento richiesta in un contesto di complessità

Quali altri segnali positivi hai notato nella tua azienda? Condividili nei commenti!

Conclusioni

Il problema nelle aziende non è Scrum, o qualsiasi altro approccio di lavoro, il problema è la reazione aziendale alla novità. Perché rappresenta un pericolo, scatenando la reazione autoimmune.

Una malattia autoimmune si può curare, a volte ci si deve convivere, altre volte ci vogliono interventi chirurgici pesanti. Mi scuso se qualche lettore è passato attraverso queste prove difficili, è una metafora forse fuori luogo, ma che trovo talmente azzeccata in un contesto di adozione di Scrum in azienda.

Il problema in azienda è la mancanza di leadership, di visione. Le persone che sono semplici esecutori di “ordini”, la mancanza di fiducia (orizzontale e verticale), l’incapacità a dire di no, una strategia mirata solo alla creazione di fatturato o soddisfazione degli azionari.

Questi sono i problemi, non Scrum o qualsiasi altro approccio di lavoro.

La leadership mediocre, porta a risultati mediocri e a reazioni autoimmuni che alimentano la mediocrità.

In conclusione mi piace ricordare il perché si ha bisogno di Scrum. Il futuro (ormai il presente) è costituito da prodotti customizzabili, riutilizzabili, ecologici, utili, specifici.

L’utente è ormai il prodotto, bisogna capirlo per soddisfarlo, non creare qualcosa e poi pensare che una campagna marketing o un buon venditore riuscirà a venderlo.

Gli anticorpi aziendali fanno di tutto per continuare a creare prodotti che non hanno qualità, arrivano tardi sul mercato, non corrispondono a qualcosa che gli utenti desiderano, creano un sacco di spreco, di infelicità.

La nostra missione, da Collective Genius e Scrum.org, è quella di aiutarvi a far riconoscere Scrum come elemento “sano” del vostro sistema azienda e farvi diventare il leader di mercato del vostro mestiere!

Per approfondire

Le formazioni che aiutano a far riconoscere Scrum come un elemento sano all’azienda!

Project Management e Professional Scrum

Project Manager e Scrum Master, due mestieri diversi

Project Manager e Scrum Master sono due mestieri diversi. Se sei un project manager, senti parlare sempre di più di Scrum e vorresti capire cosa c’è di così diverso fra questi due ruoli? Perché dovresti scegliere fra l’uno o l’altro e non si può fare un pò dei due?

In questo articolo provo a condividere le risposte a queste domande, con i principi e le ragioni che differenziano Scrum Professionale dal Project Management.

L’obiettivo non è quello di convincere che Scrum è la soluzione miracolo a tutto, al contrario. La mia esperienza come project manager mi porta ad apprezzare tutto quello che ho imparato durante gli anni spesi a gestire progetti in modo tradizionale.

Aggiornamento del 6 luglio 2023 – aggiunta del video dell’evento in diretta relativo a questa tematica.

Premessa

Ho avuto tre esperienze principali di lavoro:

  1. Sviluppatore software per sistemi industriali complessi (essenzialmente C, C++ e SQL) dal 2001 al 2006 (6 anni)
  2. Team leader, project e program manager nel settore bancario, trasporto e logistica, finanza dal 2007 al 2014 (8 anni)
  3. Scrum Master e Professional Scrum Trainer dal 2015 ad oggi (9 anni)

Conosco bene cosa pensa (e cosa vive) uno sviluppatore, un project manager o uno Scrum Master. In particolare, per averli vissuti personalmente, conosco le sfide che un project manager deve affrontare se vuole diventare un buon Scrum Master.

Esploriamole insieme!

Project Manager e Scrum Master

Sono due mestieri diversi. È importante capirlo, perché il focus e le responsabilità di questi due ruoli sono diametralmente opposti.

Project Manager
Il Project Management funziona bene in contesti complicati o semplici (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)

Project Manager: ha per missione di tenere sotto controllo costi, time e scope del progetto. Garantisce all’azienda che gli investimenti strategici sono correttamente gestiti. Spesso è un esperto tecnico o funzionale e dice ai colleghi cosa fare, assegna i task e controlla che siano eseguiti secondo i piani. Ne parlo in questo articolo.

Un project manager lavora per soddisfare il management interno, ovvero controllare che il lavoro sia eseguito secondo i piani.

Fabio Panzavolta
Scrum Master
Scrum funziona bene in contesti complessi (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)

Scrum Master: ha per missione di assicurarsi che Scrum è correttamente capito ed utilizzato. Contrariamente al project manager, i risultati del team “non gli interessano”. Se i membri dello Scrum Team hanno capito cosa vuol dire creare prodotti complessi in modo empirico, i risultati arriveranno.

Lo Scrum Master è un servant leader, aiuta a rimuovere gli ostacoli che impediscono il raggiungimento degli obiettivi del team (ne parlo in questo articolo).

Uno Scrum Master (con tutto lo Scrum Team) lavora per soddisfare gli utilizzatori del prodotto il più rapidamente possibile.

Fabio Panzavolta

Project Manager e Scrum Master, focus interno o esterno all’azienda?

La ragione di esistere di un project manager è quella di limitare i rischi aziendali garantendo il controllo degli investimenti.

Questo funziona principalmente per progetti altamente prevedibili, per i quali non sono previsti cambiamenti sostanziali durante lo sviluppo.

Quando lavoravo come project manager i primi cambiamenti al piano del progetto arrivavano molto rapidamente. Questo portava inevitabilmente a ginnastiche improbabili per non stravolgere il piano.

Project Manager – Focus interno

Per un Project Manager il focus è interno all’azienda, si passa più tempo a negoziare un paio d’ore di lavoro a destra e sinistra con gli sviluppatori che a sviluppare effettivamente il prodotto.

Questo focus interno porta a perdere di vista il perché si fa un progetto concentrandosi principalmente su budget, time e scope.

Ho personalmente conosciuto sviluppatori software che lavoravano da due anni su un progetto e non avevano mai visto il prodotto finito… immaginate la motivazione e l’impegno che potevano mettere al lavoro.

Scrum Master – Focus esterno

Uno Scrum Master, aiuta lo Scrum Team e gli stakeholders a fare un focus sui problemi da risolvere agli utilizzatori, ad ottimizzare il lavoro non fatto per concentrarsi solo su ciò che è veramente importante: il valore creato per gli utilizzatori del prodotto.

Questo non vuol dire che i limiti aziendali sono ignorati, perché il Product Owner fa attenzione a massimizzare il valore del prodotto. Quindi, per esempio, il budget a disposizione è speso in maniera opportunistica e non pianificata su un anno o due, ma con cicli di un mese al massimo.

Massimizzare il valore del prodotto vuol dire, fra l’altro, che la strategia del Product Owner implica la creazione di un prodotto che si auto-finanzierà il prima possibile.

Project Manager e Scrum Master, Scope fisso o variabile!

Altro cambiamento fondamentale, uno Scrum Master aiuta ad acquisire un modo di lavorare orientato sugli obiettivi, i requirements ci interessano, ma fino ad un certo punto.

Il project manager raccoglie tutti i requisiti, che molto spesso fanno parte del contratto. Per ottimizzare (sigh, sob 😊) si cerca di elencare tutte le funzionalità, con il cliente, nelle prime fasi del progetto. In modo tale da non doversi più vedere per un annetto o due (ri-sigh, ri-sob).

Ovviamente questo modo di lavorare funziona, come dicevo prima, se ciò che state facendo non ha incertezze sostanziali.

Purtroppo (in particolare per l’informatica), molto spesso il cliente non sa nemmeno cosa vuole. Oppure (che è anche peggio) è assolutamente convinto di sapere cosa vorrebbe avere (poi si scopre che gli utenti e i loro problemi quotidiani non li conosce veramente).

Quindi il povero project manager (esperienza vissuta) fa dei piani nel momento in cui il team, il cliente e lui stesso hanno meno esperienza e meno informazione possibile… conoscete i risultati… altrimenti non sareste arrivati fino qui a leggere 😊.

Da Project Manager a Scum Master

Questo problema è risolto in Scrum, perché invece di lavorare a scope fisso, si lavora con obiettivi fissi, concedendo una certa “liquidità” nelle funzionalità da implementare grazie all’ordinamento del Product Backlog.

Lo Scrum Master insegnerà a tutti (anche al cliente) come fondare il lavoro su obiettivi, generare risultati concreti per gli utilizzatori e farà in modo che le esigenze emergano con l’esperienza, grazie al feedback degli utilizzatori ed alla collaborazione regolare con il cliente.

In un mondo complesso ed incerto, quando non si sa veramente cosa si vuole, un prodotto non si pianifica, emerge dall’esperienza.

Fabio Panzavolta

Scegliere di fissare un obiettivo ed avere funzionalità variabili avrà come conseguenza una migliore qualità, più implicazione da parte di tutti, più innovazione nella ricerca di soluzioni e più rilasci in produzione.

Project Manager e Scrum Master, dalle esigenze agli obiettivi

Parlavo di contratto prima… quante volte, da project manager, mi sono trovato a dover discutere con il cliente per giorni, settimane per cambiare una virgola in una particolare esigenza… con il risultato che dopo la discussione ci volevano altre settimane per avere il GO per implementare il cambiamento (che nel frattempo, a volte, era già stato fatto).

Purtroppo, in certi casi, ci siamo anche trovati ad implementare delle cose che sapevamo sbagliate, o incoerenti, per non dover subire il processo descritto sopra.

Il focus sulle esigenze è un focus malato in un contesto complesso e mutevole.

Fabio Panzavolta

Il giusto focus è negli obiettivi… in Scrum ce ne sono due:

  • Product Goal: definito dal Product Owner, è un obiettivo a medio termine, un passo in più verso la visione del prodotto
  • Sprint Goal: definito dallo Scrum Team, è un obiettivo a corto termine (un mese massimo), un passo in più verso il Product Goal

In un contratto si possono fissare i Product Goal, facendo attenzione a non renderli troppo stringenti, bensì sufficientemente vaghi per dare una direzione e lasciare libertà nel decidere cosa e come sperimentare nuove soluzioni.

Segui questo link se vuoi saperne di più sui contratti agili.

Riuscire a fare un focus sul goal (Scrum Professionale) e non sui requirements (Project Management), vuol dire concentrarsi sul perché si vuole fare qualcosa, non sul come. Le discussioni sul cosa e come raggiungere l’obiettivo saranno legate al perché si vogliono fare, con un focus maggiore, più o meno funzionalità a seconda del contesto e degli esperimenti che si faranno collaborando.

Conclusioni

Project Manager e Scrum Master sono due mestieri diversi, con focus diverso. Non si può pensare di accettare un ruolo di Scrum Master senza aver capito Scrum Professionale o le responsabilità di uno Scrum Master (ne parlo in un episodio del podcast Scrum 🇮🇹).

La difficoltà non è Scrum, bensì il cambiamento nel modo di pensare, agire e prendere decisioni.

Uno Scrum Master si accontenta di rivelare ciò che non funziona secondo Scrum, non dà soluzioni o dice agli altri cosa fare. Piuttosto, aiuta le persone a trovare e sperimentare le soluzioni grazie alle idee che emergono discutendo.

Se sei un Project Manager e desideri cominciare o continuare il tuo percorso di professionalizzazione, puoi cominciare da autodidatta.

Personalmente ho letto tanto, questi sono i libri, ho praticato in condizioni differenti (prima in contesti al di fuori del lavoro, poi al lavoro) e non smetto mai di pensare che sto ancora imparando.

Un’altra fonte inesauribile di conoscenza è ovviamente il sito scrum.org, ma anche i blog di Ken Schwaber e Gunther Verheyen, i miei due punti di riferimento.

Se vuoi imparare o migliorare la tua conoscenza di Scrum Professionale, facendoti accompagnare, puoi anche scegliere di partecipare ad una delle nostre formazioni.

Scrum On!

Perché Scrum non è una metodologia?

Spesso in formazione si discutono le differenze fra metodologia e framework. In questo articolo troverete la risposta alla domanda: “Perché Scrum non è una metodologia?”

Una metodologia di lavoro consiste ad applicare sempre lo stesso processo, con gli stessi input e output, per realizzare il lavoro. L’obiettivo è di ridurre i rischi e rendere il risultato del lavoro prevedibile.

L’apparizione delle metodologie di lavoro risale al periodo della rivoluzione industriale, l’esempio classico è la catena di montaggio che è pensata per assemblare diversi componenti il più rapidamente possibile ed ottenere come risultato finale il prodotto voluto. Una metodologia ottimizza l’output che si vuole creare, il risultato finale è conosciuto in anticipo.

Con l’avvento di nuovi mestieri, come l’informatica, profondamente differenti dal concetto di una catena di montaggio, si è applicato ciò che si conosceva, trascurando il fatto che la soluzione ad un problema non era conosciuta in anticipo. Ciò ha creato tensioni e problemi di vario tipo fra i lavoratori e il management.

Una metodologia è utile per risolvere un problema semplice, è un’approccio predittivo che presuppone la conoscenza anticipata dello stato finale che si vuole raggiungere.

Fabio Panzavolta

l’evoluzione del pensiero

Nel 1990 alcuni professionisti del mondo dell’informatica, fra i quali Ken Schwaber e Jeff Sutherland (creatori di Scrum) hanno capito che i ritardi, la scarsa qualità e le inefficienze nella creazione di software non erano dovute alle persone che non lavoravano abbastanza duramente, o che non applicavano correttamente la metodologia, bensì al paradigma adottato.

Prima con Extreme Programming poi con Scrum, le cose hanno cominciato a cambiare. L’accettazione del fatto che non si può prevedere in anticipo tutto il lavoro necessario alla creazione di un prodotto complesso ha lasciato lo spazio ad un cambiamento di paradigma.

L’empirismo a preso il posto del determinismo. Un processo empirico basa tutte le decisioni future sull’esperienza passata: la soluzione ad un problema, la creazione di un prodotto o servizio emergono dal feedback ricevuto dall’utilizzatore.

Ken Schwaber, co-creatore di Scrum, in questo articolo descrive le organizzazioni moderne prendendo come metafora il film “La tempesta perfetta” dove una serie di circostanze sfortunate e concomitanti creano una situazione praticamente incontrollabile per l’equipaggio del peschereccio. È evidente come, in questo contesto, nessun tipo di metodologia potrà aiutare l’equipaggio a sopravvivere. Al contrario, la sperimentazione di diverse manovre è necessaria per capire come la barca reagisce e trovare la via d’uscita.

LONDON, ENGLAND – MARCH 09: Federico Ruzza of Italy is tackled by Jamie George of England during the Guinness Six Nations match between England and Italy at Twickenham Stadium on March 09, 2019 in London, England. (Photo by Michael Steele/Getty Images)

Ecco perché Scrum non è una metodologia! Spesso descriviamo Scrum come un gioco di società, oppure come il Rugby, con le proprie regole, principi e valori. Se si vuole giocare a Scrum, bisogna avere il coraggio di affrontare l’incertezza e sperimentare diverse soluzioni fino a trovare quella più adatta al momento.

Scrum permette di navigare l’incertezza, esplorando diverse soluzioni adattative per risolvere problemi complessi.

Fabio Panzavolta

Conclusione

Perché Scrum non è una metodologia? Perché Scrum lascia le persone libere di prendere decisioni per adattarsi a qualsiasi situazione e seguendo poche regole semplici. Basti pensare che lo Scrum Guide in inglese è un libretto di 13 pagine!

Nella tabella qui sotto riassumo alcune differenze fra una metodologia ed un framework, con l’obiettivo di comprenderne la differenze ed aiutare nella scelta migliore per il problema che dovete risolvere.

MetodologiaFramework
Un processo predefinito e ripetitivo, con gli stessi step, input e output da applicare meccanicamenteDelle regole, principi e valori da seguire per creare un processo empirico adatto al problema da risolvere
DeterministicoEmpirico
La soluzione è immaginata all’inizioLa soluzione emerge grazie al feedback degli utilizzatori
Utile quando è tutto sotto controllo, pochi cambiamenti e si ha una conoscenza estesa del lavoroUtile in contesti complessi, con molti cambiamenti e incertezza sulla soluzione da fornire per un problema dato
Le persone seguono le istruzioni, poca comunicazione, divisione e specializzazione del lavoroLe persone seguono le stesse regole, principi e valori. Comunicano e collaborano nella ricerca della soluzione attraverso la sperimentazione.
Ottimizza l’efficaciaOttimizza la resilienza
Differenze fra metodologia e framework