IT 
EN 
JA 
ES 
La prova tecnica
Negli ultimi cinque anni ho avuto una fantastica carriera come Scrum Master. Non faccio questa distinzione perché prima non mi piaceva essere uno Scrum Master, ma perché non ero affatto uno Scrum Master… ero un insegnante di Chimica. È solo di recente che ho esaminato questi due ruoli e ho individuato alcune somiglianze chiave (inclusa quella che gli adolescenti e gli sviluppatori di software non sono così diversi come potresti pensare!). Sono stato e sono tuttora un facilitatore, un manager, un levatore di impedimenti e un agente di cambiamento. Quindi, mi ha fatto pensare che, poiché questi due ruoli erano simili, alcune delle tecniche potrebbero essere riapplicate in un contesto diverso? A quanto pare, assolutamente!
Volevo scrivere alcune tecniche che usavo in una classe di studenti che ora uso in una sala riunioni di adulti. Quando ero coinvolto nella formazione delle persone per insegnare, "Creativity in the Classroom" era dove avresti trovato il mio nome nell'agenda della formazione. Per me, la formazione non riguarda idee concettuali, ma tecniche dure e veloci che puoi portare via e sfruttare domani. Questo è ciò su cui mi sono concentrato qui. Possono avere risultati a lungo termine, ma le pratiche sono facili e mi hanno dato grandi risultati. Nota, so che includono pratiche complementari a Scrum e che non esiste un tema coerente.
Gli studenti lavorano in coppia e danno feedback per aiutare il resto del gruppo -> Perfezionamento in anticipo
Buono per: avvicinare il team agli utenti e disaggregare il "comando centrale".
Prima di una sessione di perfezionamento del Product Backlog (o simile) chiedi agli sviluppatori di condividere uno o due PBI dal Product Backlog per perfezionare in coppia. Chiedi loro di interagire con gli utenti finali, il Product Owner e le parti interessate al fine di ottenere trasparenza sulla "domanda". La coppia scrive la descrizione in collaborazione con il Product Owner e può aggiungere criteri di test o qualsiasi altra cosa rilevante. In breve, richiedono tempo per comprendere i requisiti tecnici del PBI. Fare questo in anticipo ottiene alcune cose:
✔️ La conoscenza del lavoro imminente è condivisa tra gli sviluppatori. Tutti i membri sono concentrati sull'aiutare il resto della squadra e quindi genera più una sensazione di "una squadra".
✔️ Il dimensionamento è più fluido. Spesso gli sviluppatori pongono numerose domande tecniche al PO che fanno deragliare lo scopo del perfezionamento: trasparenza sul valore. Se alcuni degli sviluppatori sono già stati coinvolti nel dettaglio del PBI, possono "eliminare" le domande tecniche se non sono pertinenti.
✔️ La stima è più informata. C'è più fiducia nella stanza che le previsioni sono affidabili.
Condividere l'obiettivo di apprendimento all'inizio di un'unità -> Visualizzare uno Sprint Goal
Buono per: mostrare a tutti come contribuiscono al quadro generale dello Sprint.
Attacca il tuo Sprint Goal in alto. Questo è l'obiettivo e un singolo focus (mai sentito parlare di una piramide con due picchi?... no, una piramide, un focus, uno Sprint Goal).
I PBI che sono dipendenze si trovano al livello più basso perché devono essere eseguiti per primi. Sono il fondamento su cui la convalida del tuo Sprint Goal avrà successo o meno. Senza il fondamento, è molto improbabile che tu raggiunga il tuo obiettivo. I PBI che possono essere eseguiti una volta risolte le dipendenze sono il livello successivo.
✔️La piramide mostra come ogni PBI contribuisce al quadro più ampio.
✔️ Incoraggia il buy-in di tutti gli sviluppatori, anche quando stanno lavorando su qualcosa di "piccolo", perché possono capire perché ogni PBI è importante.
✔️Le parti interessate lo adorano perché è visivo.
✔️Puoi colorare i triangoli durante il Daily Scrum per mostrare i progressi o aggiungerli/rimuoverli secondo necessità.
È importante sottolineare che non rimanere bloccato su di esso rimanendo una forma piramidale. È una struttura per supportare una pianificazione trasparente, non solo per creare una bella immagine!
Risoluzione del comportamento -> Membro del team fittizio
Buono per: empatia e riconcentrazione del conflitto tra i team.
Gli Scrum Team sono composti da persone e quindi le cose possono diventare emotive. Probabilmente siamo stati tutti in una Sprint Retrospective quando le cose si sono ribaltate e forse hanno superato il limite del "personale". Prova a utilizzare un membro del team immaginario con una storia passata (il nostro è uno sviluppatore chiamato Jerry, è logico e sempre corretto). Se un conflitto sta sfuggendo di mano, fai sedere la squadra e pensa a come si sentirebbe Jerry.
✔️ I partecipanti smettono di pensare a come si sentono e iniziano a considerare come si comporta qualcun altro (empatia).
✔️ Rimuove l'aspetto personale del conflitto (de-escalation) e spesso consente una via da seguire.
Queste sono solo alcune cose che ho estratto direttamente dal mio repertorio di insegnamento e ce ne sono molte altre. Si concentrano sull'empowerment senza proprietà, sull'uguaglianza attraverso l'impegno e sulla leadership dall'interno.
Non sono andato troppo nei dettagli perché non credo sia necessario. Siete tutti praticanti con circostanze uniche, quindi prendete quello che vi piace, provate la Tecnica di Prova e, se non funziona, buttatela. Cerchiamo di essere empirici su di esso.