Il regolamento riflessivo

---

Negli ultimi mesi, credo di essermi trasferito in un punto del mio viaggio agile in cui ho iniziato a mettere in discussione le norme e innovare la mia pratica. Non lo dico con arroganza, anzi lo intendo in modo umile perché ultimamente mi sembra di avere più domande che risposte. Questo post sul blog è in realtà più per me stesso (al momento in cui scrivo non sono nemmeno sicuro di aver intenzione di condividerlo), per costringermi a spiegare in modo coerente il mio pensiero sui miglioramenti di Scrum. Giusto avvertimento, non aspettarti alcuna risposta da questo blog. Il mio obiettivo è la riflessione personale e niente di più.

Tornando indietro di circa un anno fa, ho sfidato uno Scrum Master esperto con una domanda. Di recente, in uno scenario completamente diverso con una persona diversa, quella domanda si è ripresentata e quindi ho voluto scriverne. Quella domanda era:

'C'è un punto in cui il framework Scrum stesso diventa un ostacolo al miglioramento continuo?'

So cosa stai pensando. Stai pensando che sono fuori di testa. Ma lascia che ti spieghi perché ho posto la domanda e poi puoi esprimere i tuoi giudizi.

Per me, Scrum consiste nell'apportare empiricamente piccoli miglioramenti sia a un prodotto che al processo che utilizziamo per consegnarlo. Scrum è fantastico – i suoi risultati sono dimostrati – sono 100% venduti. Non è prescrittivo (dopo tutto, è un framework!), ma fornisce una guida leggera su come muoversi verso la massimizzazione del valore. Tuttavia, sono anche un sostenitore del modo di pensare Shu-Ha-Ri (SHR), quindi la domanda che ho posto derivava da come Scrum e SHR potessero coesistere (come mi è stato detto innumerevoli volte che lavorano a mano -in-guanto').

A livello di base, SHR è 'Tradizione' (seguendo le regole), 'Innovare' (sfidando lo status quo) e 'Trascendere' (creando le proprie regole). In qualità di Scrum Master, il mio obiettivo è sempre stato quello di creare un ambiente in cui la creatività e l'auto-organizzazione siano al centro. Perciò 'Shu', dove la squadra osserva il 'norme create dai nostri antenati' è 100% applicabile. Oltre a ciò, però, non sono sicuro di quanto siano applicabili Ha e Ri a Scrum? Di recente ho allenato molti team sul framework Scrum e non riesco nemmeno a contare il numero di volte in cui ho detto "auto-organizzati, ma entro i confini di Scrum'. Se rifletto sul dirglielo, li sto limitando a 'Shu'? Sto impedendo la loro capacità di 'Innovare' E 'Trascendere'? Se la 'le forme possono essere rotte' (Ah) O 'allontanarsi completamente dalle forme (Ri), significherebbe che non stanno facendo Scrum se operano al di fuori dei confini? È un problema? AHHH! Così tante domande!

Penso di aver stabilito la mia opinione che anche se il Prodotto è 'complesso e adattivo' ed è la soluzione perfetta per Scrum, limitando il team a organizzarsi solo all'interno dei confini si rischia un tetto di vetro di progresso. Il motivo per cui penso questo (la mia opinione probabilmente galleggerà come una piuma al vento su questo argomento) è perché considero "seguire Scrum" nel senso semplicemente, 'rendi empirico il tuo processo'. Se le prove suggeriscono che un team può migliorare l'applicazione Scrum nel proprio dominio... dovrebbero fidarsi del loro empirismo e adattarsi?

Andando avanti, se il mio team fosse: fornire costantemente incrementi potenzialmente rilasciabili; migliorare costantemente la qualità e i processi; vivere i 5 valori di Scrum (pur rimanendo empirici) e ha detto, 'Sappiamo che X è al di fuori del framework Scrum, ma pensiamo che ci renderà migliori', proverei a ricordare loro i confini del quadro? Il vecchio me lo avrebbe sicuramente fatto, e penso che lo farei ancora adesso. Ma proverei a convincerli a seguire l'applicazione Scrum da manuale anche se pensano di poter 'Trascendere'? Probabilmente no.

All'inizio di questo blog ho detto che lo scopo di scrivere questo era per farmi riflettere. E io ho. La domanda che ho posto al mio collega più anziano era errata. Scrum non è l'ostacolo, infatti il framework ci dice chiaramente cosa fare quando hai impostato il tuo lavoro su Done, 'ispezionare e adattare'.

Mi piacerebbe paragonare i miei pensieri su questo argomento a un "uovo di Pasqua" in un videogioco. Quando sei andato il più lontano possibile seguendo la trama (regole del framework Scrum; Shu), devi cercare altre opportunità per rendere la tua esperienza interessante (innovando e adattandoti con libertà; Ha). Alla fine, supererai il gioco e cercherai qualcosa di meglio (Ri).

Detto questo, vorrei cambiare la mia domanda per favore:

'C'è un punto in cui un team può superare il framework Scrum?'

….e penso che sia un argomento per un altro blog.