Mischia in un ambiente di consulenza?

Uno dei problemi più comuni in Scrum è che a volte si ottiene un manager Procrustean che vuole fare le cose "dal libro". Dimenticano che l'obiettivo di usare Agile / Scrum non è fare Agile / Scrum ma fornire una migliore qualità e un software più reattivo all'utente in modo iterativo. Hai anche molti manager "Scrum in Name Only" che pensano che avere un breve incontro giornaliero sia tutto quello che c'è per Scrum. Può anche diventare un fattore abilitante per i gestori inclini alla gestione delle micro-proprietà.

Nella tua situazione, penso che tu ed i maestri Scrum nei vari gruppi dovresti essere in grado di determinare se sei necessario per una posizione in piedi in un particolare giorno. Ad esempio, se il team sta attualmente lavorando su sprint che non ti coinvolge direttamente, come ad esempio lavorare su modelli di oggetti e sul database, non è necessario che ci sia.

Dato che stai fornendo lavoro a più team, sei più un venditore, un ruolo secondario, piuttosto che un membro del team di sviluppo, un ruolo fondamentale. Questo potrebbe essere il modo di affrontarlo se la tua gestione è troppo vicina al libro. Se stai lavorando da solo, potresti finire con la solita scrumming sui tuoi sprint. C'è stata una buona discussione su come fare un solo scrum in questa discussione .

Quanto tempo dedichi alle riunioni di gruppo per ogni progetto, ogni settimana?

Suppongo che ci sia una riunione di stato settimanale per ogni progetto e che ogni riunione venga eseguita per circa un'ora.

Una mischia di 10 minuti ogni giorno per ogni progetto ti farà risparmiare 10 minuti a settimana per ogni progetto. Non sembra molto, giusto? Ma in quell'ora di riunione di stato lunga, quanto tempo ti prepari per andare ad esso? Finisce per trascinare tutti nella squadra dalla squadra. Fa schifo se non hai nemmeno lavorato a quel progetto quella settimana b / c ti ritrovi a fare un enorme switch di contesto che è un blocco di un'ora intera per un progetto che non è così alto sulla tua lista delle priorità.

Con una mischia è veloce. Tutti scoprono chi sta lavorando su cosa quotidianamente. I PM possono ottenere una rapida panoramica del loro progetto, gli sviluppatori sanno chi sta lavorando su quale parte in modo che i colli di bottiglia possano essere identificati prima e i lead della squadra possono vedere rapidamente chi sta per andare su un biglietto e fare un controllo dei danni prima di uscire. mano.

Lavoro in un ambiente a più progetti, e devo dire che preferisco i progetti che vengono eseguiti con scrum rispetto alla tradizionale riunione di stato. Tendiamo ad avere più tempo e meno budget, ed è rinfrescante sapere se qualcuno sta effettivamente spendendo del tempo in quel progetto in un dato giorno.

Un progetto a cui mi sono trovato alla fine dello scorso anno si è spostato in mischia verso la fine. Il primo ministro cancellò la riunione di stato settimanale un giorno, quindi inviò un invito a una riunione per quel pomeriggio. Abbiamo fatto un rapido aggiornamento di stato, quindi ha programmato un altro incontro per due giorni dopo. Continuammo a giorni alterni fino all'ora del crunch, il mattino si alzò e il PM portò normalmente delle ciambelle per incoraggiarci a essere tutti lì.

Il progetto è passato dall'essere una serie di compiti a cui gli sviluppatori sarebbero arrivati, a obiettivi e ticket chiaramente definiti su cui lavorare entro la prossima riunione. Quando devi aggiornare il tuo stato domani e non la settimana prossima, assicurati di avere qualcosa da dire. :-)

Onestamente credo che la mischia possa adattarsi a qualsiasi progetto se il team è impegnato a farlo. Si apre la comunicazione in modo che tutti siano sulla stessa pagina, qualcosa che ti aspetti da fare una riunione di stato settimanale, ma raramente lo fa.