Squadra Scrum con competenza

Abbraccia questo ... vedi, Agile NON significa che i modi di lavoro prescritti sono ciò che hai da fare. Significa che puoi decidere cosa funziona per te e fare esattamente quello.

Ora sono sicuro che, dato quel consiglio, il tuo team diventerà immediatamente operativo con i ragazzi Cobol che fanno le loro cose e comunicano con il ragazzo di .NET che farà il suo dovere. Speriamo che saranno abbastanza interessati a raccogliere alcune indicazioni per essere in grado di orientarsi tra le diverse tecnologie, ma ciò non significa che tutti debbano improvvisamente diventare ruoli multi-specializzati e scambiati ogni giorno. Non mi sembra che la pila di abilità sia rotta.

Assicurati che il team si trovi in un ambiente "black box" in cui i gestori esterni non riescono a vedere cosa o come fanno ciò che fanno. Assicurati solo che il team soddisfi i requisiti e produca software regolarmente, in modo che i gestori possano vedere i progressi, ma altrimenti lasciarli soli e lasciarli andare avanti, a loro scelta. Quel è il vero significato di agile, indipendentemente da ciò che hai letto in alcuni manuali di Scrum bu ****.

Se hai bisogno di un backup su questo, prendi i libri di cristallo di Alistair Cockburn - ha inventato parte Agile, sa di cosa si tratta. Quello che ho detto sopra è un consiglio che gli è stato tolto.

Per capire come affrontare il problema, devi prima capire dai tuoi superiori che obiettivo finale è avere un team Agile / Scrum interfunzionale. Una volta che lo sai e comprendi il punto di vista del business, oltre a comprendere la cultura dell'azienda e gli obiettivi dei singoli membri del team, puoi iniziare ad affrontare il problema.

I set di abilità funzionali trasversali tra una squadra sono l'obiettivo desiderato, tuttavia assumere una nuova squadra non è una buona opzione. Anche se potessi trovare un numero di sviluppatori .NET / Cobol esperti in entrambe le tecnologie, sarebbero costosi e rari.

L'opzione migliore è investire nella formazione della tua squadra. A seconda della cultura dell'azienda e della tua regione, questa potrebbe anche essere un'opzione poco attraente per l'azienda se, in genere, gli sviluppatori della tua zona hanno un mandato breve e sono costantemente impegnati in attività. Tuttavia, con l'obiettivo dichiarato di un team interfunzionale con stack tecnologici così disparati, necessari per il seguente progetto, è purtroppo l'unica via data all'assoluto che la squadra deve essere completamente agile in Cross Functional.

Quando valuti le storie degli utenti, fai sapere che qualsiasi storia utente può essere assegnata a una determinata risorsa tecnica e che se a uno sviluppatore Cobol viene fornita una storia utente principalmente .NET che uno sviluppatore .NET è obbligato a fornire una guida e direzione allo sviluppatore Cobol. Potrebbe essere una storia di 1 punto per lo sviluppo di .NET ma una storia di 3 punti per lo sviluppo di Cobol. È importante tenere presente che ci sono più sviluppatori Cobol che sviluppatori .NET, quindi lo sviluppatore .NET avrà meno tempo a disposizione per l'orientamento e la formazione, rendendo le attività .NET molto più costose. La paia di programmazione è uno strumento utile mentre lo fai, quindi incoraggia questo.

I vantaggi sono che questo investimento nella tua squadra si tradurrà in una maggiore funzionalità trasversale a quella in cui questo non è più un problema. Tuttavia, il grande avvertimento è che la stima della storia di un utente potrebbe dipendere da una o più persone, il che renderà prive di significato diverse metriche di gestione dei progetti. Sarà più difficile valutare un contributo individuale a un progetto se sembra che non stiano producendo molto, ma forse stanno imparando moltissimo lungo la strada.

Da una nota a margine, hai detto che il team ha uno Scrum Master ma sei chiamato per farlo? In un tipico team Scrum questo tipo di compito è esattamente il ruolo dello Scrum Master.

Voglio solo dire che le persone generalmente si sentono "forzate" in Scrum quando Scrum non viene eseguito correttamente. Gli errori più comuni sono:

1. Uno "Scrum Master" che è davvero un PM. Lo Scrum Master è un ruolo passivo. Il suo compito è quello di rimuovere gli impedimenti dal percorso del team e assicurarsi che il team aderisca alla cerimonia di Scrum (Sprint Planning, Dailies, Sprint Review e Retrospective). Questo è tutto. I team di sviluppo decidono su cosa stanno andando a lavorare e su come lo faranno. Se lo Scrum Master sta assegnando compiti o dettando lavoro, stai sbagliando, e il tuo team di sviluppo penserà che tutta questa faccenda di Scrum faccia schifo.

2. I quotidiani dovrebbero essere coinvolgenti e brevi. Nulla ucciderà il morale del team di sviluppo più rapidamente delle tre domande spesso consigliate: cosa hai fatto oggi ?, cosa fai domani? Hai qualche impedimento. A cui quasi invariabilmente riceverai le seguenti risposte: incoerenza, ciò che pensano di voler sentire e "No".

   Invece, tira su la tua sprint board e passa attraverso i PBI uno per uno. Chiedi cose come "Qualcuno ha mai lavorato su questo PBI?" Se è così, allora "Che cosa hai fatto?" e "Quanto è lungo questo compito? Può essere spostato a fare o quanta fatica pensi che sia rimasto?". Infine, "C'è qualcosa che ci impedisce di ottenere questo risultato?". Questa è una sorta di variazione delle Tre domande, ma è meglio in due modi: non è conflittuale e coinvolge l'intero team, non solo un singolo individuo. Riguarda cosa ha fatto il team, non cosa ha tu fatto. I quotidiani sono solo per avere un'idea di come lo sprint sta progredendo e per individuare i problemi in anticipo se ce ne sono. Questo è tutto. Vuoi entrare e uscire.

3. Gli sprint non sono basati sulla velocità, o la velocità viene giocata per adattarsi al lavoro che l'OP desidera eseguire. Questo è sempre scioccante per me ed è molto più comune di quanto si possa immaginare. La velocità è una misura di ciò che la squadra può compiere in ogni dato sprint. Pertanto, l'unica volta che dovrebbe cambiare è se ci sono ore ridotte a causa di ferie o giorni di riposo o se si assume o si perde un membro del team. In altre parole, dovrebbe cambiare solo quando cambia la capacità effettiva della tua squadra. Dopo tre o quattro buoni sprint, avresti dovuto affinare la tua velocità e dovrebbe essere uno sprint abbastanza buono per lo sprint. Se la tua velocità è ovunque, stai valutando male, cercando di fare più lavoro di quello che il team può gestire, o entrambi. Il risultato in entrambi i casi diminuirà il morale della squadra, in quanto sentiranno di aver fallito o saranno sovraccarichi di lavoro e potenzialmente esauriti. Gli sprint dovrebbero essere facili e naturali. Una volta che una squadra entra nel flusso, può stimare con precisione e conosce la velocità, dovrebbe sentirsi come se avessi il giusto tempo per fare il lavoro nello sprint. Nessuno è annoiato e nessuno si sente oberato di lavoro o stressato per fare le cose.

4. Prendere impegni anziché previsioni. Originariamente Scrum ha parlato del lavoro svolto come parte di uno sprint come "impegni", ma in seguito ha rivisto il linguaggio a "previsioni". Ciò è stato fatto per una buona ragione in quanto la connotazione di ogni parola è molto diversa. Se ti perdi un impegno hai fallito. Se ti manca una previsione, provi a fare meglio la prossima volta. Quando il team si imbarca in uno sprint, c'è tutta l'intenzione di fare tutto alla fine dello sprint, ma poi la vita alza la sua brutta testa. Le cose accadono, e sia gli stakeholder che del team Scrum devono capirlo. Se la squadra non fa finire tutti i PBI in uno sprint, dovresti discuterne nella retrospettiva, ma non è un grosso problema. La mancanza del tuo obiettivo ti aiuta effettivamente a valutare meglio le tue capacità e a impostare un target più accurato la prossima volta. Punire il tuo team di sviluppo ucciderà solo il morale che potresti aver lasciato.