Applicare un approccio Scrum uniforme a tutte le squadre all'interno di un dipartimento

Ovviamente sei giustificato nel pensarlo. Il fatto stesso che tu stia parlando di "far rispettare Scrum" è una sirena a tutto volume.
Scrum è prima di tutto l'auto-organizzazione della squadra; possono scegliere come fare il loro lavoro e come organizzarsi. La direzione ha solo una voce in merito al lavoro da svolgere.
Il motivo per cui i team dovrebbero organizzarsi è che sono sempre unici, a causa delle diverse nature dei singoli membri del team (e delle persone con cui lavorano) e del dovuto alle differenze dei prodotti su cui lavorano. Una pratica che funziona perfettamente per una squadra, può avere effetti negativi su un'altra squadra. Ecco perché all'interno di un certo ambito (una metafora sandbox viene spesso utilizzata), devono sperimentare, imparare e scoprire cosa funziona meglio per loro.
Quello di cui hai bisogno è uno Scrum master molto competente (uno per team), che può guidare un team in questa scoperta, ma allo stesso tempo può anche lavorare con il management per ottenere la libertà per il team di continuare quella scoperta.

Benvenuti in uno dei peggiori incubi della mischia. Hai incontrato una delle ragioni per cui scrum non riesce a fornire le grandi cose che tutti hanno in mente quando lo adottano.

Sfortunatamente scrum non è compatibile con il management superiore che tende a centralizzare e creare processi di gestione attraverso l'organizzazione e i team. Per avere successo, i vertici devono cambiare mentalità e concentrarsi su ciò di cui hanno bisogno dai team. Non dovrebbero concentrarsi su come funzionano le squadre. L'unica volta in cui dovrebbero essere coinvolti, è se una squadra non si esibisce per capire il motivo.

Credo che tu debba sederti con la direzione e parlare delle loro esigenze e di ciò che vogliono che i team consegnino. Questo può essere un requisito globale per tutte le squadre. Potrebbe essere una stima che capiscono, la durata, ecc. Queste cose non dovrebbero dettare i processi dei team. È importante separare le aspettative di gestione dal modo in cui gestisci la mischia. Ogni team deve trovare il proprio ritmo e il proprio modo di guidare i progetti, in modo da renderli efficaci, produttivi e fornire ciò di cui ha bisogno la direzione. Se ad esempio hai una stima di 15 punti storia, la squadra dovrebbe essere in grado di calcolare quei punti in giorni uomo (o ore) in base alla velocità media della squadra. Ma sarà unico per il team.

Come azienda, il bilanciamento delle risorse dovrebbe essere un vantaggio competitivo. Altrimenti, basta creare un gruppo di singole società di software che perdono questo tipo di leva. Un'organizzazione con più team e progetti deve occuparsi del turn over e del bilanciamento delle squadre. Non penso che sia una buona idea per ogni combinazione unica di squadra riscrivere il libro su come stanno andando a fare la mischia.

Ogni volta che stai cercando di aggregare cose per misurare qualcosa, la coerenza è importante, cioè non confrontare mele e arance. La gestione dovrebbe concentrarsi su questi bisogni di livello superiore, ma assicurarsi che non siano troppo coinvolti nei dettagli di come operano i team. Prova ad applicare i loro suggerimenti, ma sii preparato a difendere perché una squadra potrebbe essere l'eccezione. Chiunque non apprezzi personalmente un particolare modo di fare le cose, deve indossare i pantaloni per adulti e occuparsene.

Ci deve essere una certa flessibilità, in modo da poter svolgere il lavoro. Ci dovrebbe essere coerenza quando necessario. Se l'appartenenza al team viene cambiata, non tutti dovrebbero sentirsi come se fosse il loro primo giorno di lavoro.

Forse le tue squadre non cambiano mai, ma dovresti dare una possibilità a questa scelta avendo una certa coerenza.

No, non esagerare e hai buone ragioni per essere preoccupato. La gestione dovrebbe essere focalizzata sul cambiamento culturale. Il management deve impostare la direzione giusta e presentare il contesto alle squadre per affrontarlo utilizzando le cerimonie agili che funzionano bene affinché il team sia produttivo.

Mi sento fortunato a lavorare in un'organizzazione che sta attraversando una trasformazione agile da cascata per oltre un anno e ha iniziato a lavorare nel portafoglio in cui lavoro. Inizialmente avevano iniziato con un progetto in cui si formava un team agile. Il successo della consegna attraverso cerimonie agili come le retros, la stima relativa, la previsione storica con la velocità ha portato all'intero portafoglio a formare squadre aggiuntive con il proprio backlog.

Dall'esperienza, Agile non è prescrittivo e non puoi implementare un approccio cookie cutter. Solo perché ha funzionato in una squadra non significa che funzionerà in un'altra. Lo so per esperienza perché inizialmente pensavamo di poter far ripartire nuovi team applicando le stesse cose del DoD, che cosa significa 1 punto, che cosa significa 8 punti. Ma non funziona in quanto contestualmente hanno poco significato se applicati a una squadra diversa. Per inciso, per una storia della squadra superiore a 8 punti significava che era troppo grande e doveva essere diviso.

Ciò che ha funzionato è stato la definizione di linee guida per i team, come devono fare stand-up, retros, showcases allo stesso tempo e ad ogni retro azioni in cui vengono prese in giro e implementate per migliorare i nuovi team. Altre cose come la definizione del fatto e il dimensionamento dei punti della storia sono stati introdotti dopo un paio di sprint mentre il team ha acquisito maggiore familiarità con il concetto di narrazione della storia e il completamento delle carte e non averlo fatto insinuarsi nel prossimo sprint.

So che questo è un duro affare per la gestione perché vogliono sapere quando verranno consegnati i progetti e quando si formano nuovi team agili è difficile dare un'immagine in anticipo. Ma ora il portafoglio ha la reputazione di avere una strong capacità di consegna agile. Saremmo ancora inciampando se l'approccio del cookie cutter continuasse a essere spinto alle altre squadre.

L'incoerenza nella pratica tra i team Scrum potrebbe effettivamente essere un problema, ad esempio se i membri del team si spostano da un gruppo all'altro.

Sarebbe meglio provare a risolvere questi problemi di condivisione delle conoscenze inter-squadra in un modo più agile - forse qualcosa come eseguire sessioni di Lean Coffee o Scrum-of-Scrum coinvolgendo i tuoi maestri di mischia. Spero che la tua direzione si renda conto che stai assumendo la proprietà di questa area e smetti di provare a gestire i problemi in modo top-down.