Sessione tenuta a DevOpsHeroes 2017 su approcci per rendere Continuous Delivery praticabile in modo trasversale all'azienda, con attenzione particolare al middle management.

1. #DOH17

2. 2
Far scalare la Continuous Delivery
per il middle management
Matteo Emili
Microsoft MVP
matteo.emili@live.com || @MattVSTS
http://mattvsts.blogspot.com

3. 3
Organizer & sponsors
GetLatestVersion.it

4. 4
Il viaggio verso Continuous Delivery
• Non é facile implementare un processo di Continuous Delivery
da zero
• Diversi strati di costi
• Ostacoli tecnici, metodologici, culturali
• Le ragioni? Svariate – ma principalmente l’umana resistenza al
cambiamento
• Prerequisito #0: accettare il cambiamento portato da CD

5. 5
Continuous Delivery Champion
• Il CDC é qualcuno che spinge ed evangelizza i concetti di
Continuous Delivery in modo trasversale all’azienda
• I CDC sono normalmente membri dei team di sviluppo o
appartenti al top management
• Sono persone che vogliono portare i benefici ed il valore di
Continuous Delivery tramite l’adozione delle best practice
• Si scontrano spesso con diversi ostacoli: culturali, tecnici,
metodologici
• Ha un grosso difetto di partenza: parte sempre da un
approccio basato sulla propria esperienza

6. 6
Il middle management
• Il middle management é solitamente lo strato piú critico per
un tale cambiamento
• É isolato dai due possibili estremi dei CDC perché é
responsabile dei risultati dei suoi team, ma é escluso dalle
decisioni strategiche del top management
• Questa disconnessione lo separa dalle prioritá del CDC
• La normale reazione é di alzare delle barriere, causando
frizioni e fraintendimenti

7. 7
La legge di Conway
• “organizations which design systems ... are constrained to
produce designs which are copies of the communication
structures of these organizations”
• The Mythical Man-Month – Fred Brooks, 1975

8. The CALMS
Framewor
k
Culture Automation
Sharing Metrics
Lean

9. 9
Problemi affrontati adottando e scalando l’Agile
Dal 11th Annual State of Agile Report - https://explore.versionone.com/state-of-agile

10. 10
Un problema ulteriore: DevOps
• Continuous Delivery e DevOps sono strettamente correlate
• DevOps non ha una definizione!
• Non é un processo, non é una metodologia, non é una
tecnologia
• Non esiste un DevOps Enterprise Edition da installare…
• DevOps é una collezione di best practice dove l’intera
organizzazione é coinvolta nel portare del valore al proprio
cliente
• Inoltre ci sono diverse metodologie che possono essere
utilizzate, il che porta ad ulteriore confuzione

11. 11
The Three Ways
• The Phoenix Project é una storia di fantasia di
una organizzazione come tante altre…
• Uno dei concetti fondamentali é l’uso delle
Three Ways – tre principi fondamentali
• Sono applicabili ad ogni contesto, dall’IT alla
produzione manifatturiera
• La maggior parte delle pratiche di DevOps e di
Continuous Delivery sono derivate da questi
tre principi

12. 12
Flow

13. 13
Feedback

14. 14
Continuous Learning

15. 15
Basta barriere e piccoli cambiamenti
• Le barriere sono il problema principale in una trasformazione
verso Continuous Delivery, impediscono l’implementazione
della First Way
• Con barriere erette fra gruppi diversi dell’organizzazione é
impossibile creare un sistema di feedback trasversale (Second
Way)
• I cambiamenti devono essere implementati in modo granulare
ed iterative
• Basta con i big bang che cambiano tutto
• L’automazione aiuta a rimuovere tutte le cattive abitudini ereditate
da anni di processi tradizionali

16. 16
Il Minimum Viable Product
• Iniziate con qualcosa di piccolo, dove un downtime o un
problema tecnico non causa enormi problemi
• Portarlo in produzione é essenziale – un piccolo set di feature
funzionanti ed autonome
• Costruire in modo incrementale ed iterativo su questo
principio
• Perché? Si possono validare rapidamente le idee e verificare se
il prodotto creato corrisponde ai requisiti richiesti

17. 17
E gli strumenti?
• Gli strumenti che utilizziamo contribuiscono alla segregazione
• Ogni piattaforma dovrebbe essere aperta a chiunque,
indipendentemente dal gruppo di appartenenza
• Chiudere lo stack di ALM ai ruoli non strettamente tecnici
(Product Manager, supporto, etc.) é una pessima idea, che
porta ad una frammentazione delle informazioni
• É necessario tendere ad una realtá dove esiste solo un unica
fonte dove reperire le informazioni necessarie al
progetto/prodotto

18. 18
Troviamo un terreno comune
Dal 11th Annual State of Agile Report - https://explore.versionone.com/state-of-agile

19. 19
I dati sono imparziali
• Con una piattaforma unificata state creando una fonte unica
ed imparziale di dati per l’intera azienda
• Piú la piattaforma si espande attraverso l’organizzazione,
meglio si puó utilizzarla per approcciare il problema CD
• Coinvolgere livelli superiori dell’azienda permette di avere
una vista estesa di come una certa storia rientri all’interno
della strategia generale
• Non esiste “uno strumento per
sviluppatori/business/operation” – tutti gli strumenti di ALM
moderni sono pensati per essere utilizzati da diversi ruoli con
client differenti

20. 20
Qual é il tuo campo di azione?
• Il middle management é solitamente schiacciato nel mezzo
dell’approccio che il CDC decide di utilizzare
• É complesso garantire loro la stessa visibilitá dei benefici di
Continuous Delivery rispetto ad un estremo
• Il loro campio di azione é superiore a quello dei singoli team, ma
é inferiore alla vision e alla strategia del top management
• Quello che solitamente conta é quante feature sono rilasciate,
magari correlate con le Epic/Theme di appartenenza, ma sempre
in relazione con le User Story che i Product Owner forniscono

21. 21

22. 22
Un esempio pratico
Il backlog non é solo per le PBI

23. 23
Il backlog non é solo per le PBI
• Lo strumento che utilizzate deve essere in grado di poter
creare visualizzazioni verticali da Epic a PBI, pur mantenendo
una visione di insieme
• Con specifiche eccezioni, le PBI non interessano davvero al
middle management
• Il backlog é relativo – quello che conta davvero é ció che é in
corso e quello che é completato
• Il valore portato dalle attivitá in corso é al centro del
palcoscenico, i dettagli tecnici vengono dopo

24. 24
Come posso iniziare?
• Iniziare con poco, con filtri ad esempio – é importante rendere
il backlog una presenza permanente in ogni contesto,
personalizzato per mostrare i dati voluti
• Utilizzare le relazioni fra gli artefatti (Parent-Child, Related,
etc.)
• Utilizzare uno strumento accessibile via Excel
• Accoppiare lo strumento con qualcosa che dia visibilitá ad alto
livello delle release attraverso iterazioni multiple

25. 25
Non perdere il treno
Delivery Plan in TFS e VSTS

26. 26
Product Owner? Ti presento il cliente!
• Il Product Owner deve conoscere le reali richieste della sua
utenza, ed il modo migliore é attraverso un contatto diretto
• La strategia dovrebbe essere focalizzata sul cliente, sui suoi
feedback e le prioritá dovrebbero essere dettate da quello che
il cliente vuole davvero
• Il Product Owner e chi sopra di lui devono essere in accordo
sull’esecuzione di questa strategia

27. 27
Come rendo le cose ragionevoli?
• “Non puoi cambiare quello che non puoi misurare”
• Nel loop Build-Measure-Learn il secondo passaggio é il piú
importante
• Misurando si ottengono evidenze imparziali di quello che va
sostituito o migliorato
• Solo le metriche possono dire se si va nella direzione giusta,
quindi é fondamentale averne ed averne di giuste!

28. 28
I vantaggi?
• Il prodotto viene esteso solo con quello che davvero conta
• Si riducono i costi di manutenzione
• Potenziali problem vengono spesso individuati in modo
proattivo
• Il budget di R&D é speso in modo sensato, basandosi sulle
necessitá del cliente

29. 29
Uno strumento essenziale: la telemetria
• Avere la telemetria a bordo delle nostre applicazioni ci
fornisce informazioni essenziali
• Problemi tecnici
• Utilizzo dell’applicazione da parte degli utenti
• Un esempio reale: la nuova ‘eccezionale feature che dovrebbe
cambiare il mercato’ su cui é stata spesa una considerevole
quantitá di risorse non é usata da nessuno
• Seppellita sotto sette interazioni utente differenti: problema di UX
• Il Product Owner rimane nella sua torre di avorio, ignaro di quello che
il cliente vuole

30. 30
Utilizziamo la Telemetria
Reattiva e proattiva con Application Insights

31. 31
Prima le persone, poi i processi, i tool seguiranno
• Il primo passo é raggiungere un terreno comune a tutti, le
persone costruiscono i processi necessari, lo strumento
utilizzato é un mero dettaglio
• Rimuovere i colli di bottiglia
• Facilitare la comunicazione
• Iniziare da qualcosa di piccolo e costruire in modo iterative
• Mostrare evidenze ed accumulare dati obiettivi ed utili

32. 32
Condivisione prima di tutto
• La condivisione delle informazioni abate le barriere e favorisce
il miglioramento continuo
• Ogni ruolo nell’azienda deve avere accesso a quello che sta
succedendo
• Stabilire un linguaggio comune, condiviso da tutti
• Il management non tecnico dovrebbe avere un’idea chiara
della direzione del prodotto
• Gli stakeholder e i client sono parte del processo, non sono
separati

33. 33
Chiudere il cerchio con i feedback
• Il cliente é al centro di tutto, si lavora sulla base di quello che
l’utenza desidera
• Feedback e dati telemetrici, insieme a dati interni, fanno
capire se la direzione intrapresa é corretta
• Validazione veloce delle idee con utilizzo reale
• Si crea qualcosa per il cliente, il cliente condivide le sue
prioritá e le facciamo nostre
• Tutti ne hanno vantaggio, dagli sviluppatori ai Product Owner

34. THANK YOU!
#DOH17 Slide disponibili su http://slideshare.net/matteoemili