Scettico in una squadra di Scrum

La mia azienda è recentemente passata a un modo di lavorare Agile e come parte di esso abbiamo iniziato a utilizzare SCRUM. Mentre mi sento molto a mio agio con esso e sento che questo modo è superiore a quello tradizionale, alcuni dei miei compagni di squadra non condividono la stessa opinione. In realtà sono molto scettici su "tutta quella roba agile" e non la prendono sul serio. Ad esempio, uno dei compagni di squadra è sempre in ritardo sugli incontri e non gliene importa nulla. Il management IMO cerca di non accorgersene (forse perché è nuovo e ci vuole tempo perché le persone si abituino).

La mia domanda è: come affrontare questo problema senza sollevare un conflitto all'interno del team?

Di fronte a un estremo scetticismo, provo alcune cose:

1.) Dimostro tecniche come TDD, Implementazione continua, Programmazione di coppie, Riunione di requisiti con i tuoi utenti, brevi iterazioni, ecc. Non chiamo tali tecniche Agili o mi affido al Manifesto Agile (mi occupo di Artigianato software - ma è diverso; p). Mostro semplicemente ai membri del team strumenti e tecniche utili che semplificano la loro vita. Tendono a salire sul carro Agile una volta che ne vedono i benefici ogni giorno.

2.) Non passo immediatamente a una metodologia SCRUM (o altra) completa. È sempre meglio introdurre piccoli aspetti di Agile alla volta.

3.) Concordo con gli scettici (fino a un certo punto). Agile non è un proiettile d'argento e anche SCRUM, Kanban, Lean ecc. Non sono un proiettile d'argento. Invece lavoro con loro per vedere quali aspetti potrebbero avvantaggiarli immediatamente (di solito un server CI è un gioco da ragazzi) e poi provo il resto "Diamo una possibilità agli stand-up per una settimana e poi lo esaminiamo".

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 il team:

"Sono anche un po 'scettico riguardo agli stand-up, ma penso che come squadra dovremmo provarlo per 1 settimana (senza scuse!) E poi rivederlo per vedere se ha funzionato per noi. Cosa fanno le persone pensare?"

Un tipico caso di Scrum erroneamente implementato .

Scrum è stato imposto alla squadra. L'intero team non l'ha scelto.

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

La resistenza al cambiamento è il tuo nemico qui.

Consiglio vivamente di ricominciare da capo e presentare Scrum al team e lasciare che facciano domande.

Se non riesci a vendere l'idea, non provare a forzarli usando una metodologia che non vogliono. Faranno di tutto per sabotare. Arrivare tardi nelle alzate quotidiane è uno dei comportamenti che otterrai.

Si noti che Scrum potrebbe non essere consigliabile per la propria azienda. Le uniche persone che possono rispondere a questa domanda sono le persone che lavorano alla base. La squadra .

È possibile che il concetto di riunioni quotidiane 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, le riunioni possono dirottarti ed essere frustrante. Lavoro con qualcuno del genere, che preferisce incontrarsi su base settimanale, il che è perfettamente ragionevole.

A dire il vero, se fossi nel tuo team di programmazione, probabilmente sarei così scettico! Ho visto una lunga serie di metodologie che avrebbero dovuto rivoluzionare le cose e far sì che i progetti arrivassero 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 frustando qualcos'altro, tra qualche anno arriverà qualcosa di nuovo. Non fraintendetemi, penso che alcune delle nuove metodologie apportino idee utili. Sfortunatamente portano anche molti dogmi e idee stupide.

Importa davvero se non sale a bordo? Basta assegnargli alcune attività di programmazione e lasciarlo fare come vuole. Se il suo lavoro è soddisfacente, lascialo stare. Se il suo lavoro non è soddisfacente, sostituiscilo. Perché è così importante per le persone seguire la mischia?

Nel corso degli anni ho visto molti bravi programmatori smettere o infastidire 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 salterai sull'ultima moda.

Se stai agendo, dovresti avere un backlog da cui stai lavorando. Utilizzare la mischia per distribuire compiti dal backlog.

I compiti (migliori) scelti vengono scelti per primi all'inizio della riunione. Quando arriverai in ritardo, dagli solo ciò che resta del giorno.

Non importa se è un dono di Dio alla programmazione, ottiene il compito schifoso che nessun altro voleva. Se cerca di organizzare un altro compito o di lavorare su qualcos'altro, la squadra nel suo insieme deve appoggiarsi a lui e costringerlo a lavorare solo sul suo compito "scelto". Probabilmente dovresti avere un build build che possa rifiutare le sue modifiche se non sta lavorando all'opera scelta.

Inoltre, il team dovrebbe stabilire obiettivi e potenzialmente compensi. Puoi votare come 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 alla direzione di coloro che stanno ferendo la squadra e impedendo alla squadra di avere successo.

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

Le squadre di Scrum dovrebbero auto-organizzarsi. Scrum funziona anche implementando estrema trasparenza in tutto.

Quindi la risposta ovvia è che lo Scrum Master convoca una riunione, spiega il problema (ma non illuderti, tutti i membri del team sanno già esattamente quale sia il problema) e poi dice loro che hanno 1 ora per capire cosa lo faranno. 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 abbia trovato. Se li supera, o impone le proprie idee sulla soluzione, distruggerà la fiducia che la squadra ha bisogno di costruire con lui per autorizzarsi. È possibile che il team decida di non fare nulla.

In ogni caso, il problema dovrebbe essere esaminato alla Retrospettiva Sprint e può essere discussa l'efficacia di qualsiasi soluzione trovata.

Evitare il "conflitto di squadra" non dovrebbe nemmeno essere un fattore.

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

Sfoglia i tuoi lavori più vecchi, scopri più esempi di come l'approccio delle cascate ti ha deluso molte volte in passato. Quindi presenta i casi al tuo compagno di squadra. Con uno sguardo di buon senso, vedrà la luce.

La programmazione è un'attività di precisione, quindi un individuo raro non starebbe attento ai fatti concreti. Almeno, in teoria.

Chi ha preso la decisione di cambiare e perché? Dove si trovavano quegli scettici sulla decisione o la decisione era appena caduta su di loro?

Sei troppo rigido e / o veloce nella tua implementazione dei tuoi nuovi metodi? Hai prodotto buoni prodotti (non necessariamente perfetti) usando i tuoi vecchi metodi? Hai dimostrato agli scettici come ne trarranno beneficio? Puoi dimostrarlo? Quelli che hanno "visto la luce" hanno dimostrato agli scettici i vantaggi per loro, il team e l'azienda?

Probabilmente stai chiedendo loro di accettare tutto solo sulla parola dei credenti. Molto probabilmente questi scettici hanno adottato nuove metodologie prima e nessun beneficio mai realizzato.

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

Certamente allora cosa fai se gli scettici vincono?

Avere una riunione del team per discutere e capire perché la tua azienda è passata a SCRUM e indurre tutti a identificare ciò che pensano di SCRUM aggiungendo valore all'attuale modalità operativa. A volte le aziende fanno interruttori (sono stato in riunioni di mischia in cui nessuno ascolta davvero e tutti si limitano a scuotere quello che hanno fatto ieri e se ne vanno. Queste squadre di solito raggiungono un equilibrio come - "Non ti metterò in discussione e non farai casino con me "e ondeggiare lì. È 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 uscire dalla loro inerzia. In questo caso, avrei un 1: 1 con quella persona o lo renderei il maestro della mischia :). Una volta assegnate loro la responsabilità, troveranno pace con essa o elimineranno completamente perché non sta aggiungendo valore. Entrambi sono win win.