Processo decisionale all'interno di un team Scrum

Hai ragione quando dici:

1. È una decisione per il team di Scrum. E
2. Se lo Scrum Team non è d'accordo su un approccio, lo Scrum Master potrebbe facilitare un processo per aiutare il team a decidere.

Successivamente, se non è possibile raggiungere un consenso, lo Scrum Team ha effettivamente deciso di non decidere. Questa è una disfunzione che lo Scrum Team deve affrontare.

Lo Scrum Master dovrebbe mai decidere per il team (e non esiste un System Architect o Functional Manager in Scrum).

Lo Scrum Team deve risolvere la situazione da soli. Come Scrum Master, potrei incoraggiarli a provare un approccio per uno Sprint, e l'altro approccio per un altro Sprint, e quindi rivedere alla Sprint Retrospective. Ispezionare, adattare e andare avanti.

La tua domanda è esattamente la ragione per cui credo che solo perché tu (provi a) praticare Scrum o altre forme di Agile, ciò non significa che non ci dovrebbe essere un capo tecnico del team (aka benevolo dittatore) sul progetto .

Nella mia esperienza passata, abbiamo avuto un progetto, in cui il management è venuto giù e ha semplicemente dichiarato "non più gestione, nessuna gerarchia, la squadra è responsabile." Abbiamo avuto un numero di voci forti (alcune delle quali provenivano da ragazzi con solo 1 anno di esperienza nel progetto e nella lingua in cui si trovavano) su una squadra relativamente grande e la maggior parte degli incontri degenerati in argomenti, alcuni dei quali erano per ragioni piuttosto sciocche. (puoi immaginare una discussione di un'ora e mezza se la convenzione di denominazione dei progetti di test unitari dovrebbe essere test_ [nome progetto] o [nome progetto] _test o ....)

Quindi, rivedendo con la direzione come questa struttura del team non ha funzionato per noi, la mia proposta è che alcune gerarchie non sono una brutta cosa. Per il prossimo progetto, mi ha dato l'etichetta di un lead di design (con poteri fondamentalmente dittatoriali) e in un anno e mezzo che ci ha portato a completare la prossima release, penso che ho dovuto esercitare quei poteri solo poche volte e solo verso l'inizio del progetto.

Il mio ruolo come capo del design e uno dei membri di scrum era di far parte del team. Abbiamo ancora avuto discussioni e ho accolto favorevolmente / incoraggiato. Quindi in realtà ho dovuto intervenire solo poche volte quando non è stato possibile raggiungere un consenso. E penso perché i nostri incontri sono rimasti produttivi e non c'è stato nessun urlo o discussione al punto in cui metà della squadra vuole solo andarsene, nel tempo siamo diventati più allineati nella stessa pagina dove la necessità di quei poteri tipo dittatoriale per lo più andato via.

L'altra cosa che ho aiutato è stata quella di dividere il grande team di sviluppo in squadre più piccole di 3-5 persone, in modo che quelle voci forti avessero ciascuna la possibilità di condurre naturalmente senza scavalcarsi l'una sull'altra.

Queste sono le mie opinioni soggettive:

1: una decisione del team non deve essere basata sul consensus. Può infatti essere un voto a maggioranza, la scelta di un rappresentante eletto o qualcos'altro. Ma la squadra dovrebbe in qualche modo essere d'accordo, sì. Considerando chi dovrebbe facilitare questo ci porta direttamente sul numero di risposta ...

2: ho incontrato più volte situazioni in cui l'incapacità di risolvere le controversie si è rivelata problematica. In questi casi, avere qualcuno lì per risolvere la disputa aiuta davvero, anche se la risoluzione richiede solo una decisione casuale. Secondo la mia esperienza, funziona bene se il team leader o il capo tecnico assume questo ruolo.

In teoria si potrebbe probabilmente anche adottare una sorta di politica "rock, paper, scissors" per risolvere le controversie, ma ciò richiederebbe membri del team non ostinati e di mentalità abbastanza aperta. Potrebbe funzionare se sei seduto su un gruppo di persone esperte o persone che sono molto d'accordo.