Scettico in una squadra di Scrum

Di fronte a un estremo scetticismo, provo alcune cose:

1.) Dimostro tecniche come TDD, Distribuzione continua, Programmazione di coppie, Raccolta di requisiti con i tuoi utenti, brevi iterazioni ecc. Io non chiama quelle tecniche Agile o arpa su Agile Manifesto (mi occupo di Software Artigianato - ma questo è diverso; p). Semplicemente mostro ai membri del team strumenti e tecniche utili che semplificano le loro vite. Tendono a salire sul carrozzone Agile una volta che vedono i benefici giorno per giorno.

2.) Non scambio immediatamente con una metodologia SCRUM completa (o di altro tipo). È sempre meglio introdurre piccoli aspetti di Agile alla volta.

3.) Sono d'accordo con gli scettici (ad un certo punto). Agile non è un proiettile d'argento e SCRUM, Kanban, Lean ecc. Non sono nemmeno una pallottola d'argento. Invece lavoro con loro per vedere quali aspetti potrebbero avvantaggiarli immediatamente (un server CI è un gioco da ragazzi di solito) e poi provo il resto "Diamo uno stand-up per una settimana e poi lo rivediamo".

Come ogni metodologia, SCRUM e altri devono effettivamente lavorare con il team e l'organizzazione, non alienarli.

Quindi per arrivare direttamente alla tua domanda. Sollevalo con la squadra:

"Anch'io sono un po 'scettico riguardo agli stand-up, ma penso che come squadra dovremmo dare il via a una settimana (senza scuse!) e poi rivederlo per vedere se ha funzionato per noi. Cosa pensa la gente? "

Un caso tipico di Scrum erroneamente implementato

Scrum è stato imposto al team. La (intera) squadra non l'ha scelta.

Quando vuoi implementarlo, devi avere il pieno supporto sia del team che della gestione, oppure non funzionerà affatto.

Resistance to change is your enemy here.

Ti consiglio caldamente di ricominciare e presentare Scrum al team e fargli fare domande.

Se non riesci a vendere l'idea, non provare a forzarla usando una metodologia che non vogliono. Faranno di tutto per sabotarlo. Venire tardi in stand-up giornalieri è uno dei comportamenti che otterrai.

Tieni presente che Scrum potrebbe non essere consigliabile per la tua azienda. Le uniche persone che possono rispondere a questa domanda sono le persone che lavorano alla base. Il team .

È possibile che il concetto di riunioni giornaliere non si applichi molto bene a ciò che una persona sta facendo. Quelle riunioni non sono gratuite.

Se quello che stai facendo richiede molta concentrazione a lungo termine, come la matematica pesante, gli incontri possono scoraggiarti ed essere frustrante. Lavoro con una persona del genere, che preferisce incontrarsi su base settimanale, il che è perfettamente ragionevole.

A dire la verità, se fossi nel tuo team di programmazione, probabilmente sarei lo scettico! Ho visto una lunga serie di metodologie che avrebbero dovuto rivoluzionare le cose e far arrivare i progetti in tempo, nel budget e senza errori. Questo è solo l'ultimo. Perché dovrei credere all'olio di serpente? 10 anni fa le stesse persone stavano fustigando qualcos'altro, tra qualche anno qualcosa di nuovo arriverà. Non fraintendermi penso che alcune delle nuove metodologie portino alcune idee utili. Sfortunatamente portano anche un sacco di dogmi e idee stupide.

Importa davvero se non salirà a bordo? Assegnagli alcuni compiti di programmazione e fagli fare come vuole. Se il suo lavoro è soddisfacente, lascia che sia. Se il suo lavoro non è soddisfacente, sostituiscilo. Perché è così importante per le persone seguire la mischia?

Nel corso degli anni ho visto molti buoni programmatori smettere o arrabbiarsi perché il loro manager continua a introdurre nuove metodologie. Vogliono solo programmare e portare a termine il lavoro. Fidati di me tra qualche anno, maledirai la mischia e salti su qualunque sia l'ultima moda.

Se stai facendo agile, dovresti avere un backlog da cui stai lavorando. Usa la mischia per distribuire i compiti dal backlog.

Le scelte (migliori) assegnazioni vengono raccolte prima all'inizio della riunione. Quando arrivi tardi arriva solo a dargli quello che rimane per un giorno.

Non importa se è un dono di Dio alla programmazione, ottiene il compito schifoso che nessun altro voleva. Se prova a rinforzare un altro compito o a lavorare su qualcos'altro, la squadra nel suo insieme ha bisogno di appoggiarsi a lui e costringerlo a lavorare solo sul suo compito "scelto". Probabilmente dovresti avere un master che può rifiutare le sue modifiche se non sta lavorando al lavoro scelto.

Anche il team dovrebbe stabilire obiettivi e potenzialmente un risarcimento. Puoi votare come una squadra per non premiare coloro che non partecipano. Ciò varia in base alla quantità di proprietà che la tua gestione ha dato al tuo team agile. Ricorda la gestione di coloro che stanno facendo del male alla squadra e impedendo al team di avere successo.

Ricordagli che se si presenta in tempo può partecipare al processo.

Le squadre di Scrum dovrebbero essere auto-organizzanti. Scrum funziona anche implementando la massima trasparenza in tutto.

Quindi la risposta ovvia è che lo Scrum Master chiama una riunione, spiega il problema (ma non illuderti, tutti nel team sanno già esattamente qual è il problema) e poi dice loro che hanno 1 ora per capire cosa hanno intenzione di fare al riguardo. Quindi si siede in un angolo e tiene la bocca chiusa.

Ovviamente, questa è una squadra nuova per Scrum. Quindi la chiave è che lo Scrum Master deve accettare qualsiasi risposta il team si presenti. Se li annulla, o impone le sue idee sulla soluzione, distruggerà la fiducia che la squadra ha bisogno di costruire con lui che gli è permesso di auto-organizzarsi. È possibile che la squadra decida di non fare nulla.

In ogni caso, il problema dovrebbe essere esaminato alla Sprint Retrospective e l'efficacia della soluzione che hanno trovato può essere discussa.

Evitare "conflitti di squadra" non dovrebbe nemmeno essere un fattore del tutto.

Spara al compagno di squadra, quindi non causerà polemiche all'interno del team.

Esplora i tuoi lavori più vecchi e scopri più esempi di come l'approccio di caduta dell'acqua ti ha lasciato cadere molte volte in passato. Quindi presenta i casi al tuo compagno di squadra. Con un assaggio di buon senso, vedrà la luce.

La programmazione è un'attività di precisione in modo che un individuo raro rimanga irriconoscibile ai fatti concreti. Almeno, in teoria.

Chi ha preso la decisione di cambiare e perché? Dove quegli scettici in merito alla decisione o la decisione li ha semplicemente abbandonati?

Sei troppo rigido e / o veloce nell'implementazione dei tuoi nuovi metodi? Hai messo fuori prodotti buoni (non necessariamente perfetti) usando i tuoi vecchi metodi? Hai dimostrato agli scettici in che modo potranno beneficiarli? Puoi dimostrarlo? Chi ha "visto la luce" ha dimostrato agli scettici come ne traggono beneficio, il team e l'azienda?

Probabilmente stai chiedendo loro di accettare tutto solo sulla parola dei credenti. Più probabilmente questi scettici hanno ripreso nuove metodologie prima e nessun beneficio è mai stato realizzato.

Forse potresti fare un progetto o due con solo i credenti che ci lavorano usando le tue nuove procedure. Prendi misure reali e dimostra agli scettici i veri benefici. Forse potrebbe anche creare una piccola competizione tra gli scettici e i loro vecchi modi, i credenti e i loro nuovi modi.

Certo che cosa fai se gli scettici vincono?

Avere una riunione di gruppo per discutere e capire perché la tua azienda è passata a SCRUM e far capire a tutti cosa pensa di SCRUM potrebbe aggiungere valore all'attuale modalità operativa. A volte le aziende fanno scambi interrotti (sono stato in riunioni di mischia in cui nessuno ascolta davvero e tutti si limitano a snocciolare quello che hanno fatto ieri e se ne va. Queste squadre di solito raggiungono un equilibrio come: "Non metterò in dubbio te e tu non scherzi con me "e vai a passeggio, è solo una perdita di tempo), quindi prendi ciò che è meglio per te.

I veterani di solito hanno molta resistenza a tutto ciò che potrebbe cambiare il loro attuale stile di lavoro, quindi devi assicurarti che ci siano abbastanza carote per farli scendere dalla loro inerzia. In questo caso, avrei un 1: 1 con quella persona o renderlo il supervisore della mischia :). Una volta date loro la responsabilità, troveranno la pace con essa o la elimineranno completamente perché non aggiungono valore. Entrambi sono vinti.