Continuiamo la nostra serie di post introduttivi su Scaled Agile Framework (SAFe) partendo dal livello più basso della Big Picture, ovvero il Team Level.
SAFe Team Level
Si tratta del livello più familiare per chi ha già esperienza con metodologie Agile@Core, come, ad esempio, Scrum o XP o una loro combinazione. Qui ritroviamo le pratiche tanto care a chi è fautore di questo diverso approccio al software development: uso delle User Stories, Test Driven Development, Simple Design e low BigUpFrontDesign, Pair Programming, Continuous Integration, ecc…
Ma il Team Level non è solo Agile@Core. Infatti la differenza più evidente è rappresentata dalla necessità di coordinare i diversi Team impegnati sul progetto al fine di garantire la corretta gestione dello Stream Value.
Per avere un riferimento numerico è utile ricordare che, tipicamente Scrum raccomanda Team composti da 7 (+/- 2) membri. Nel caso @Scale parliamo dell’impiego di 50/150 developer, quindi tra i 7 e i 20 Team se si decide di usare comunque Scrum come pratica base, cosa molto comune.
Nascono così una serie di interdipendenze che è assolutamente necessario gestire, cosa che è possibile affrontare affidandosi ad alcune best-practice:
- I vari Team coinvolti sul progetto devono allinearsi sulla stessa cadenza, ovvero devono avere iterazioni di durata comune;
- I vari Team sincronizzano esclusivamente le date di inizio/fine, lasciando più libertà ai singoli gruppi di lavoro;
- Sfruttare appieno i Potentially Shippable Increments (PSI), ovvero l’unità minima di Valore utile da presentare agli stakeholder, che, tipicamente, interessa quanto realizzato in 4/5 iterazioni;
- In abbinamento alle iterazioni “classiche”, SAFe suggerisce l’uso, alla fine dell’insieme costituente 1 PSI, di una HIP Iteration (Hardening/Innovation/Planning).
Ogni Team ha il proprio Team Backlog e, quindi, per ogni Team è presente un Product Owner che ha la responsabilità dei relativi Work Item, nonché della loro priorizzazione. Lo Sprint/Iteration Planning meeting si trasforma nel PSI Planning, a cui partecipano tutti i Team e si fissano gli obiettivi per il prossimo PSI. Vista la complessità non deve meravigliare che lo stesso si svolge in ben 2 giorni.
Tornando alle best practice, è utile soffermarci più in dettaglio sull’HIP iteration, visto che le altre tecniche proposte sono assolutamente intuitive. Come abbiamo brevemente accennato nel post “il potere occulto del debito tecnico”, la HIP iteration, che ha tre obiettivi primari:
- Hardening (Tempra): assicurarsi che il debito tecnico sia ridotto e dare il tempo per realizzare test speciali, come per esempio, test prestazionali;
- Innovation (Innovazione): fornire tempo per ragionare su nuove idee e sperimentazioni out-of-the-box;
- Planning (Pianificazione): valutare i progressi e rivedere la pianificazione (Inspect-and-Adapt Workshop).
Il pre-requisito per una buona HIP Iteration è lo Sprint/Iteration review, che qui si trasforma nel più altisonante Inspect-and-Adapt Workshop, legato all’intero gruppo di Iterazioni previste per il PSI corrente. Lo scopo è quello di ragionare con obbiettività sui progressi fatti, sulle difficoltà e su come poter migliorare le attività nel loro complesso coinvolgendo contemporaneamente tutti i Team, esattamente come per il PSI Planning.
Un elemento formalizzato dall’HIP è l’Innovazione, ovvero la possibilità di utilizzare questo slot temporale per aumentare il proprio know-how (continuous education), migliorare l’infrastruttura di supporto, l’ambiente di lavoro, ecc… Ciò rende possibile ai Team, sempre nel loro insieme, di auto selezionare le attività più rilevanti emerse durante l’Inspect-and-Adapt Workshop.
Infine, l’accento sul debito tecnico. Anche se non è mai opportuno accumulare un eccessivo debito tecnico attraverso le varie iterazioni (una parte è comunque fisiologica), è possibile che in alcuni casi non sia possibile fare diversamente: si pensi, ad esempio, ai test prestazionali che non è possibile realizzare finché non viene effettuata la fase di continuous integration finale relativa alla specifica PSI. Se ciò accade, è possibile sfruttare parte del tempo riservato dell’HIP proprio per ridurre (idealmente abbattere) il debito tecnico accumulato (Hardening).
Come si vede, SAFe formalizza una serie di concetti e di pratiche comuni, corredandole con il necessario collante per un efficace lavoro multi-Team.
