Cosa ho imparato trasformando software factory?
- 1. 1 Cosa ho imparato trasformando software factory? Matteo Emili [email protected] @MattVSTS https://mattvsts.blogspot.com
- 2. #DOH18 2 Organizer & sponsors GetLatestVersion.it
- 4. CHI SONO? • Systems Engineering Advisor @ One Identity • Microsoft MVP – Developer Technologies • Professional Scrum Master 1 • Microsoft Certified Technology Specialist: Team Foundation Server • Technology enthusiast
- 5. DI SOLITO NON IMPORTA…
- 7. QUINDI, CHI SONO? • Persona con tanti (troppi?) interessi • Apprendo velocemente ed ho sempre interesse in qualcosa di nuovo • A chi interessa: in casa rack 12U con homelab rispettabile • Nella community tecnologica da…tempo immemore • Iniziato a bloggare a 17 anni, presentare ad eventi tecnici a 19, poi Microsoft MVP • I miei interessi principali nel mondo tech: architettura, ALM, qualitá • Parlato di DevOps sullo stack Microsoft (WinOps?) per la prima volta nel 2012
- 8. PROFESSIONALMENTE? • Sviluppatore e smanettone autodidatta • Primo contratto come sviluppatore durante le scuole superiori (tre pomeriggi a settimana) • Il codice era ‘interessante’ per me, ma scriverlo bene e portare valore non tecnologico mi interessava di piú • Ovunque sia stato il mio nome é sempre stato associato a TFS, ALM, etc. • Sono stato esposto a diversi tipi di industria
- 10. A CHI NON PIACCIONO I PATTERN? • L’idea é nata parlando con Giulio Vian ed altri membri della community GetLatestVersion.it • Ci chiediamo regolarmente ‘come risolvo questo?’ oppure ‘quali benefici mi apporta quest’altro?’ con problemi che spaziano dal business al dettaglio tecnologico • Nonostante ognuno di noi dia risposte differenti, nel tempo ho realizzato che ci sono pattern di situazioni e di reazioni tipiche specialmente nei progetti di trasformazione • Ho iniziato a scavare nel mondo della psicologia, ed ho aperto il vaso di Pandora!
- 11. DEFINISCI TRASFORMAZIONE! Una trasformazione ‘legacy to modern’ puó essere… • Virtualizzazione o containerizzazione • Da Waterfall a Scrum/Lean/… • Zip a Version Control System • Excel verso Jira • Dai deploy manuali nel weekend verso la Continuous Delivery • Consolidare gli stack ALM/DevOps • Practice establishment • Monoliti a microservice • …
- 13. LA TECNOLOGIA NON CONTA
- 14. LA TECNOLOGIA É UNO STRUMENTO
- 15. TUTTI FANNO LA STESSA COSA
- 16. CAMBIARE
- 17. LE AZIENDE SONO FATTE DI PERSONE
- 18. LA PSICOLOGIA PORTA AL SUCCESSO
- 19. PERCHÉ? IL CASO IN OGGETTO: L’ESSERE UMANO Non promette bene… • Paura del cambiamento • Innato istinto ad evitare il rischio • Valuta la conoscenza tribale come importante • Esperienze soggettive vs esperienze oggettive • Credenze irrazionali • Soffre la pressione di gruppo o di prestazione • … Un profilo psicologico
- 20. NON TUTTO É PERDUTO
- 21. ANCHE NOI SIAMO ESSERI UMANI
- 22. CI SONO DELLE SOLUZIONI
- 23. TIPO?
- 24. CONSOLIDAZIONE DELLO STACK ALM AZIENDALE L’azienda ABC decide di consolidare gli stack di ALM a livello aziendale con una soluzione di un singolo vendor, unificando anni (decadi?) di proprietá intellettuale nello stesso posto É un enorme sforzo aziendale che migliorerá massicciamente come il software é sviluppato internamente e permetterá maggiore apertura Scenario #1
- 25. UN ESEMPIO PRATICO • Atlassian Suite+Trello+Excel+Custom & SVC+CVS+Git+SourceSafe • Tutto spostato e consolidato su TFS o Azure DevOps • É un cambiamento *enorme* • C’é un livello importante di investimento richiesto
- 26. COSA SUCCEDERÁ? • La gente inizierá a lamentarsi • Alcuni gruppi/dipartimenti faranno seria resistenza • Alcune persone si lamenteranno dicendo ‘Non riesco ad essere produttivo! Tutto é stato spostato! Non trovo piú nulla!’ • Qualcuno potrebbe rendere la vita molto difficile • Ho anche visto esempi di sabotaggio negli anni…
- 27. COSA PROBABILMENTE SUCCEDERÁ? • L’iniziale resistenza é molto debole o passiva • Di solito é fomentata da ‘capi tribú’ • Le persone tendono a seguire ció che conosce, per istinto innato (‘se funziona…’) • Altrettanto importante: cambiamento significa ripartire, azzerare e ricominciare • Non siamo abituati a farlo!
- 28. COSA POTREBBE ACCADERE? • Sana competizione interna • Farsi avanti per supportare l’iniziativa • Collaborazione fra gruppi per creare asset riciclabili ed effettuare knowledge sharing • Completare il progetto prima possible per tornare alle normali attivitá il prima possibile
- 30. COSA HO IMPARATO • Fare leva sui risultati tangibili e materiali • La tempistica giusta fa la differenza, ma affrettarsi non paga • La percezione incrementale é essenziale • Riciclare la conoscenza pre-esistente permette di raggiungere anche il piú ostile • I ritardi sono normali, succedono, nessuno dará problemi se la percezione incrementale é forte
- 32. INCREMENTALE É LA CHIAVE!
- 33. PERCHÉ É COSÍ IMPORTANTE? • Approcci iterative ed incrementali sono quelli che giocano sulla motivazione dell’individuo • Tempistiche ridotte ed un flusso continuo di prodotti finite fanno sentire il team in controllo • É un circolo vizioso positive: il team é sicuro di se e prende delle decisioni basate sul proprio ritmo ed esperienza • Questo é un caso in cui si puó far leva sulla conoscenza tribale a proprio vantaggio – un team che si autogestisce é sicuramente piú produttivo di uno gestito dall’alto • É inoltre l’unico modo per confutare la legge di Parkinson!
- 34. LA LEGGE DI PARKINSON?
- 35. IL LAVORO É COME IL GAS IDEALE
- 36. …O LA BUROCRAZIA
- 37. IL LAVORO SI ESPANDE PER RIEMPIRE IL TEMPO A DISPOSIZIONE
- 38. INDIPENDENTEMENTE DA TUTTO, IL TEAM SARÁ SEMPRE ‘IMPEGNATO’
- 39. NEL TEMPO IL VALORE PRODOTTO DA UN TEAM ‘SEMPRE IMPEGNATO’ CALA
- 40. DAVVERO? • Se il team é effettivamente sovraccarico la qualitá del consegnato sará bassa • Ci saranno sempre piú bug ed il debito tecnico andrá alle stelle • Se il team ha capacitá libera (ma sta aderendo alla legge di Parkinson) inizierá a focalizzarsi sui dettagli piú futili • Il consegnato sará sempre piú ridotto e ci sará una grossa enfasi sui piccolissimi cambiamenti implementati In both cases, value is low
- 41. WATERFALL TO AGILE Azienda XYZ decide di saltare sul treno di Agile, eliminare il suo inefficiente processo basato su Waterfall ed abbracciare l’Agile É una iniziativa guidata dall’alto, dove il management vuole recuperare il distacco dai temi trendy del mercato ed impedire che l’azienda rimanga perennemente dietro ai concorrenti Scenario #2
- 42. CI SONO UN PAIO DI CAMPANELLI DI ALLARME QUI…
- 43. …ABBRACCIARE L’AGILE… …RECUPERARE IL DISTACCO…
- 44. REAZIONI CAUSATE DAL PANICO ED APPROCCI MOLTO PESANTI
- 45. COME FARLO FUNZIONARE? • Un training veloce ed informale é sufficiente per far partire l’adozione di Scrum • Scum é perfetto per questo: stravolge le tempistiche ma ha un iter molto definito • Essendo imposto, non c’é bisogno di comparazioni a questo momento • Prendi una porzione del prodotto ed inizia ad implementare un backlog • Lo sforzo collaborativo rende il passaggio da pianifcazione a delivery abbastanza semplice • Scrum é solo l’inizio. Lean? Scrum? Scrumbut? L’evoluzione dipende dal team
- 46. MAGIA? • La morale del team é fondamentale • Lo sviluppo di un software é uno sforzo di gruppo • Le persone dovrebbero sentirsi motivate, non depresse perché il management ha avuto un altro cambio di umore • Le metodologie agili mettono tutti sullo stesso livello, quindi le contribuzioni individuali hanno grande peso • La difficoltá di decidere come procedure é rimossa – in questo caso puó essere positivo • I miglioramenti possono essere portati avanti basandosi su esperienze tangibili
- 47. SPESSO SONO I FONDAMENTALI A FARE LA DIFFERENZA
- 48. LA TEMPESTA PERFETA • Immaginiamo una situazione dove una azienda vuole investire in telemetria (sia reattiva che proattiva) • C’é un numero X di persone nel ‘Team della Telemetria’ • Il management crede che sará davvero efficace: una combinazione di decisioni basate sui dati ed intelligenza artificiale che fará spendere in modo migliore il tempo e le risorse allocate a R&D • Cosa *realmente* potrebbe accadere? Scenario #3 (fittizio)
- 50. MENO É DI PIÚ • Distorsione cognitiva dove persone di bassa abilitá hanno una illusoria superioritá e giudicano erroneamente le proprie capacitá come superiori di quello che sono • Inoltre persone di elevate abilitá assumono incorrettamente che attivitá per loro facili siano ugualmente facili per altre persone Source: Wikipedia
- 51. MENO É DI PIÚ • Esempi comuni si trovano in persone appena uscite da scuola/universitá, ma chiunque puó esserne affetto • É sorprendentemente comune in una categoria di sviluppatori: quelli che hanno lavorato per un lungo periodo di tempo con tecnologia legacy e sono improvvisamente introdotti in un ambiente completamente nuovo • La soluzione é relativamente facile: abbinare una persona in fase di on- boarding o mentoring interno quando richiesto • Normalmente é un buon segno, di una persona motivate a migliorare dopo aver perso la sua illusoria superioritá
- 53. PIÚ SAI, PEGGIO É • Pattern psicologico dove l’individuo dubita dei propri risultati ed ha una paura interna di essere ‘scoperto’ • Evidenze di risultati tangibili vengono scartate o minimizzzate come ‘fortuna’, ‘posto giusto al momento giusto’, ‘tempismo perfetto’ Source: Wikipedia
- 54. PIÚ SAI, PEGGIO É • Estremamente comune negli sviluppatori ad altissimo potenziale ed individui di successo • La ragione dietro a questo comportamento é che gli standard personali di questi soggetti sono molto piú alti di quelli aziendali • Review peer-to-peer non fanno che peggiorare la situazione • I media non aiutano quando parlano di tecnologia • É molto pericolosa perché puó facilmente portare al burnout (esaurimento)
- 55. PIÚ SAI, PEGGIO É • Affrontare questa sindrome come cambiamento non é facile • Nessuno mai dirá ‘credo che non dovrei essere qui’ • Il modo migliore di approcciare il problema é di sfruttare canali di feedback interni (standup meeting?) • Le persone si sentiranno motivate e spronate a contribuire, portando ad una migliore consapevolezza • Sfortunatamente non é un processo semplice
- 56. SUPREMAZIA DEL TIPO ALPHA
- 57. I AM ONLY HUMAN, AFTER ALL… • Le persone sono naturalmente polarizzate intorno o contro l’elemento alpha del team • L’analisi della telemetria é un caso da rendere il piú automatizzato possible (ecco uno dei motivi della crescita esponenziale della telemetria proattiva) • Essendo il processo guidato dai dati, mescolare una delle ‘sindromi’ precedenti con un element alpha significa che il risultato del lavoro del ‘Team della Telemetria’ sará naturalmente parziale • Non si puó evitare, fa parte dell’indole umana – si puó solo mitigare
- 58. COMPETIZIONE
- 59. I AM ONLY HUMAN, AFTER ALL…DI NUOVO! • Due esseri umani che condividono la stessa attivitá ripetitiva saranno sicuramente in competizione • Proporzionalmente al livello di competizione (specialmente se sono coinvolti degli incentivi) il numero di falsi positive aumenterá • Oppure il contrario – se ci sono dei fattori negativi nella valutazione il livello di segnalazioni sará piú basso dell’atteso • Mai, mai, mai introdurre competizione in un team!
- 60. UN PAIO ANCORA PER CHIUDERE
- 61. LA LEGGE DI PUTT
- 62. UNA SITUAZIONE BINARIA • La tecnologia é dominata da due tipi di persone: chi capisce cosa non gestisce e chi gestisce cosa non capisce • Nel tempo ogni gerarchia tecnica verrá invertita dalla competenza Source: Wikipedia
- 63. UNA SITUAZIONE BINARIA • Tantissime persone non vogliono essere promosse a ruoli di ‘management’ • Dall’altro lato, ci sono persone che sono nella media in ruoli tecnici ma hanno un ottimo senso del business o di gestione delle relazioni personali • É il dovere di una buona azienda identifcare queste persone e farle esprimere al meglio • L’azienda puó solo guadagnare da questo approccio, facendo leva sulle migliori competenze delle proprie persone ed avendo un team estremamente motivato Source: Wikipedia
- 64. IL PRINCIPIO DI PETER
- 65. INCOMPETENZA?! • Una persona che é competente nel proprio lavoro avrá una promozione ad un livello superiore che richiederá competenze diverse • Se la persona promossa manca di queste competenze avrá un nuovo livello di incompetenza, e non sará promossa di nuovo • Ma se la persona é ancora competente nel nuovo ruolo sará promossa ancora, e continuerá ad esserlo finché non raggiungerá un livello in cui sará incompetente • Essendo incompetente, questa persona non verrá piú promossa e rimarrá bloccata allo stesso livello fino alla fine della sua carriera Source: Wikipedia
- 66. SUONA FAMILIARE? • Sembra vada a braccetto con la politica aziendale • Molto comune in aziende con grandi strutture rigide (livelli, gradi, etc) • Al momento non esiste soluzione – se non molta attenzione! Source: Wikipedia
- 67. DOMANDE?