Minimizzare lo sforzo massimizzando il valore prodotto

Scrum: Cambiare Framework e Gestire Più Progetti

Qualche giorno fa, in uno dei miei video, ho ricevuto da Alfonso una domanda molto interessante. E come promesso, voglio approfondire con voi le vostre domande in un post dedicato. Ecco, questo è proprio uno di quei post.

La domanda era questa: un nuovo progetto non può rimanere tale per sempre. Quando il progetto viene rilasciato, è opportuno cambiare framework? Con un team di sette persone posso gestire più progetti con Scrum?

Prima di tutto, ricordate i miei consigli sull'utilizzo di Scrum: sono consigli, non regole. Dei consigli che darei a qualsiasi mio collega che volesse iniziare ad utilizzare Scrum.

Naturalmente, se conosci bene il framework o sei un abile Scrum Master, sono sicuro che non avrai problemi nell'applicazione di Scrum o nell'applicazione di parte di esso in team non del tutto dedicati o in progetti già in corso. Dico parti del framework perché, ragazzi, siamo adulti, il mondo ideale non esiste e soprattutto, ricordiamocelo, dobbiamo essere agili. Cioè, dobbiamo essere in grado di prendere e utilizzare ciò che ci serve del framework per ottimizzare il nostro lavoro e ottimizzare il valore prodotto.

Sapete, a volte è possibile trovare team che ostacolano l'applicazione del framework oppure che hanno difficoltà ad utilizzarlo. Allora perché non introdurlo poco alla volta o utilizzare anche solo piccole parti del framework invece di imporlo? Cambiare modalità di lavoro è un processo lento che richiede del tempo per essere assimilato.

Dopo questa dovuta considerazione, proviamo a rispondere alle domande di Alfonso per punti.

Prima domanda: Quando il progetto viene rilasciato, è opportuno cambiare framework?

Ecco, questa è una domanda davvero interessante. Non nego di averla ricevuta spesso e non nego che all'inizio del mio percorso fu anche una mia domanda, proprio perché all'inizio di questo mio percorso mi trovai a lavorare con un software già online.

Ad oggi, io faccio una distinzione tra queste due possibilità:

1. Il progetto è online e stabile ed è terminata la fase di rodaggio:

Cioè quella fase in cui tutti sono lì in attesa di aspettare che saltino fuori bug non trovati in fase di test. Superata questa fase, entriamo in una fase di ordinaria manutenzione del progetto. In questa specifica fase, io preferisco cambiare framework ed utilizzare Kanban: meno regole, meno effort per seguirne le implementazioni, insomma più semplice per tutti. In questa fase però continuo ad esempio ad utilizzare lo stand-up meeting. Ricordiamoci che dobbiamo essere agili, se delle pratiche hanno funzionato bene, perché non continuare ad utilizzarle anche con altri framework? Beh, lo stand-up, secondo me, è una di quelle pratiche che funziona davvero bene se gestita nel modo corretto.

2. Il progetto è online e stabile e oltre all'ordinaria manutenzione è necessario fare un vero e proprio aggiornamento:

Nuove funzionalità, nuovi sviluppi che richiedono diverse competenze, analisi ed implementazioni pesanti. Ecco, in questo caso possiamo benissimo tornare ad utilizzare Scrum vedendo questo aggiornamento come un vero e proprio progetto. In questa nuova fase, possiamo inserire l'attività di ordinaria manutenzione come attività all'interno del progetto che vengono pianificate secondo sprint. Possiamo anche decidere di dividere il team: una parte dedicata alla manutenzione e l'altra parte alle nuove funzionalità.

Ad ogni modo, io preferisco sempre valutare la situazione e poi decidere se cambiare framework. Puoi utilizzare diversi framework per uno stesso progetto, ma in diverse fasi di vita del progetto. Oppure non cambiare mai il framework e, ad esempio, continuare ad utilizzare Scrum. La decisione spetta a voi, ma ricordate: quello che fate deve sempre essere in funzione dell'ottimizzazione del lavoro e del valore che state producendo. La decisione poi naturalmente deve essere condivisa e accettata da tutto il team.

Ad ogni modo, ricordate: il vostro obiettivo è minimizzare lo sforzo massimizzando il valore prodotto.

Seconda domanda: Con un team di sette persone posso gestire più progetti con Scrum?

Per trovare la risposta a questa domanda, proviamo sempre a pensare ad una regola madre che dovremmo cercare di rispettare finché ne abbiamo la possibilità. La regola è: un progetto, un team. Naturalmente non è sempre possibile, a volte un'azienda si trova a dover lavorare su più progetti con un solo team, magari semplicemente perché arrivano più commesse nello stesso periodo, che naturalmente è difficile rifiutare.

Insomma, le situazioni possono essere tante. Il mio consiglio è: finché potete, fate in modo che la qualità del prodotto venga prima della quantità. Per questo, dovete ricordare che per essere sicuri di fare un lavoro di qualità, il team è meglio che si concentri su un solo progetto per volta.

Detto questo, se siete nella situazione di dover far fronte a più progetti con un solo team, bene, avete di fronte a voi tre possibilità:

1. Dividere il team in modo da riuscire a far fronte a più progetti, quindi mantenere un team più piccolo dedicato ad ognuno di essi.

2. Non dividere il team e mantenerlo unito. Qui, in base agli accordi con i tuoi clienti, puoi decidere di lavorare un progetto per volta, quindi capire a che punto sei con un progetto già iniziato e decidere di portare a termine tutta una serie di attività prima di iniziarne un altro.

3. Mantenere il team unito e utilizzare una board unica per tutti i progetti coinvolti, stile Kanban. Questo sarà utile per dare evidenza al lavoro e fare in modo che il team lavori task singole e atomiche di progetti diversi. Naturalmente, in questa situazione ti consiglio di utilizzare pratiche o cerimonie che si sono rivelate molto utili in passato, ad esempio gli stand-up meeting oppure l'utilizzo degli story point.

Insomma, potete capire: ogni situazione è diversa e possono essere trovate soluzioni adatte alla situazione e al team coinvolto.

Alla fine, ricordiamocelo: quello che conta non è se utilizzate Scrum, Kanban, Extreme Programming oppure avete fatto un mash-up tra tutti questi. Ciò che conta davvero è solo una cosa: portare a termine il progetto.

Bene, siamo alla fine di questo post. Se ti è piaciuto, lascia un commento e condividi le tue esperienze. Ricorda, se hai dubbi o curiosità, scrivimi: sarò ben felice di aiutarti e ti risponderò magari in uno dei prossimi articoli. Per adesso è tutto, ci vediamo presto. Fino ad allora, ricorda: keep it simple.