Come organizzare i team Scrum
Puoi leggere l’articolo in inglese su Medium pubblicato in Serious Scrum
Cosa suggerisce Scrum
I prodotti aziendali variano in complessità. Per gestirli possono essere necessari gruppi di 2-3 persone fino ad arrivare a gruppi che coinvolgono più di 100 persone. Il Product Owner e lo Scrum Master non si devono conteggiare a meno che non eseguano loro stessi anche l’implementazione degli elementi di backlog. Quando la complessità del prodotto aumenta e il numero delle persone coinvolte nello sviluppo inizia a crescere c’è la necessità di prendere delle decisioni su come suddividere i gruppi.
Divisione per iniziativa aziendale
Alcuni Coach Agile suggeriscono di dividere i team per iniziativa aziendale. Ciò significa che per ogni iniziativa sponsorizzata dal portfolio management viene formato un team che è responsabile dell’iniziativa. Il motivo principale per proporre questo tipo di organizzazione è che il team ha tutte le competenze necessarie per portare a compimento l’iniziativa. Un’iniziativa aziendale può essere qualsiasi nuovo requisito o miglioramento da aggiungere al prodotto, ad esempio:
- Integrazione con un nuovo sistema esterno
- Modifica dell’architettura software per migliorare le prestazioni
- Creazione di una piattaforma di analytics
Gli svantaggi principali di questo tipo di approccio organizzativo sono:
- La durata dell’iniziativa aziendale può variare molto, da poche settimane ad anni: potrebbe essere necessario cambiare i membri del team Scrum dopo alcune settimane, questo non è in linea con le best-practices di Scrum che suggeriscono di avere team stabili piuttosto che team che cambiano frequentemente. Inoltre, potrebbe non esserci nemmeno il tempo di arrivare alla fase di performing dello sviluppo del team .
- L’iniziativa aziendale può avere un impatto su più aree funzionali del programma: i team possono finire a lavorare sugli stessi moduli funzionali, creando dipendenze tra le implementazioni dei team che generano conflitti sul codice sorgente che rallenteranno la fase di sviluppo. Inoltre, se queste dipendenze vengono trascurate, ci saranno problemi nell’unire le funzionalità che possono avere business logic in conflitto.
Divisione per competenza tecnologica
Questo è il caso peggiore, quando i team sono divisi per competenza tecnologica ci saranno dipendenze tra i team per implementare una parte di un modulo software:
- Esperti della GUI
- Esperti di back-end
- Esperti DevOps
con questo tipo di organizzazione, sarà molto difficile coordinare i team per avere un prodotto funzionante alla fine dello Sprint. Le nuove funzionalità saranno implementate dividendole in infrastruttura, front-end, back-end. Ciò non è in linea con l’idea di avere una funzionalità completa che sia dimostrabile al Product Owner e agli altri stakeholder alla fine dello Sprint.
Divisione per aree funzionali
La suddivisione delle responsabilità dei gruppi coinvolti nello sviluppo del prodotto è legata all’architettura del prodotto. Non si può semplicemente creare i gruppi ed assegnare l’implementazione dei requisiti appena sono pronti per lo sviluppo, senza avere chiaro a quale area o modulo funzionale appartiene il requisito. Così facendo si creano conflitti e dipendenze durante lo sviluppo che fanno perdere tempo sia nella fase di implementazione del requisito che nella fase di merge.
La prima cosa importante quando si decide la modalità di suddivisione dei gruppi è avere ben chiaro quali sono le funzionalità di business che il prodotto offre. In questo modo si può assegnare ad un gruppo la responsabilità di una o più funzionalità di business che non si sovrappongono. Ad esempio, i sistemi a supporto del business di una società di telecomunicazioni comprendono le seguenti funzionalità di business:
- Catalogue Management
- Order Management
- Inventory Management
- Charging
- Billing
Quindi si può avere un team di 3-9 persone per ogni area funzionale. Laddove l’area funzionale risultasse ancora troppo grande per essere gestita da un solo team, si può suddividere ulteriormente in moduli funzionali. Ad esempio l’area funzionale di Catalogue Management potrebbe essere suddivisa in Commercial Catalogue Management e Service Catalogue Management.
La definizione delle funzionalità di business di un prodotto, non è sempre banale e di solito è un processo iterativo. I confini e le responsabilità di ogni modulo sono raffinati con l’esperienza. Il processo di definizione e raffinamento delle funzionalità di business richiede una buona conoscenza della struttura, dell’area di competenza e dei processi di business dell’organizzazione aziendale.
Microservizi
La decomposizione del prodotto in funzionalità di business è anche uno step necessario per muoversi verso un’architettura a microservizi. In un’architettura a microservizi, ogni servizio deve essere abbastanza piccolo da essere sviluppato da un unico team. Inoltre ogni servizio deve rispettare il principio di singola responsabilità. Ossia deve avere un’unica ragione per cambiare e la funzionalità implementata dal servizio deve essere completamente incapsulata nel servizio stesso.
Scrum Self Organization
Scrum suggerisce di avere self-organizing teams. Una volta definiti i ruoli e individuate le aree funzionali, sarà possibile adottare una strategia per aiutare i team nell’auto-organizzazione. Consiglio vivamente di suddividere il prodotto in aree funzionali, ogni area funzionale può avere il suo Product Owner; se l’organizzazione sta attraversando una trasformazione verso Scrum, potrebbe essere adottata la strategia del Marketplace descritta nel post collegato. Invece, se il prodotto sta crescendo e sono necessarie più persone per svilupparlo, il team può crescere fino a raggiungere i 9 membri; quando è necessario un numero maggiore di persone nel team,è consigliabile coinvolgere il team nella decisione su come suddividersi per avere un accordo sulla nuova organizzazione e una sensazione positiva circa il cambiamento necessario.
Se ti è piaciuto l’articolo Come organizzare i team Scrum e t’interessa Scrum puoi leggere altri articoli nella sezione Agile