Rendere concreta un'idea, questa è la parte difficile. Avere solo una visione non è sufficiente, bisogna capire cosa si farà domani per iniziare il lungo viaggio per trasformare l'idea in qualcosa di reale, e poi c'è la parte difficile. Quello che stai per fare è davvero la cosa giusta da fare? Dovete ottenere un rapido feedback sui progressi reali per saperlo. Questo è ciò che conta, questo è il punto di Scrum. Non è solo qualcosa che fai. Lo si fa per arrivare da qualche parte. Per fornire valore.
Nell'aggiornare la Guida Scrum 2020, i co-creatori di Scrum non hanno cambiato Scrum stesso. Quello che il Dr. Jeff Sutherland e Ken Schwaber hanno fatto, tuttavia, è stato trovare modi migliori per descriverlo. Modi migliori per spiegare lo scopo di ogni elemento del framework.
Probabilmente l'aggiornamento più notevole nella Guida Scrum 2020 mostra come questa chiarezza porterà a risultati migliori.
Onestamente non so dirvi quante volte ho visto questo scenario. Entriamo in un'organizzazione e troviamo un mucchio di team che lavorano su cose che nessuno vuole. È come guardare una masterclass sull'arte oscura della consegna a valore zero.
Il problema non sono i cattivi team, o i cattivi backlogs, o anche i cattivi Product Owner. Il problema è che non c'è nessuna connessione tra ciò che l'organizzazione vuole raggiungere e ciò che gli Scrum Team stanno facendo da Sprint a Sprint. Niente che leghi la visione con i passi concreti necessari per renderla reale. Questo è il motivo per cui ognuno dei tre artefatti Scrum ha ora un impegno corrispondente.
Come afferma la Guida Scrum 2020, "Questi impegni esistono per rafforzare l'empirismo e i valori di Scrum per lo Scrum Team e le loro parti interessate". Ognuno dei nuovi impegni migliora "la trasparenza e la focalizzazione rispetto alla quale il progresso può essere misurato".
L'impegno per il Product Backlog è il Product Goal. Per lo Sprint Backlog, è lo Sprint Goal. Per l'Incremento, è la Definizione di Fatto.
Lo Sprint Goal è il singolo obiettivo per lo Sprint. Anche se lo Sprint Goal è un impegno da parte degli sviluppatori, fornisce flessibilità in termini di lavoro esatto necessario per raggiungerlo. Lo Sprint Goal crea anche coerenza e concentrazione, incoraggiando lo Scrum Team a lavorare insieme piuttosto che su iniziative separate.
E' troppo facile uscire dalla pianificazione dello Sprint con uno Sprint Backlog che è un assortimento abbastanza casuale di Product Backlog Items che tutti sanno che devono essere fatti, ma non hanno nessun senso del perché, esattamente. Perché questo gruppo di PBI piuttosto che qualche altra classifica? A cosa si aggiungono? Perché il Product Owner sta dando le priorità in questo modo?
Proprio come possiamo perdere individualmente la concentrazione passando da una cosa all'altra lasciando del lavoro fatto a metà nella nostra scia, così può fare uno Scrum Team. Il Team ha bisogno di concentrarsi su quale sia lo scopo dello Sprint. A cosa servono tutte queste cose? Cosa stiamo cercando di realizzare? O per dirla più semplicemente risponde alla domanda più importante in Scrum, perché?
La maggior parte delle volte, sfortunatamente, non tutto nello Sprint Backlog ha qualcosa a che fare con l'obiettivo dello Sprint. C'è quasi sempre qualcosa di solito che deve essere fatto. Questo va bene, ciò che è importante è che tutto ciò su cui lo Scrum Team sta lavorando sia in quello Sprint Backlog, in modo che sia visibile quanta della loro capacità è usata per le cose che il cliente vuole veramente e quanta è occupata da cose che non hanno niente a che fare con quella cosa veramente importante che è l'obiettivo dello Sprint.
Un Navy SEAL che implementa Scrum nel suo team mi ha recentemente detto qualcosa che mi è rimasto impresso: "Lo sforzo è la nostra moneta". Avere un chiaro Sprint Goal dice dove questa moneta dovrebbe essere spesa e avere uno Sprint Backlog trasparente mostra dove viene effettivamente spesa. Questo dovrebbe portare il team e gli stakeholder a rivalutare quale valore viene effettivamente acquistato.
Lo Sprint Goal è l'impegno del Team su ciò che sarà consegnato dallo Sprint Backlog. Lo Sprint Backlog è una descrizione intima di quello che è l'obiettivo.
La Definizione di Fatto è una descrizione formale dello stato dell'Incremento quando soddisfa le misure di qualità richieste per il prodotto. Nel momento in cui un elemento del Product Backlog soddisfa la Definizione di Fatto, un incremento è nato. La Definizione di Fatto è l'impegno del team per la qualità e il valore. Se qualcosa non soddisfa la Definizione di Fatto non può essere rilasciato e non dovrebbe mai essere mostrato alla Sprint Review.
La peggiore forma di spreco, secondo Taiichi Ohno, il creatore del Toyota Production System, è il lavoro non fatto. L'energia è stata spesa, le ore sono state impiegate, una parte di quella moneta è stata spesa, ma non c'è nulla di valore creato. Un processo scritto a metà, un esperimento a metà, un pezzo di codice scritto a metà, un servizio iniziato ma non consegnato.
La Definizione di Fatto dà allo Scrum Team una chiara idea di quali standard il Team deve soddisfare per essere finito con un elemento del Product Backlog. E il team si impegna a raggiungere quell'incremento di prodotto alla fine di ogni Sprint. Parte del valore della Definizione di Fatto è che dà allo Scrum Team un chiaro indicatore di quando le cose sono fatte. Ti dà uno dei più grandi deliverable in Scrum: Il lavoro non fatto. Dice allo Scrum Team dove fermarsi.
Una volta stavo parlando con qualcuno il cui lavoro consisteva nel consegnare la documentazione delle migliori pratiche in una grande organizzazione in modo che potessero essere condivise tra centinaia o addirittura migliaia di team. Aveva una scadenza di qualcosa come una ogni sei settimane o qualcosa del genere. Quando gli ho chiesto quale fosse la sua definizione di fatto, ha risposto con un ritornello fin troppo comune, la data di scadenza. Quando gli ho suggerito di definire "fatto" in anticipo, ho potuto vedere la sua faccia cambiare. "Mi hai appena ridato metà della mia vita". Invece di lavorare fino a una data di scadenza, ha cominciato a lavorare a una definizione di fatto, che gli dava la possibilità di smettere di lavorare quando era finito e passare a qualcos'altro.
Il Product Goal descrive uno stato futuro del prodotto che può servire come obiettivo per lo Scrum Team per pianificare. Il Product Goal è nel Product Backlog. Il resto del Product Backlog emerge per definire "cosa" realizzerà il Product Goal.
Un prodotto è un veicolo per fornire valore. Ha un confine chiaro, stakeholder conosciuti, utenti ben definiti o clienti. Un prodotto potrebbe essere un servizio, un prodotto fisico o qualcosa di più astratto.
Una delle cose che ripeto continuamente ai miei clienti, beh, a chiunque voglia ascoltare in realtà, è "Non fare Scrum per fare Scrum. Fate Scrum per arrivare da qualche parte".
Il Product Goal è in un certo senso la somma di tutti gli Sprint Goal del team. È lo stato che il Product Backlog descrive. È dove lo Scrum Team sta cercando di arrivare. Ogni prodotto o servizio o processo o rilascio o qualsiasi altra cosa ha bisogno di avere un obiettivo. Un obiettivo che è probabilmente molti Sprint nel futuro. Quando mi siedo a scrivere un libro ho un obiettivo, un libro finito che dice quello che voglio dire nel modo in cui voglio dirlo e nelle mani di un lettore. Questo richiede tempo. Di solito mi ci vogliono da un anno a diciotto mesi. Ora quell'obiettivo è grande, e devo tenerlo a mente, ma devo anche pormi la domanda "Cosa farò il prossimo sprint per avvicinarmi a quell'obiettivo? E poi, ancora più importante, "come misuro se quello che sto facendo mi sta avvicinando al mio obiettivo di prodotto", un libro finito?
Parlando con Jeff e Ken sul perché hanno aggiunto l'obiettivo del prodotto come impegno nella guida Scrum, hanno detto che si trattava di affrontare una disfunzione che vedono comunemente nei team Scrum. I team vanno di Sprint in Sprint, forse hanno anche degli Sprint Goals, ma perdono di vista dove vogliono arrivare. Qual è la somma di tutti quegli Sprint? Ci stiamo avvicinando al nostro obiettivo di prodotto o stiamo solo facendo costantemente fuoco sulla cosa più urgente e perdendo di vista la cosa più importante: il valore nelle mani del cliente.
Jeff e Ken vogliono che gli Scrum Team, in particolare i Product Owner, mantengano il Product Goal sempre visibile e sempre davanti agli occhi. È troppo facile farsi distrarre dal prossimo oggetto luccicante o dalla crisi più recente, o peggio ancora, dalla crisi di qualcun altro e perdere di vista quale sia effettivamente l'obiettivo finale e assicurarsi che tutto ciò che il team sta facendo si stia avvicinando a quel punto.
Il successo nell'uso di Scrum dipende dal fatto che le persone diventino più abili nel vivere cinque valori:
Lo Scrum Team si impegna a raggiungere i suoi obiettivi e a sostenersi a vicenda. La loro attenzione primaria è sul lavoro dello Sprint per fare il miglior progresso possibile verso questi obiettivi. Lo Scrum Team e le sue parti interessate sono aperti riguardo al lavoro e alle sfide. I membri dello Scrum Team si aspettano l'un l'altro di essere persone capaci e indipendenti, e sono rispettati come tali dalle persone con cui lavorano. I membri dello Scrum Team hanno il coraggio di fare la cosa giusta, di lavorare su problemi difficili.
L'impegno, per me, è il cuore di Scrum, è il valore che è sostenuto da tutti gli altri valori. È l'impegno dello Scrum Team a fornire valore, a raggiungere gli obiettivi, a risolvere i problemi e a sostenersi a vicenda nel farlo. È un impegno non verso Scrum, di per sé, ma verso l'uso di Scrum per raggiungere gli obiettivi che si sono prefissati.
La Guida Scrum 2020 non ha cambiato Scrum, è una sua migliore descrizione. Scrum non è cambiato, è solo che i co-creatori hanno imparato di più su come esprimerlo. La Guida 2020 con i suoi nuovi tre impegni legati ai tre artefatti non è nuova, sono sempre stati presenti, sono sempre stati impliciti. Ma Jeff e Ken sentivano che dovevano essere più espliciti, che senza questo gli Scrum Team non stavano fornendo il valore che dovrebbero essere in grado di fornire.
Uno Scrum Team si impegna a consegnare qualcosa di valore, un Product Goal. Ogni Sprint Goal è il loro impegno ad avvicinarsi a questo. Ed ogni incremento, ogni volta che qualcosa raggiunge la Definizione di Fatto è il loro impegno a fornire qualità e valore in ogni Item del Product Backlog che creano.
Tradotto e adattato da Scrum Inc.: https://www.scruminc.com/updated-scrum-guide-drives-focus-alignment-value-delivery/
Scritto da JJ Sutherland | Dicembre 4, 2020 | Blog
Vuoi conoscere Scrum? Scegli uno dei componenti del Framework dalla lista e scopri come funziona il framework Agile più diffuso al mondo.