Scrum: gestire la mancanza di motivazione

In base a ciò , "Scrum si affida fortemente a team altamente motivati, strettamente collaborativi, interfunzionali e auto-organizzati". Quindi, come gestite i colleghi che potrebbero non essere così motivati ​​ad assumere la proprietà del codice? Come si ottiene qualcuno interessato a diventare proprietario?

Non so se questo è il problema del tuo team, ma è stato sicuramente per noi quando abbiamo introdotto per la prima volta la mischia. Il nostro management è venuto da noi un giorno e ha detto, da ora in poi non lavorerai in singoli silos. Invece, lavorerai come una mischia. Ecco un sacco di nuovi processi che tutti devono seguire e seguirli.

La chiave è che non sono mai venuti da noi, gli sviluppatori, e hanno chiesto, come volete lavorare? cosa ti renderà più felice? più efficiente?. Quindi quello che ho sentito è stato: "non possiedi più alcun codice. Qualunque cosa tu scriva, verrà calpestato (sai, proprietà della squadra). Non ti sposterai o alzerai un dito perché ora gestiremo il tuo orario di ora in ora". Oh e ora hai uno stand noioso di 15 minuti ogni giorno in cui le persone discuteranno di cose che non ti interessano e di solito ci vorranno 30 minuti e poi ogni due settimane avrà una noiosa riunione di pianificazione di 4 ore che sicuramente farà schifo tutta la vita fuori di te.

In realtà questo non è Agile o Scrum, si sta solo spostando da uno stile di gestione a uno stile diverso, dove tutto è ancora controllato centralmente, e non solo mi ha risucchiato tutta la vita, ma mi ha anche dato un sacco di libero tempo di aggiornare il mio curriculum.

Negli ultimi dodici mesi, dopo aver fatto pressioni numerose volte affinché il nostro team manager provasse qualcosa di diverso, mi ha davvero accettato i miei suggerimenti e penso che abbiamo avuto un anno di grande successo.

Credo che il cambiamento chiave per noi sia stato quello di dare agli sviluppatori molta più voce e libertà nella scelta di come vogliamo lavorare. Poche cose che abbiamo fatto:

1. Suddividi il grande team di sviluppo "agile" in 3 piccoli team in modo che ciascuno abbia solo 3-4 sviluppatori. Questo rende tutti coinvolti e gli individui non vengono soffocati.
2. Assicurati che tutti nella stessa squadra lavorino nella stessa area funzionale in modo che le persone si preoccupino di ciò di cui gli altri stanno parlando in stand up e pianificazioni di iterazione.
3. Invece di scegliere semplicemente chi lavora su cosa e assegnare storie / compiti, abbiamo escogitato un arretrato e il team stesso ha avuto molto da dire su come il lavoro è diviso.
4. Poiché avevamo molti nuovi membri, abbiamo iniziato con un sistema di silos in cui ogni persona possiede un'area di responsabilità primaria. Ciò ha permesso alle nuove persone di concentrarsi su un'area più piccola di un prodotto sconosciuto e di avere anche la sensazione più rapida di non giocare nella sandbox di qualcun altro. Ma dopo 6-8 mesi dal programma, quelle aree hanno iniziato a mutare man mano che i confini diventavano più grigi. Ora i ragazzi, nei team in cui faccio parte, sono abbastanza a loro agio nel penetrare nel codice degli altri o nel far lavorare altri sviluppatori nei loro.
5. Le revisioni del codice di tutti gli invii erano fondamentali (e questa è stata la prima cosa che è stata ignorata quando abbiamo fatto Scrum per la prima volta):
   • Trasferimento di conoscenze in termini di tecniche / metodi di programmazione
   • È stato fantastico per gli altri imparare il codice che altrimenti non avrebbero visto
   • Il tuo team ha la possibilità di comunicare e socializzare che migliora le dinamiche del team
   • E immagino che le recensioni di codice cattureranno un bug o due, ma vedo il loro valore principalmente negli aspetti sopra.
6. La direzione deve ascoltare la squadra. Se il team dice che qualcosa non funziona o deve essere cambiato, e semplicemente lo ignorano, i membri del team semplicemente controlleranno e lasceranno che la direzione gestisca il progetto. Se vuoi che le persone siano motivate, hanno bisogno di essere investite e saranno investite solo se stanno facendo ciò che credono giusto, non ciò che viene loro detto di fare dall'alto.

Ci sono molte ragioni per la mancanza di motivazione, ma probabilmente il più comune non è la sensazione di avere voce in capitolo. Quando il nostro team ha iniziato a fare scrum ho notato che le persone meno motivate su scrum si sono voltate dopo aver visto i loro suggerimenti dalle retrospettive implementate.

Un sacco di problemi minori può aggiungere per essere demotivante. Ad esempio, una cosa che è emersa la scorsa settimana è stata un membro del team a cui non piacevano le riunioni delle 4:00. È facilmente risolvibile.

In altre parole, il modo migliore per scoprire cosa sta demotivando la tua squadra è chiedere loro.

Dando loro la proprietà individuale sul codice.

Molti negozi lavorano su un modello di "proprietà della squadra". Questo è ottimo per la collaborazione incrociata e la riduzione del rischio, ma non altrettanto per motivare le persone a essere personalmente responsabili. La proprietà del team può comportare un codice medio, poiché non esiste un incentivo alla proprietà individuale.

Soluzione: assegnare a ciascuna sezione del codice gli amministratori come amministratori di quella parte del codice, ma consentire l'accesso completo del team all'intera base di codice.

Vedi anche: /software//a/33464/1204