Problemi di cultura preesistente durante la transizione Scrum

Question

Problemi di cultura preesistente durante la transizione Scrum

#1 da (6 voti)

1

Il mio team sta provando a passare a Scrum da tempo, ma sembra che la cultura preesistente stia impedendo alla squadra di passare a una nuova mentalità o addirittura a indurla a muoversi nella direzione opposta.

Per riferimento, il team ha due manager di linea, un project manager, un product owner e cinque sviluppatori.

Gli sviluppatori non hanno mai contatti diretti con il proprietario del prodotto. Sebbene si possa sostenere che i line manager riempiono quel ruolo dal momento che definiscono il lavoro per il team, questo è negato dal PM.
Il project manager insiste sul fatto che lei è la "scrum leader".
PM insiste anche sul fatto che i line manager fanno parte del Dev Team poiché tutti i team Agile hanno un ruolo di "Team Lead" e la supervisione diretta del lavoro da parte di LM va bene dato che sono i lead tecnici dopo tutto, che è una Scrum valida ruolo.
PM insiste anche che gli standup giornalieri servano da strumento di segnalazione.
Gli stand-up giornalieri sono gestiti da LM che lo utilizzano per monitorare i progressi quotidiani, supervisionare ogni singolo sviluppatore, commentare il loro approccio e assegnare nuovi compiti.
1-3 giorni per user story sono considerati un limite rigido per user story da LMs anziché una linea guida di breakdown. Se uno sviluppatore supera i 2 giorni su una storia utente, riceve una email su come lo sviluppatore è responsabile della consegna entro una scadenza.
I LM insistono sulla proprietà collettiva significa che dovrebbe esserci un individuo per funzione responsabile del suo sviluppo.

Bonus:

Quando ho sollevato questi punti in modo estemporaneo durante una riunione, mi è stato praticamente detto che ero sciocco per aver suggerito di rimuovere gli LM dal processo di sviluppo poiché erano quelli con la conoscenza del business o di dare suggerimenti sin da quando era nuovo
Poche ore dopo aver inviato un'email agli LM con gli sviluppatori CCed che riassumevano i punti che ho citato in merito agli articoli pertinenti, ho ricevuto un'email che inviava a tutte le persone in quell'email un problema relativo a una funzione su cui ho lavorato e come ci è voluto troppo tempo.

C'è qualcosa che posso fare in questa situazione per aiutare il team come transizione dello sviluppatore verso una mentalità Scrum ed evitare di rompere il morale della squadra a causa del monitoraggio quotidiano e della supervisione che ne deriva, che richiede fino al 10-15% di la settimana lavorativa?

management agile scrum scaled-agile-framework

posta Victor S 07.10.2018 - 14:38

fonte

1 risposta

Leggi altre domande sui tag management agile scrum scaled-agile-framework

DRY o non DRY in SDK Metodi di classe che non vengono mai chiamati e tutto gestito dagli interni della classe stessa

score 6 · Accepted Answer

Concentrati sui singoli problemi piuttosto che sulle metodologie e coinvolgi tutti.

Piuttosto che buttarsi dritto e proporre cambiamenti, inizia suggerendo che la squadra tiene regolarmente incontri retrospettivi ogni poche settimane in cui l'obiettivo è discutere cosa sta andando bene, cosa non sta andando bene e cosa potrebbe essere migliorato. Questo dovrebbe essere il punto di partenza per identificare problemi specifici da risolvere, oltre a decidere se vale la pena risolvere i problemi e proporre suggerimenti per possibili azioni correttive.

Le retrospettive rappresentano un'opportunità per tutti i membri del team (compresi gli stakeholder e le persone responsabili della consegna) di avere una discussione onesta e aperta su ciò che la squadra sta facendo attualmente bene e le cose che stanno causando dolore o problemi. Questo non include solo i problemi di processo / umani, può essere che ci siano anche problemi tecnici persistenti o soluzioni tecniche. È un problema per il team nel suo insieme discutere se il problema identificato debba davvero essere risolto o se è qualcosa con cui la squadra può convivere, o può essere che il problema esista completamente al di fuori del controllo del team e potrebbe dover essere aumentato verso l'alto .

Ad esempio, se stai dicendo che gli sviluppatori non hanno la possibilità di fornire stime per il lavoro da completare, potrebbe essere il caso che i rischi tecnici non vengano identificati così rapidamente come altrimenti potrebbero essere, o che le stime fornite potrebbero non essere realistiche.

È compito del team nel suo complesso discuterne e decidere se si tratta di problemi reali che hanno un impatto reale sulla consegna del software; se il team è d'accordo sul fatto che questi sono problemi che devono essere risolti, allora tutti nel team hanno anche l'opportunità di suggerire miglioramenti e, per la persona / persone responsabili della consegna del software, di ascoltare e sollevare le loro preoccupazioni - in definitiva sono loro chi ha responsabilità se qualcosa va storto, quindi il loro coinvolgimento è fondamentale.

Ricordare che una metodologia non dovrebbe essere l'obiettivo, l'obiettivo dovrebbe essere quello di avere un processo di sviluppo che permetta al team di gestire il rischio in modo efficace, di rispondere alle esigenze del business nel modo migliore possibile, visti i vincoli esistenti intorno il team, e solo per ottenere un software funzionante che soddisfi le aspettative di tutti.