Membri dominanti del team in un team Scrum

Cosa faresti in una situazione in cui un membro del team tenta di assumersi responsabilità non inizialmente assegnate a lui ma allo Scrum Master?

Il team Scrum è auto-organizzato, quindi c'è spazio per qualcuno che è un po 'più dominante. Altri dovrebbero chiedergli le sue idee sui compiti a cui stanno lavorando, ma il suo dominio deve essere tenuto sotto controllo.

Cosa puoi fare:

• Motivare gli altri a essere indipendenti ma collaborativi: questo può essere realizzato meglio se si coopera con il loro manager e risorse umane che porranno loro alcune aspettative, che saranno valutate su base regolare.
• Durante stand-up, pianificazione e retrospettive; lascia parlare prima gli altri membri del team. Durante le revisioni, lascia che gli altri membri del team presentino storie utente che hanno implementato.
• Consenti ad altri di scegliere prima le attività in modo che lo sviluppatore dominante non possa solo scegliere le attività che vuole svolgere.
• Coinvolgere la programmazione di coppia per alcune attività in modo che il membro del team dominante stia collaborando con altri sviluppatori.
• Sii democratico - l'opinione di un membro del team non è sufficiente per apportare modifiche al processo - Scrum funzionerà solo se il team comunica in modo chiaro o ti bloccherai a vicenda.
• Se nulla di tutto ciò ti aiuta, dovresti parlare con il membro del team dominante e spiegargli la situazione - ma attenzione, non c'è nessun team leader in Scrum per un motivo. Se hai il supporto della direzione, potresti anche minacciare la sua stabilità lavorativa, ma questa dovrebbe essere l'ultima opzione.

Se il membro del team dominante non vuole perdere il dominio e i membri del team passivo non vogliono essere più attivi, avrai bisogno del supporto del loro manager e delle risorse umane. Questo potrebbe essere un problema se il processo Scrum non è incoraggiato dalla direzione.

Presumibilmente, il motivo di questa domanda è perché ritieni che la squadra sia in qualche modo poco performante a causa di questa persona dominante. Forse perché il resto della squadra non contribuisce al 100% perché, beh, qual è il punto?

Come manager, se lo sei, è tua responsabilità assicurarti che tutti i tuoi dipendenti comprendano quali sono i loro ruoli. In particolare, cosa ci si aspetta da loro e come verranno valutati. Come membro del team di un team Scrum, ogni persona è personalmente responsabile del successo del team. Quindi questo membro del team dominante deve sapere che stanno fallendo in quella responsabilità e sarà valutato di conseguenza.

Il feedback è un punto chiave. Se c'è una riunione di gruppo e questa persona domina la discussione, impone i suoi progetti e il suo approccio al resto della squadra e li spinge in ruoli passivi, allora gli deve essere detto, senza mezzi termini e privatamente, che non riesce a soddisfare i requisiti del ruolo. Se lo noti sottolineando subdolamente solo i suoi risultati personali, allora deve essere chiamato su di esso, e fatto capire che i risultati personali sono valutati molto, molto meno che aiutare la squadra a ottenere un risultato di gruppo.

Tutto ciò è difficile, ma è a questo che servono manager e Scrum Masters.

C'è un altro modo possibile per farlo. Trasformalo in un problema di squadra. Chiamali insieme e dì loro che stanno ottenendo risultati scarsi ed ecco perché. Chiedi loro di trovare una soluzione. Potresti essere sorpreso.

Perché non chiedere allo sviluppatore alpha la sua opinione. È del tutto possibile che non abbia idea dell'effetto che sta avendo. Prendilo da parte e digli cosa ne pensi. Potresti persino approfondire la discussione di "hey sei il nostro sviluppatore principale, ma dobbiamo portare queste persone al tuo livello, ho bisogno del tuo aiuto per capire come possiamo farlo?". Trasforma il suo dominio in una risorsa. Vedi se riesce a vedere i modi per farlo.

Se è misurato su quanto bene supporta la sua squadra e li porta al suo livello, allora avrà più motivazione per farlo.

Implichi che in realtà non sta lavorando nell'interesse della squadra (la mia ipotesi), cioè è in qualche modo malvagio, quindi sì, rimuovilo. Ma un uomo saggio una volta mi disse: Non assumere cattiva volontà, quando l'incompetenza o la semplice ignoranza sono più probabili.

Sembra che cerchi di essere lo Scrum Master.

Chiarisci le tue posizioni e agisci di conseguenza.

Il ruolo dello Scrum Master è quello di abilitare lo spirito di squadra. Se non riesci a far diventare questa e l'unica persona un giocatore di squadra, rimuovilo dalla squadra .

Nota rapida: lo sviluppatore dominante non è più problematico del tuo sviluppatore passivo.

attualmente la pianificazione dello sprint è un ruolo che ruota all'interno del team

La pianificazione dello sprint dovrebbe coinvolgere l'intero team, non essere consegnato a una persona alla volta. A meno che non ci sia una buona ragione per questo, vedo questo come un grave problema.

Se quello che stai dicendo è vero e obiettivo, hai un grosso problema a portata di mano: le persone che non partecipano e il "Dominatore" che impedisce un processo veramente agile. Come maestro Srum sta a te agire. Forse vorresti prendere il tuo project manager in confidenza con questa situazione.

Molte squadre si allontanano dal nucleo dell'agile ed è tuo compito riportarle indietro. Devi insegnare e reinserire valori agili nella squadra. In effetti, dovresti costantemente insegnare valori agili. Tieni la tua visione agile, rendila chiara e potente. Mostra loro il tuo impegno per "agile fatto bene".

Per fare questo, guidali attraverso il manifesto agile e i valori Scrum. Chiedi loro cosa significa per loro la collaborazione e perché è importante. Chiedi loro il ruolo della fiducia nell'agile. Questo è un ottimo momento per parlare del perché non esiste un ruolo di guida del team e nessun ruolo di project manager in Scrum e che è responsabilità di tutto il team creare un software eccellente, non l'individuo.

Pianifica un'intera sessione retrospettiva attorno a questo. Fai in modo che si impegnino su alcuni valori e seguano la prossima retrospettiva. Non puntare le dita, usa metodi neutri.

Introdurre metodi che costringano gli altri membri a dichiarare le proprie opinioni in modo sicuro. Qualcosa di semplice come il pugno di cinque è ottimo per far sentire le voci silenziose nella squadra. È dolorosamente ovvio che la squadra non è d'accordo con il ragazzo dominante. Planning Poker funziona bene, ma la chiave è non permettere alcuna discussione prima che le carte vengano mostrate. Tutto ciò che aiuta a far sentire gli altri senza iniziare conflitti è utile.

Se va bene, sei pronto. Altrimenti, parlagli del problema. Usa il coaching e poni potenti domande che possono aiutarlo a capire chiaramente il problema. Cerca di arrivare alla causa principale per cui ha assunto il ruolo dominante. Forse gli manca la fiducia nella squadra (perché?) E forse sente di essere responsabile del successo (perché?). Ho il sospetto che questo ruolo non sia qualcosa che vuole e molto probabilmente vorrebbe che cambi. Egli può venire intorno e realizzarlo.

Forse lo sviluppatore "dominante" è premiato dalla sua prestazione individuale piuttosto che dai risultati di squadra?

In passato mi sono assicurato che anche le persone molto vocali e con idee chiare venissero premiate (attraverso i loro obiettivi) promuovendo altri contributi.

In generale, penso che sia una cattiva idea premiare i membri della mischia solidamente sul loro contributo individuale piuttosto che sui risultati del team.

Potresti anche provare a fare un round di feedback a 360 nel tuo team per tutti i membri del team, solo se pensi che gli altri membri del team saranno sinceri nei loro commenti.

Proponi di diventare lo Scrum Master per lo sprint successivo.

Le persone disposte ad assumersi le responsabilità non sono un problema (purché non vogliano monopolio su di loro), è esattamente ciò che stiamo cercando di raggiungere con l'auto-organizzazione.

A proposito, le squadre con un ruolo di scrum master rotante non sono rare.

L'unico compito del maestro Scrum è assicurarsi che tutti rispettino le regole del libro Scrum. Se i maestri non scrum lo facessero da soli senza interferenze con il maestro Scrum, ciò dimostrerebbe che sei in ottima forma (Scrum-)! Meno deve fare lo Scrum Master, più cattiva e snella è la tua squadra dal punto di vista Scrum. Alla fine il ruolo di Scrum Master potrebbe / dovrebbe essere eliminato, è lì per iniziare e insegnarti Scrum.

Ancora una volta, il master Scrum non partecipa al processo di sviluppo. Dovrebbe assicurarsi che tutte le parti interessate comunichino in tempo utile le cose giuste, conosce Scrum e fornisce assistenza facendo Scrum, non è un product owner o project leader. Se provi qualcosa di diverso, potresti non fare Scrum con spirito agile. Ovviamente, in contesti più piccoli, Scrum Master potrebbe essere un ruolo giocato da uno dei membri del team o dei portatori di interessi. Quindi è solo un berretto che si indossa quando è il momento delle formalità. Non confonderlo con un ruolo di leadership, è un ruolo di orientamento.

Abbraccia l'individualismo e le prestazioni individuali, ma cerca anche di autorizzare gli individui passivi a diventare più partecipativi.

La mia esperienza dice che sebbene possano sembrare simili a prima vista, il comunismo e l'agile non sono gli stessi. Agile non mira a una società (squadra) senza classe ma a software che funziona.

Cerca di far capire al tuo sviluppatore alfa che potrebbe aiutarti a sviluppare le altre abilità chiedendo e istruendo, piuttosto che rispondere sempre prima e raggiungere risultati individuali. Sicuramente il tuo sviluppatore alpha è uno che si preoccupa per il buon software, ed è qualcosa che non puoi permetterti di perdere.