Reality check sull’opportunità di rendere la propria organizzazione più agile, su cosa è necessario per farlo e sul ruolo (limitato) di pratiche e metodologie cosiddetti “Agile”

1. OptionFactory
No Silver Bullet
Diventare agili non è banale, nè scontato

2. Presentazioni
● Francesco Degrassi
○ Sviluppatore software, coordinatore, consulente
○ Attivo nell’ambito dello sviluppo lean e agile da una decina d’anni
● OptionFactory
○ Sviluppo software con approccio lean
■ High availability, performance, scaling, security
○ Supporto operativo alle aziende che sviluppano o fanno sviluppare
■ assessment, consulenza, formazione
○ Piccole, medie e grandi aziende, italiane ed estere

3. Agile è fuori moda
● Siamo oltre il picco di
interesse
● Molti l’hanno provato
● Non è più un tratto distintivo
○ neppure in Italia

4. ...ma il plateau di produttività è lontano
● Contrariamente ad altre metodi / approcci / tecnologie
○ E’ ancora molto controverso
○ Opinioni molto polarizzate
○ Nessun consenso sulla sua validità e applicabilità
● Uno dei fattori è quello delle aspettative
○ non tanto esagerate, quanto errate
Non un proiettile d’argento, quanto una strategia
con precisi trade-off che richiede capacità non banali

5. Agile Manifesto
● Un set condiviso di principi guida per un modo “migliore” di sviluppare
● Nel tempo vi si sono associati
○ pratiche
○ strumenti
○ metodologie, nuove ed esistenti

6. Principi e pratiche universali
● automazione dei processi ripetitivi, non di concetto
○ maggiore velocità, meno sprechi, meno errori
● pairing
○ resilienza, meno errori
● esplicitazione e discussione del valore
○ chiarezza, maggiori opportunità di massimizzazione
● testing pragmatico, automatico, durante lo sviluppo
● passo sostenibile
● refactoring
● ...

7. Agile Software Development Manifesto
Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change
over following a plan

8. Un approccio agile privilegia alcuni aspetti su altri
allo scopo di ottenere un risultato netto migliore
in uno specifico contesto.

9. Trade-off: Latenza / Throughput
Never underestimate the bandwidth of a station
wagon full of tapes hurtling down the highway.
–Andrew Tanenbaum, 1981

10. Trade-off: Latenza / Throughput
● Assunzione
○ ci sono assunzioni da validare e molto da imparare
○ molte delle feature realizzate non saranno usate o andranno cambiate
● Sviluppo iterativo, per avere feedback più frequente
○ scrum
● team cross-funzionali, per evitare colli di bottiglia
● Simple design, YAGNI
● Value stream mapping
● kanban board
● “See the whole”, System Thinking

11. Trade-off: Flessibilità / Uniformità
● Assunzione
○ Soluzioni non standardizzate
● Team cross-funzionali, per minimizzare le dipendenze esterne
● DevOps, per integrare elementi di operations nello sviluppo della soluzione

12. Trade-off: Reattività / Controllo
● Assunzione
○ Il personale sul campo ha (o può avere) il set di informazioni più
completo e la capacità per prendere decisioni
● Decentralizzazione delle decisioni
○ Team auto-organizzati
○ Empower the team

13. Trade-off: Collaborazione / Tutela
● Assunzione
○ C’è modo di allineare gli obiettivi delle parti e condividere il rischio
● Trasparenza, partecipazione e visibilità nel processo
● Contratti cosiddetti “agili”
○ incrementali
○ revenue sharing
○ clausole di bail-out

14. Appropriatezza al contesto - 1
Più appropriato Dimensione Meno appropriato
Differenziato Tipo di mercato Indifferenziato, commoditizzato
Ridotte Dimensioni Ampie
Flessibile Processo* Regolamentato
Distribuita Distribuzione della
conoscenza
Centralizzata
Alta Trasparenza in azienda Bassa
Performance oriented
Messengers trained
Cultura aziendale Rule / Power oriented
Messenger neglected / messenger shot

15. Appropriatezza al contesto - 2
Più appropriato Dimensione Meno appropriato
Colocato Distribuzione del personale Distribuito
Facile
Cliente interno, accesso all’utente finale
Facilità di ottenere feedback Difficile
Intermediari, subappalti, ambienti militari
Interno TIpologia di cliente* Esterno
Alto Allineamento degli obiettivi
tra cliente e fornitore
Basso
Incerti
servizio innovativo verso il pubblico
Certezza dei requisiti Certi
modulo di integrazione tra prodotti di mercato
Instabili
piattaforma di HFT
Stabilità dei requisiti Stabili

16. Appropriatezza al contesto - 3
Più appropriato Dimensione Meno appropriato
Nuovo, da esplorare Stack tecnologico* Noto, stabile
Minimi
Web application, SaaS
Vincoli di deployment Significativi
Appliance, embedded, ambienti militari
Ridotto
SaaS
Numero di installazioni Elevato
Applicazioni mobile*

17. Capabilities per un approccio agile
● Competenza tecnica, gli errori si pagano e rallentano
● Responsabilità e autonomia, per le decisioni decentralizzate
● Attrazione, selezione del personale (e retention!)
● Comunicazione efficace, sia orizzontale e verticale
● Rapporto positivo e trasparente con il cliente
Diverse, non necessariamente superiori, ad approcci di altro tipo.

18. Metodologie
● Framework / template di processo con annessi ruoli, pratiche, strumenti
● Guidano nel mettere in pratica principi e valori
● Principi e valori, sempre al primo posto
● Rischioso se calate dall’alto (“Make us agile!”)
● Vanno adattate se limitanti
● Shu in Shu-Ha-Ri

19. Problemi comuni
● Metodologia come Il Processo, o
anche best practice
● Metodologia per imbrigliare gli
elementi più disruptive
● Scrum come “Agile with control”
○ Un ossimoro
Cynefin Framework

20. Pratiche - Daily standup
● Obiettivi:
○ comunicazione ed allineamento nel team
○ spinge le persone ad identificare e affrontare gli impedimenti
● Rischi:
○ semplice reporting
○ meccanismo di controllo
○ sit-down meeting
● Altre opzioni:
○ comunicazione costante ed informale tramite colocazione / chatter
○ Ad-hoc standup

21. Pratiche - Kanban board
● Obiettivi:
○ visualizzazione del work in progress
○ minimizzazione del WIP
○ prioritizzazione
○ allineamento
● Rischi:
○ backlog (il cimitero delle storie)
○ nessun limite o definition of done
○ board multiple per le stesse persone / team
● Altre opzioni:
○ small releases

22. Pratiche - Retrospettiva
● Obiettivi:
○ creare un ciclo di sperimentazione e apprendimento
○ creare consapevolezza sui successi oltre che sui fallimenti
● Rischi:
○ blame game
○ valvola di sfogo
● Altre opzioni:
○ spike, deliberate discovery
○ root cause analysis

23. Pratiche - Pairing
● Obiettivi:
○ allineamento
○ resilienza
○ spinge il team a prendere responsabilità sull’intera codebase
● Rischi:
○ pairing anche dove non porta valore
○ coaching travestito da pairing
● Altre opzioni:
○ design / code review

24. Pratiche - Coding standard
● Obiettivi:
○ aumentare la comprensibilità
○ ridurre il carico cognitivo
○ aumentare il rapporto segnale/rumore
● Rischi:
○ standard controproduttivi
○ ingessamento

25. Come procedere?
1. Applicare liberamente i principi e le pratiche di buona ingegneria del
software che non comportano trade-off
2. Valutare il posizionamento di azienda e progetto sulle varie dimensioni
3. Valutare le proprie capabilities ed i punti di attenzione
● una prospettiva esterna può essere utile
Se si decide di procedere
4. Sperimentare, eventualmente appoggiandosi ad un partner già esperto
● rende evidenti i punti di attrito
● aiuta a superare la diffidenza al cambiamento

26. Agility cannot be imposed from the top, simply because good
agile practices have to be discovered by the people using them.
Dave Thomas

27. OptionFactory
Thanks!
http://optionfactory.net
francesco.degrassi@optionfactory.net