Sessione tenuta a DevOpsHeroes 2018 sulla psicologia dei team e del management durante processi di trasformazione tecnologica.

1. 1
Cosa ho imparato trasformando
software factory?
Matteo Emili
matteo.emili@live.com
@MattVSTS
https://mattvsts.blogspot.com

2. #DOH18 2
Organizer & sponsors
GetLatestVersion.it

3. DI CHE PARLIAMO?
PERSONE
COMPORTAMENTI
PSICOLOGIA
REAZIONI

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…

6. …TRANNE STAVOLTA.

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

9. PERCHÉ QUESTA SESSIONE?

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
• …

12. TRASFORMAZIONE É DISAGIO

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

29. COSA HO IMPARATO?

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

31. INCREMENTALE É TUTTO

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)

49. L’EFFETTO DUNNING-KRUGER

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á

52. SINDROME DELL’IMPOSTORE

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?

68. #DOH18
THANK YOU!