Scrum si presta a ambienti multi-progetto?

Lavoro come Development Manager proprio in questo ambiente, e ho implementato Scrum con successo con un team di 4 persone nell'ultimo anno, da quello che era un pasticcio orribile. Ci è voluto un po 'di tempo per arrivare dove siamo ora, ma funziona benissimo. Cercherò di riassumere le azioni più importanti, ma non esitate a chiedere ulteriori informazioni.

1. Ho agito sia come proprietario del prodotto sia come Scrum Master. Ho lavorato per creare un backlog per ogni prodotto, con lo stakeholder associato.

2. Ho quindi dato la priorità a TUTTI i backlog, quindi ho avuto il mio backlog in modo efficiente. Stava usando Fogbugz, quindi potevo filtrare ognuno per progetto affinché lo stakeholder lavorasse con me e mescolasse gli elementi.

3. Pianifica gli sprint da questo, incapsulando tutti i progetti e tutti i membri del team, quindi alcuni membri del team lavoreranno alle proprie attività specifiche, ma incoraggeranno il lavoro e l'apprendimento interfunzionali. Tutte le discussioni in piedi sono utili, perché se qualcuno sta parlando di qualcosa che nessun altro conosce, ha dovuto elaborare abbastanza per noi da capire. Questo ha aiutato l'apprendimento.

   • A questo punto, il team mancava di coesione, ma almeno stavamo facendo le cose su tutti i progetti, mantenendo l'azienda felice e migliorando la qualità aggiungendo il controllo del codice sorgente / i test automatici. È stato un enorme miglioramento del pasticcio che era prima, ma era anche difficile mantenere la concentrazione, senza un obiettivo se non quello di completare lo sprint. Inoltre non disponevamo di demo in quanto non sarebbero state particolarmente rilevanti per uno qualsiasi degli stakeholder. Poiché ero sia PO che SM, ero relativamente gentile nel coinvolgere troppo la squadra. Vale la pena notare che stavamo ancora consegnando MOLTO di più rispetto al mio arrivo.

4. Ho quindi cercato di spostare lentamente l'attenzione degli sprint su un singolo prodotto, quindi avremmo uno sprint dire il 60% su un prodotto, ma con altri compiti ancora. Alla fine, gli sprint sono stati concentrati al 90% su un compito e le parti interessate hanno imparato ad "aspettare il proprio turno" - dopo tutto, stavamo ancora ottenendo molto più di quanto non avessero mai fatto prima. Ciò ha reso possibile la demo per un prodotto alla volta.

5. Una volta focalizzati gli sprint, ho iniziato a formare gli stakeholder in Scrum, trasformandone alcuni in Product Owner. Questo è il livello in cui mi trovo ora, lavoro con 3 proprietari di prodotti e ho ancora 2 prodotti che possiedo in modo efficace. Gli sprint possono avere 1 o 2 compiti per progetti "altri", ma abbiamo un focus sufficiente per una demo sprint con i principali stakeholder dello sprint dimostrando solo le nuove funzionalità dei loro prodotti.

Spero che questo aiuti, questo è il viaggio che ho fatto con il mio attuale datore di lavoro, e finora il team Dev, le unità aziendali e (soprattutto) il mio capo sono molto felici.

Al momento lavoro come parte di un team di scrum di 4 persone che è responsabile, in un modo o nell'altro, per tutti i prodotti della nostra azienda. Con un totale di circa 16 prodotti, oltre a un casino di pezzi unici semi-connessi, posso dirti dall'esperienza che scrum non si affida a un ambiente multi-progetto. Come detto sopra, è difficile costruire una sinergia di squadra quando si lavora costantemente su cose diverse. Inoltre, è difficile relazionarsi ai dettagli di lavoro dei compiti dei tuoi compagni di squadra, dal momento che il tuo focus è su un compito completamente diverso, in un progetto completamente diverso.

Inoltre, "cadere-in-amore" o anche l'analisi non assegnata con un particolare prodotto è quasi impossibile a causa del tasso di turnover delle assegnazioni, che può portare, tra le altre cose, alla decomposizione del codice.

Se ti trovi in una posizione in cui non puoi sfuggire a più progetti assegnati al tuo team, io non consiglierei SCRUM.

La risposta accettata affronta la domanda abbastanza, ma mi consente di condividere le mie esperienze. Sono stato in due diverse situazioni in cui i membri di un team SCRUM dovevano gestire più progetti. Un team SCRUM può gestire più progetti, ma solo a determinate condizioni.

Nel primo caso, i progetti multipli hanno presentato una sfida significativa. Il mio datore di lavoro doveva ancora adottare metodologie Agile nel suo complesso. Facevo parte di un progetto pilota in cui abbiamo utilizzato SCRUM per un singolo progetto.

Il problema è che il team di gestione del progetto ha preferito molti progetti concomitanti e di lunga durata su progetti brevi e mirati. Di conseguenza, al mio team sono stati assegnati costantemente più progetti di quanti ne avessimo sviluppatori; era tipico per la squadra di quattro di essere la giocoleria da sei a dieci progetti! Ciò è stato esacerbato dal fatto che abbiamo dovuto gestire anche una notevole quantità di responsabilità operative e di supporto.

Ciò che abbiamo scoperto è che il team ha avuto solo una piccola parte del loro tempo dedicato al team SCRUM, non siamo riusciti a stabilire una velocità affidabile e abbiamo limitato la quantità di lavoro per ogni Sprint per paura di non prendere gli impegni Sprint . L'integrazione di tutto il lavoro di altri progetti nella nostra pianificazione potrebbe aver aiutato, ma quei progetti avevano date e ambiti fissi, rendendo improbabile che avremmo potuto fare correttamente SCRUM.

Nel secondo caso, l'intera azienda aveva abbracciato da tempo Agile e aveva sviluppato un mezzo attraverso il quale diversi team potevano essere affrontati da un team SCRUM. Era così efficace che, come ingegnere, non sapevo nemmeno che metà dei progetti fossero! I proprietari dei prodotti lavorerebbero con i Project Manager per identificare il lavoro necessario; utilizzando le stime fornite da noi ingegneri e la velocità stabilita dal team, i proprietari dei prodotti potevano fare previsioni ragionevoli su quando un particolare oggetto sarebbe stato completato. Finché il team ha costantemente rispettato i propri impegni, non è stato necessario preoccuparsi delle scadenze per la maggior parte dei deliverable.

È stato d'aiuto, tuttavia, che tutti stessimo lavorando sullo stesso piccolo insieme di applicazioni. I team sono stati allineati con i prodotti, rendendo più facile la comprensione di ciò a cui stavano lavorando i colleghi e rendendo più semplice spostare l'attenzione da un progetto all'altro, se necessario.

In breve, SCRUM può essere facilmente adattato per gestire più processi simultanei, se viene eseguita la pianificazione e l'organizzazione corrette.

Non sono sicuro di capire, se hai "2/3 persone che lavorano su ciascuno", non è lo stesso di avere diversi team, ognuno dei quali lavora su un progetto.

Possono cambiare i progetti regolarmente, piuttosto che avere un "prodotto" su cui lavorano continuamente, ma non è molto diverso. Alcuni luoghi si aspettano addirittura che i team lavorino su parti diverse di un prodotto e cambino per lavorare su qualcos'altro dopo che ogni progetto è stato completato, principalmente per garantire una buona diffusione della conoscenza.