Scrum: gestione della mancanza di motivazione

Non so se questo è il problema della tua squadra, ma è stato sicuramente per noi quando abbiamo introdotto per la prima volta la mischia. La nostra direzione ci è venuta un giorno e ha detto che da ora in poi non lavorerai in singoli silos. Invece, lavorerai come una mischia. Ecco un mucchio di nuovi processi che devi seguire tutti 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 è che "non possiedi più alcun codice: qualsiasi cosa tu scriva, verrà calpestata (lo sai, proprietà della squadra). Non ti muoverai né alzerai un dito perché ora gestiremo il tuo tempo all'ora". Oh, e ora hai un noioso 15 minuti di stand up ogni giorno in cui le persone discuteranno di cose a cui non ti importa e di solito impiegheranno 30 minuti e poi ogni due settimane avranno un noioso e noioso incontro di pianificazione di 4 ore che è sicuro di succhiare tutta la vita fuori di te.

In realtà non si tratta di Agile o Scrum, si passa semplicemente da uno stile di gestione a uno stile diverso, in cui tutto è ancora controllato centralmente, e non solo ha fatto risucchiare tutta la vita da me, ma mi ha anche dato un sacco di tempo libero per aggiornare il mio curriculum.

Negli ultimi dodici mesi, dopo aver pressato numerose volte il nostro team manager per provare qualcosa di diverso, in realtà mi ha accolto con i miei suggerimenti, e penso che abbiamo avuto un anno di grande successo.

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

1. Rompi il grande team di sviluppo "agile" in 3 piccoli, in modo che ognuno abbia solo 3-4 sviluppatori. Ciò rende tutti impegnati e le persone non vengono soffocate.
2. Assicurati che tutti nello stesso team lavorino attorno alla stessa area funzionale in modo che le persone si preoccupino di ciò di cui parlano gli altri in situazioni di rialzo e pianificazione iterativa.
3. Invece di dirigere semplicemente a scegliere chi lavora su cosa e ad assegnare storie / attività, abbiamo trovato un backlog e il team stesso aveva molto da dire su come il lavoro è diviso.
4. Poiché avevamo molti nuovi membri, abbiamo iniziato con un sistema di silo 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 ha anche la sensazione più rapida che non stiano giocando nella sandbox di qualcun altro. Ma dopo 6-8 mesi nel programma, quelle aree hanno iniziato a trasformarsi man mano che i confini sono diventati più grigi. Ora i ragazzi, nei team in cui lavoro, sono abbastanza tranquilli che entrano nel codice di altri o che hanno altri sviluppatori che lavorano nel loro.
5. Le recensioni di codice di tutte le richieste erano fondamentali (e questa è stata la prima cosa che è stata ignorata quando abbiamo fatto Scrum per la prima volta):
   • Trasferimento di conoscenza in termini di tecniche / metodi di programmazione
   • È stato fantastico per gli altri imparare codice che altrimenti non avrebbero visto
   • Il tuo team ha la possibilità di comunicare e socializzare, migliorando le dinamiche di squadra
   • E immagino che le recensioni del codice cattureranno un bug o due, ma ne vedo il valore principalmente negli aspetti precedenti.
6. La gestione deve ascoltare la squadra. Se il team dice che qualcosa non funziona o ha bisogno di essere cambiato, e semplicemente lo ignorano, i membri del team semplicemente controllano e lasciano che la gestione si occupi del progetto. Se vuoi che le persone siano motivate, hanno bisogno di essere conferite e saranno acquisite solo se stanno facendo ciò che ritengono 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 sulla miseria si sono voltate dopo aver visto i loro suggerimenti delle retrospettive essere implementati.

Un mucchio di problemi minori può sommarsi per demotivare. Ad esempio, una cosa che è emersa la scorsa settimana è stata un membro del team a cui non piacevano gli incontri alle 4:00. È facilmente risolvibile.

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

Dando loro la proprietà individuale sul codice.

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

Soluzione: assegna a ogni sezione del codice individui per essere stewards di quella parte del codice, ma consenti l'accesso completo al team all'intero codebase.

Vedi anche: link