Squadre parallele e mischia / agile

Question

Squadre parallele e mischia / agile

#1 da (2 voti)
#2 da (0 voti)

4

La mia azienda è cresciuta seriamente negli ultimi anni. Fino a qualche anno fa potevamo lavorare con 1 squadra agile e tutto è andato liscio. Ora abbiamo più team, tutti agili e le cose vanno meno facilmente come speravamo.

Uno dei principali problemi [psicologici] è come organizzare i metodi di lavoro nei team.

Se ogni squadra ha il proprio modo di lavorare (il proprio tipo di fogli Excel in cui viene mantenuto il progresso, il proprio modo di calcolare la capacità, ...) le squadre sembrano allontanarsi e sembrano competere piuttosto che cooperare su cose (sviluppando un codice simile in parallelo)
Se tutti i team usano le stesse metodologie e le stesse procedure di flusso di lavoro, allora abbiamo di nuovo due alternative:
- 'Forzare' le metodologie da parte della direzione sembra scorretto in quanto la gestione non sa chiaramente come le metodologie agili / scrum dovrebbero funzionare (solo i team attuali lo sanno)
- Lasciare che i team suggeriscano miglioramenti e "costringono" questo sugli altri team potrebbe migliorare la competizione piuttosto che la cooperazione (i team si rifiuteranno di utilizzare la metodologia perché proviene da un'altra squadra).

Qualcuno ha esperienza con più team che lavorano insieme in un modo agile / scrum? In che modo promuovere i team lavorando insieme senza farli incolpare a vicenda per cose che non funzionano?

agile team scrum

posta Patrick 18.07.2011 - 15:47

fonte

2 risposte

Leggi altre domande sui tag agile team scrum

Come risolvere un problema di autenticazione generale per più applicazioni? È sempre il modo migliore per andare a mettere in coda le email invece di inviarle in tempo reale? [duplicare]

score 2 · Answer 1

Dalla tua descrizione non è chiaro se i team stiano effettivamente lavorando a progetti separati - presumo che lo siano.

Nel caso ideale, penso che questo dovrebbe essere deciso principalmente dai team stessi, ma arriverebbero più o meno alla stessa conclusione (cioè usando Agile). Soprattutto se i membri di spicco dei team erano soliti lavorare insieme in un'unica squadra Agile, tendono naturalmente a portare con sé le pratiche che hanno provato e dimostrato di funzionare.

Tuttavia, ogni nuovo team è obbligato ad affrontare la propria situazione, più o meno diversa e le sfide, quindi nel tempo svilupperanno il proprio processo in modo un po 'diverso dagli altri. E va bene, entro certi limiti. Al fine di semplificare la vita del management, è consigliabile concordare e attenersi a un modo comune di riferire alla direzione. Ma dal momento che Agile non sta segnalando pesanti, non credo che ciò imponga enormi restrizioni a nessuna squadra.

Ora, se una squadra presenta un miglioramento del processo, è davvero utile che altre squadre lo apprendano, a patto che risolva anche alcuni dei loro problemi. Quindi IMO l'approccio migliore sarebbe quello di mantenere la comunicazione tra i team in merito a retrospettive e soluzioni per il miglioramento dei processi, attraverso alcuni membri del team designati (basterebbe uno per ogni team, ad esempio gli Scrum Master) per incontrarsi regolarmente dopo ogni sprint e discutere problemi che hanno incontrato, le soluzioni che hanno provato e i risultati.

Quindi se la squadra A parla di un problema, è possibile che la squadra B abbia già una soluzione funzionante, che può essere applicata immediatamente. O se la squadra A ha un'idea per risolvere lo stesso problema, è possibile che la squadra C abbia già sperimentato un'idea simile e abbia acquisito un'esperienza utile che possono condividere con il team A. Etc. Il punto è che ogni squadra è più interessata in soluzioni ai loro problemi concreti, quindi è meglio affrontare la condivisione della conoscenza da questa prospettiva: adattando le soluzioni a problemi concreti, piuttosto che cercare di adattare i processi a "soluzioni" immaginarie. I team di sviluppo sarebbero abbastanza normali a resistere al secondo approccio, ma non il primo.

score 0 · Answer 2

its own type of Excel sheets where the progress is kept

Questo dovrebbe far scattare alcuni allarmi proprio lì. Probabilmente vale la pena investire in alcuni software di gestione dei progetti. La suite Atlassian è piuttosto buona e probabilmente la più popolare. FogCreek (creatore dello scambio di stack) ha anche degli ottimi strumenti. È naturale che diversi progetti vengano eseguiti in modo diverso. Spesso è il meglio. La centralizzazione delle attività e il corretto monitoraggio dei progressi sono tuttavia essenziali.