Fare pipì controvento
•Download as KEY, PDF•
8 likes•2,198 views
La mia presentazione a Better Software 2012, arricchita di contenuti speciali.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Fare pipì controvento
Similar to Fare pipì controvento (20)
More from Alberto Brandolini
More from Alberto Brandolini (20)
Fare pipì controvento
- 2. About me In the IT field since ZX Spectrum Generally in large scale projects (I might be biased) Strategic IT Consultant Trainer (Avanscoperta & Skills Matter) Technical Writer Blogger: http://ziobrando.blogspot.com Twitter: @ziobrando My e-mail: alberto.brandolini@gmail.com
- 3. What I do Agile processes Domain-Driven Design Efficiency & Management Architecture Funny clown 9% 11% 38% 12% 31%
- 4. Persone intelligenti che prendono decisioni non intelligenti
- 6. Ma prima...
- 7. Antefatto
- 9. Affetto?
- 14. Ma per noi...
- 15. È affettuoso È pigro È bastardo È carino È furbo
- 16. Attrito e come Scrum e Kanban affrontano il problema
- 17. Scrum Roles Team Scrum Master Product Owner
- 18. Perchè proprio i
- 20. Team Team Scrum Master? Product Owner
- 21. Team Team Scrum Master? Product Owner
- 22. Team Team Team Leader? Scrum Master? Product Owner
- 23. Team Team Team Leader? Scrum Project Master? Product Owner
- 24. Team Team Team Leader? Scrum Project Consulente? Master? Product Owner
- 25. Team Team Team Leader? Scrum Project corso? Consulente? Master? Product Owner
- 26. Team Team Team Leader? Scrum Project corso? Consulente? Master? ? Product Owner
- 27. Team Team Team Leader? Scrum Project corso? Consulente? Master? ? ? Product Owner
- 28. Scrumbut
- 29. Buono come il ragù di seitan
- 30. oppure..
- 31. Scrum non funziona, proviamo altro
- 32. Kanban • Inizio “leggero” • Non tocchiamo l’organizzazione
- 33. Apparentemente De v Te a m at io n ga niz Or
- 34. Sistemando le
- 36. It’s always an IT problem until it’s proved not to be. I’ve been involved in agile teams where I’ve seen improvements on the technical side expose shortcomings and failures on the business side. When delivery is predictable the bottleneck shifts into the business. By delivering high quality software that just works, continuous feedback from customers and the measurement of realized benefits often reveals poor decision- making in other parts of the organization. Simon http://nobull.energizedwork.com/
- 37. Non sono sempre contenti...
- 38. Resistenza
- 39. Il nostro ruolo
- 40. A ragione? A torto?
- 41. A ragione? A torto? Implementazioni imbarazzanti
- 42. A ragione? A torto? Implementazioni imbarazzanti Ritardi cronici
- 43. A ragione? A torto? Implementazioni imbarazzanti Ritardi cronici incapacità di far fronte agli impegni
- 44. A ragione? A torto? Implementazioni imbarazzanti Ritardi cronici incapacità di far fronte agli impegni ...
- 45. A ragione? A torto? Implementazioni Vincoli, policy, etc. imbarazzanti Ritardi cronici incapacità di far fronte agli impegni ...
- 46. A ragione? A torto? Implementazioni Vincoli, policy, etc. imbarazzanti requisiti ballerini Ritardi cronici incapacità di far fronte agli impegni ...
- 47. A ragione? A torto? Implementazioni Vincoli, policy, etc. imbarazzanti requisiti ballerini Ritardi cronici Incapacità di capire l’IT incapacità di far fronte agli impegni ...
- 48. A ragione? A torto? Implementazioni Vincoli, policy, etc. imbarazzanti requisiti ballerini Ritardi cronici Incapacità di capire l’IT incapacità di far Politiche salariali fronte agli impegni ...
- 49. A ragione? A torto? Implementazioni Vincoli, policy, etc. imbarazzanti requisiti ballerini Ritardi cronici Incapacità di capire l’IT incapacità di far Politiche salariali fronte agli impegni Blocco sulle scelte coraggiose ...
- 50. “Non è tutto bianco o nero” Pierrot
- 51. “Non è tutto bianco o nero” A. Del Piero
- 52. By the way... circa il 90% di voi ha pensato “Alex del Pierrot”
- 53. ...e sarà la cosa che ricorderete di più di tutta la presentazione
- 54. Che lo vogliate o no
- 55. Il cervello è una brutta bestia...
- 56. Torniamo a noi
- 57. 0 Sono veramente impressionato dai vostri progressi, ragazzi
- 59. Gli dei sono
- 60. Al rogo la strega!
- 61. È colpa dell’IT!
- 62. Cerchiamo un nesso causale semplice
- 63. ...ma in un sistema complesso, la spiegazione non può mai essere semplice
- 65. Siamo fatti così
- 67. Sistema
- 68. Sistema Risposte associative immediate
- 69. Sistema Risposte associative immediate Parallelismo ... anche involontario
- 70. Sistema Risposte associative immediate Parallelismo ... anche involontario Basso consumo
- 71. Sistema Risposte associative immediate Parallelismo ... anche involontario Basso consumo Sistema
- 72. Sistema Risposte associative immediate Parallelismo ... anche involontario Basso consumo Sistema Risposte complesse che richiedono concentrazione
- 73. Sistema Risposte associative immediate Parallelismo ... anche involontario Basso consumo Sistema Risposte complesse che richiedono concentrazione Incapace di parallelismo
- 74. Sistema Risposte associative immediate Parallelismo ... anche involontario Basso consumo Sistema Risposte complesse che richiedono concentrazione Incapace di parallelismo Elevato consumo
- 75. Il gatto
- 76. Torniamo a Scrum
- 78. Organigramma
- 79. Lo conoscete
- 80. Divide et impera
- 81. da a 1 iat a Divide et impera Bo tem sis
- 84. 2 problemi: Decisioni prese nel posto sbagliato Decisioni prese nel modo sbagliato
- 85. “Hai 2 persone in più... consegnerai prima”
- 86. “Invece di un Senior abbiamo assunto 2 Junior”
- 87. “Invece di un Senior abbiamo assunto 2 Junior”
- 88. “Invece di un Senior abbiamo assunto 2 Junior” -Linearità di rendimento (falso)
- 89. “Invece di un Senior abbiamo assunto 2 Junior” -Linearità di rendimento (falso) -Proporzione lineare tra costo e valore (falso)
- 90. “Invece di un Senior abbiamo assunto 2 Junior” -Linearità di rendimento (falso) -Proporzione lineare tra costo e valore (falso) -Costi di avviamento lineari (falso)
- 91. “Intanto vai avanti con le altre cose”
- 92. “Intanto vai avanti con le altre cose”
- 93. “Intanto vai avanti con le altre cose” -Costo nullo del context switch (falso)
- 94. “Intanto vai avanti con le altre cose” -Costo nullo del context switch (falso) -Le attività lasciate aperte restano ferme (falso)
- 95. “Intanto vai avanti con le altre cose” -Costo nullo del context switch (falso) -Le attività lasciate aperte restano ferme (falso) -Fare è sempre meglio di non fare (falso)
- 99. Decisioni Devo convincere il mio capo a lasciarmi fare questa cosa... Informazioni
- 100. Non ho capito di cosa sta parlando... Decisioni Devo convincere il mio capo a lasciarmi fare questa cosa... Informazioni
- 101. Non ho capito di cosa sta parlando... Decisioni Ma dico comunque Devo convincere il qualcosa! mio capo a lasciarmi fare questa cosa... Informazioni
- 103. Versailles Antipattern Oggi il capo non è dell’umore giusto
- 104. Versailles Antipattern Oggi il capo non è dell’umore giusto Bisogna che mi aiuti a convincerlo
- 105. Versailles Antipattern Oggi il capo non è dell’umore giusto Bisogna che mi aiuti a convincerlo Bisogna che ci copriamo a vicenda
- 106. Versailles Antipattern Oggi il capo non è dell’umore giusto Bisogna che mi aiuti a convincerlo Bisogna che ci copriamo a vicenda Ho sentito che lui ha detto che...
- 107. Waste
- 108. Cortigiano nasce per risolvere problemi di linguaggio tra il re, i dignitari ed il popolo. Si evolve diventando filtro. Potere variabile
- 109. Cortigiano nasce per risolvere problemi di linguaggio tra il re, i dignitari ed il popolo. Si evolve diventando filtro. Potere variabile
- 110. Cortigiano nasce per risolvere problemi di Richelieu linguaggio tra il re, i dignitari ed il popolo. Si evolve diventando filtro. Potere variabile
- 111. Cortigiano nasce per risolvere problemi di Richelieu linguaggio tra il re, i dignitari ed il popolo. Si evolve diventando filtro. Potere variabile
- 112. Cortigiano nasce per risolvere problemi di Richelieu linguaggio tra il re, i dignitari ed il popolo. Si evolve diventando filtro. Potere variabile Alfano
- 113. Waste
- 114. Questi sono problemi di qualsiasi organizzazione
- 115. ...ma Agile ci va a sbattere contro
- 116. Sviluppare software è un continuo processo di decision making
- 117. Come posso uscire dal blocco?
- 118. Ideologia?
- 119. O ! N Ideologia?
- 122. Delegation Matrix Stime Design Ferie Budget Tell Sell Consult X Agree Advise X Inquire X Delegat X e
- 123. Verso il Nirvana responsibility Anarchia Perdita di controllo Skills Frustrazione Conflitti Turnover
- 124. Verso il Nirvana responsibility Anarchia Perdita di controllo o gn Skills So Frustrazione Conflitti Turnover
- 125. Verso il Nirvana responsibility Anarchia Management’s view Perdita di controllo o gn Skills So Frustrazione Conflitti Turnover
- 126. Verso il Nirvana responsibility Anarchia Management’s view Perdita di controllo o gn Skills So Frustrazione Conflitti Team’s view Turnover
- 127. (In)competenza
- 128. Learning
- 129. Come gestisce il feedback?
- 131. Gavetta
- 132. Cosa vuoi che sappiano fare?
- 133. Cosa vuoi che sappiano fare?
- 134. La piramide è stabile
- 135. Recruiting Strategy
- 137. La tentazione del nonnismo
- 138. Siamo buoni maestri?
- 139. NO
- 140. Incompetenza Mancanza di alternative Paura Immobilismo
- 141. Bingo! basso livello di competenze in azienda Università La piramide produce Gavetta si rinforza incompetenti Frustrazione Omologazione per chi impara per chi resiste Università in fretta non impara Fuga di talenti
- 142. Potenziale
- 143. Decision Making
- 145. Sappiamo prendere decisioni come team?
- 146. Skills
- 147. Stress
- 148. Stress Risposta psicologica Condizione percepita come avversa Condizione percepita come inevitabile
- 149. Il cervello non è più in grado di imparare
- 150. Resistenza?
- 151. Bingo! La piramide La piramide si rinforza genera stress Bassi livelli di Non si impara competenza in condizioni giustificano la piramide di stress
- 152. Conclusioni?
- 154. Abbiamo risorse limitate: In determinati momenti, meglio NON prendere decisioni.
- 155. Alcune decisioni possono NON essere prese (ed essere prese lo stesso)
- 156. decidere vs fare succedere
- 157. 3 mosse per cambiare Istruzioni razionali “botta” emotiva rimozione ostacoli
- 158. (Non) è un problema dell’ IT
- 159. La piramide è il problema
- 160. IT Department
- 161. IT Department casino
- 162. IT Department casino ca sino
- 163. IT Department casino casino ca sino
- 164. CASINO! IT Department casino casino ca sino
- 165. CASINO! IT Department casino casino ca sino
- 166. CASINO! IT Department casino casino ca sino
- 167. CASINO! IT Department casino casino ca sino
- 168. CASINO! IT Department casino casino ca sino
- 169. CASINO! CASINO! IT Department casino casino ca sino
- 170. Dogfood effect
- 171. Chi fa la prima
- 172. O ! N Chi fa la prima
- 173. Ci sono alternative alla piramide www.betacodex.org
- 174. Non siamo soli
- 175. Non siamo soli Agile
- 176. Non siamo soli Lean Agile
- 177. Complexity Science Non siamo soli Lean Agile
- 178. Complexity Science Non siamo soli Lean Agile
- 179. Complexity Science Non siamo soli Lean Agile
- 180. Complexity Science Management 3.0 Non siamo soli Lean Agile
- 181. Complexity Science Management 3.0 Beyond Budgeting Non siamo soli Lean Agile
- 182. Complexity Science Management 3.0 Beyond Budgeting Non siamo soli #Stoos Lean Agile
- 183. Complexity Science Management 3.0 Beyond Budgeting Non siamo soli #Stoos Lean Agile Radical Management
- 184. Domande?
- 185. Grazie @ziobrando alberto.brandolini@avanscoperta.it www.avanscoperta.it
Editor's Notes
- \n
- \n
- \n
- Questo è il problema di cui voglio parlare oggi. Abbiamo il privilegio di lavorare in un settore dove le persone sono decisamente intelligenti, ma prigioniere di scelte che sono stupide fino a sfiorare l’autolesionismo.\n
- E questo è il mio modesto contributo sul tema.\n
- Io ci provo, ad applicare princìpi di storytelling. Ma con me non funziona: nella mia testa storytelling è il Tarantino di “Pulp Fiction”, Bryan Singer de “I soliti sospetti”. Non sono capace di fare una storia lineare. :-(\n
- Per cui comincio da qui.\n
- Da un bel gattino accoccolato sulle ginocchia a prendere qualche carezza.\n
- Gesto che noi istintivamente associamo a concetti come l’affetto.\n
- In realtà non è così. Si tratta di qualcosa di molto più banale.\n
- Il gatto sostanzialmente ottimizza il consumo di calorie necessaria alla sopravvivenza. Come cacciatore (nel passato...) deve ottimizzare il consumo di risorse, perché le prede andrebbero comunque catturate.\nQuindi dorme a pallina, riducendo la dimensione della superficie radiante di epidermine esposta all’aria.\n
- A meno che non sia disponibile una superficie calda cui appoggiarsi nel qual caso massimizza l’epidermide esposta al calore.\n
- In condizioni di caldo invece massimizza l’esposizione al vento per aumentare lo smaltimento di calore.\n
- L’equazione è complessa, ma il gatto non ha bisogno di fare i calcoli.\n
- Per qualche strano motivo, noi non possiamo trattenerci dall’attribuire significati più profondi a questo gesto. \n
- Fine dell’antefatto. Ora parliamo dei nostri problemi\n
- Scrum apparentemente ha semplificato di molto la definizione dei ruoli. Per chi ha auto modo di conoscere RUP, averne solo 3 ha rappresentato una benedizione.\n
- Stranamente, però la definizione dei ruoli è una delle cose su cui c’è maggiore attrito.\n
- Come mappiamo i ruoli? Beh... il team è il team, è facile. Un momento! Scrum parlava di team cross funzionali... Eh, ma intanto cominciamo con gli sviluppatori.\n\nPer quanto riguarda lo Scrum Master. Il buon Craig Larman mi consigliò circa 70 libri in bibliografia, necessari per essere un bravo scrum master. Non vado oltre.\n\nE per il Product Owner? La persona che deve prendere le decisioni sul prodotto? Chi decide?\n
- Come mappiamo i ruoli? Beh... il team è il team, è facile. Un momento! Scrum parlava di team cross funzionali... Eh, ma intanto cominciamo con gli sviluppatori.\n\nPer quanto riguarda lo Scrum Master. Il buon Craig Larman mi consigliò circa 70 libri in bibliografia, necessari per essere un bravo scrum master. Non vado oltre.\n\nE per il Product Owner? La persona che deve prendere le decisioni sul prodotto? Chi decide?\n
- Come mappiamo i ruoli? Beh... il team è il team, è facile. Un momento! Scrum parlava di team cross funzionali... Eh, ma intanto cominciamo con gli sviluppatori.\n\nPer quanto riguarda lo Scrum Master. Il buon Craig Larman mi consigliò circa 70 libri in bibliografia, necessari per essere un bravo scrum master. Non vado oltre.\n\nE per il Product Owner? La persona che deve prendere le decisioni sul prodotto? Chi decide?\n
- Come mappiamo i ruoli? Beh... il team è il team, è facile. Un momento! Scrum parlava di team cross funzionali... Eh, ma intanto cominciamo con gli sviluppatori.\n\nPer quanto riguarda lo Scrum Master. Il buon Craig Larman mi consigliò circa 70 libri in bibliografia, necessari per essere un bravo scrum master. Non vado oltre.\n\nE per il Product Owner? La persona che deve prendere le decisioni sul prodotto? Chi decide?\n
- Come mappiamo i ruoli? Beh... il team è il team, è facile. Un momento! Scrum parlava di team cross funzionali... Eh, ma intanto cominciamo con gli sviluppatori.\n\nPer quanto riguarda lo Scrum Master. Il buon Craig Larman mi consigliò circa 70 libri in bibliografia, necessari per essere un bravo scrum master. Non vado oltre.\n\nE per il Product Owner? La persona che deve prendere le decisioni sul prodotto? Chi decide?\n
- Come mappiamo i ruoli? Beh... il team è il team, è facile. Un momento! Scrum parlava di team cross funzionali... Eh, ma intanto cominciamo con gli sviluppatori.\n\nPer quanto riguarda lo Scrum Master. Il buon Craig Larman mi consigliò circa 70 libri in bibliografia, necessari per essere un bravo scrum master. Non vado oltre.\n\nE per il Product Owner? La persona che deve prendere le decisioni sul prodotto? Chi decide?\n
- Come mappiamo i ruoli? Beh... il team è il team, è facile. Un momento! Scrum parlava di team cross funzionali... Eh, ma intanto cominciamo con gli sviluppatori.\n\nPer quanto riguarda lo Scrum Master. Il buon Craig Larman mi consigliò circa 70 libri in bibliografia, necessari per essere un bravo scrum master. Non vado oltre.\n\nE per il Product Owner? La persona che deve prendere le decisioni sul prodotto? Chi decide?\n
- Come mappiamo i ruoli? Beh... il team è il team, è facile. Un momento! Scrum parlava di team cross funzionali... Eh, ma intanto cominciamo con gli sviluppatori.\n\nPer quanto riguarda lo Scrum Master. Il buon Craig Larman mi consigliò circa 70 libri in bibliografia, necessari per essere un bravo scrum master. Non vado oltre.\n\nE per il Product Owner? La persona che deve prendere le decisioni sul prodotto? Chi decide?\n
- E quindi, si finisce su un molto più confortevole Scrumbut...\n
- Che funziona altrettanto bene. basta crederci.\n
- \n
- Oppure, c’è sempre a disposizione una conclusione veloce: “abbiamo provato Scrum e non funziona”, quindi l’unica soluzione è provare qualcos’altro.\n\nCome per tutte le altre cose provate in precedenza, che non hanno funzionato, il contesto o il modo in cui sono state applicate, non è messo in discussione.\n
- E quindi, perché non provare Kanban, che non ci incasina la vita con requisiti upfront complessi come: “dovete chiarire chi prende le decisioni sul prodotto”. Noi vogliamo solo fare agile. Anche solo un pochettino.\n
- E questo è il mio punto di partenza. Dico mio, perché ovviamente per lavoro vedo principalmente aziende in cui si ritiene che ci sia un problema nell’IT e quindi chiamano un consulente.\n
- ... però una volta che sistemiamo le cose, linearizzando il flusso delle operazioni (sì, forse una linea retta tesa non è proprio realistica), succede qualcosa di strano.\n
- Scopriamo che prima e dopo il development team la situazione è altrettanto incasinata.\n
- Illuminante al riguardo il paper di Simon Baker, uno di quelli che Agile lo fa e lo racconta, non come coach ma come imprenditore, a capo di un’azienda che realizza software.\n
- E negli altri dipartimenti non sono necessariamente felici di scoprire che ora sono loro ad essere nell’occhio del ciclone. Non è sempre una sensazione piacevole.\n
- La chiamiamo resistenza, ma in realtà sotto c’è qualcos’altro\n
- C’è il fatto che, in certe organizzazioni, per anni l’Information Technology ha avuto il ruolo di capro espiatorio: l’IT è SEMPRE un casino. I nostri progetti sono SEMPRE in ritardo e creiamo continuamente dei problemi.\n
- Ma questo ruolo di capro espiatorio, ce lo siamo conquistati a torto o a ragione?\n
- Ma questo ruolo di capro espiatorio, ce lo siamo conquistati a torto o a ragione?\n
- Ma questo ruolo di capro espiatorio, ce lo siamo conquistati a torto o a ragione?\n
- Ma questo ruolo di capro espiatorio, ce lo siamo conquistati a torto o a ragione?\n
- Ma questo ruolo di capro espiatorio, ce lo siamo conquistati a torto o a ragione?\n
- Ma questo ruolo di capro espiatorio, ce lo siamo conquistati a torto o a ragione?\n
- Ma questo ruolo di capro espiatorio, ce lo siamo conquistati a torto o a ragione?\n
- Ma questo ruolo di capro espiatorio, ce lo siamo conquistati a torto o a ragione?\n
- Ma questo ruolo di capro espiatorio, ce lo siamo conquistati a torto o a ragione?\n
- Non è affatto semplice stabilire dove stia la ragione e dove stia il torto.\n
- Come confermato da un’altro esperto del settore...\n
- --Digressione (o forse no)--\n
- \n
- ... e qui la cosa comincia a farsi interessante. Perché il cervello, certi collegamenti li fa in maniera assolutamente inconscia. Qualcuno si trattiene a fatica dal farli ad alta voce.\n
- ...ma che c’entra? ...fidatevi, ancora per un attimo.\n
- Torniamo al ruolo dell’IT.\n
- Il buon vecchio uomo di Neanderthal ci fa sapere la sua opinione.\n
- Perché in effetti la nostra capacità di decifrare fenomeni complessi non è che si sia evoluta in maniera spettacolare nel corso degli anni.\n\nSe per spiegare i fulmini, nella preistoria siamo ricorsi al soprannaturale (spiegazione molto più interessante di http://it.wikipedia.org/wiki/Fulmine per l’uomo delle caverne) la situazione non è infatti molto migliorata, con il passare degli anni.\n
- Nel medioevo siamo passati alla caccia alle streghe,\n
- mentre nel terzo millennio la spiegazione dei ritardi cronici e della frizione organizzativa ha una sua motivazione semplice e personalizzante.\n
- Il punto - e qui ritorna in gioco la storia del cervello - è che il cervello umano ha una predilezione per i rapporti causali semplici. E li vede anche dove non ci sono, o dove le spiegazioni sono decisamente più complesse.\n
- Però, in un Sistema Adattivo Complesso quale un’organizzazione che produce software... qualsiasi spiegazione semplice è anche semplicistica. Per quanto semplice possa apparire, è improbabile che il nesso causale sia così chiaro e netto.\n\n\n
- E qui cito - come la maggior parte degli speaker di questa edizione - il fantastico libro di Daniel Kahneman, che illustra il funzionamento del cervello, in determinate situazioni e che spiega quali e quanto errori sistematici di valutazione siamo indotti a compiere, senza renderecene conto.\n
- Il punto è che ...non c’è via d’uscita. Ragioniamo logicamente credendoci macchine logiche, ma in realtà tali non siamo. O se lo siamo, ...siamo bacate ed in determinate situazioni tendiamo a compiere gli stessi errori.\n\n...qualcosa di molto simile alla slide iniziale: “persone intelligenti che prendono decisioni non intelligenti”\n
- Secondo la spiegazione di Kahneman (premio Nobel, tra le altre cose), nel cervello ci sono due sistemi in cooperazione/competizione. \n\nUn sistema istintivo/intuitivo (Sistema 1) che è sempre attivo e cerca di dare risposte associative in maniera estremamente rapida. Capace di parallelismo, e di divagazioni involontarie.\n\nUn sistema (Sistema 2) specializzato nei ragionamenti complessi: conti a mente, ragionamenti concettuali o astratti. Può fare una sola cosa alla volta, ed ha un elevato consumo. \n
- Secondo la spiegazione di Kahneman (premio Nobel, tra le altre cose), nel cervello ci sono due sistemi in cooperazione/competizione. \n\nUn sistema istintivo/intuitivo (Sistema 1) che è sempre attivo e cerca di dare risposte associative in maniera estremamente rapida. Capace di parallelismo, e di divagazioni involontarie.\n\nUn sistema (Sistema 2) specializzato nei ragionamenti complessi: conti a mente, ragionamenti concettuali o astratti. Può fare una sola cosa alla volta, ed ha un elevato consumo. \n
- Secondo la spiegazione di Kahneman (premio Nobel, tra le altre cose), nel cervello ci sono due sistemi in cooperazione/competizione. \n\nUn sistema istintivo/intuitivo (Sistema 1) che è sempre attivo e cerca di dare risposte associative in maniera estremamente rapida. Capace di parallelismo, e di divagazioni involontarie.\n\nUn sistema (Sistema 2) specializzato nei ragionamenti complessi: conti a mente, ragionamenti concettuali o astratti. Può fare una sola cosa alla volta, ed ha un elevato consumo. \n
- Secondo la spiegazione di Kahneman (premio Nobel, tra le altre cose), nel cervello ci sono due sistemi in cooperazione/competizione. \n\nUn sistema istintivo/intuitivo (Sistema 1) che è sempre attivo e cerca di dare risposte associative in maniera estremamente rapida. Capace di parallelismo, e di divagazioni involontarie.\n\nUn sistema (Sistema 2) specializzato nei ragionamenti complessi: conti a mente, ragionamenti concettuali o astratti. Può fare una sola cosa alla volta, ed ha un elevato consumo. \n
- Secondo la spiegazione di Kahneman (premio Nobel, tra le altre cose), nel cervello ci sono due sistemi in cooperazione/competizione. \n\nUn sistema istintivo/intuitivo (Sistema 1) che è sempre attivo e cerca di dare risposte associative in maniera estremamente rapida. Capace di parallelismo, e di divagazioni involontarie.\n\nUn sistema (Sistema 2) specializzato nei ragionamenti complessi: conti a mente, ragionamenti concettuali o astratti. Può fare una sola cosa alla volta, ed ha un elevato consumo. \n
- Secondo la spiegazione di Kahneman (premio Nobel, tra le altre cose), nel cervello ci sono due sistemi in cooperazione/competizione. \n\nUn sistema istintivo/intuitivo (Sistema 1) che è sempre attivo e cerca di dare risposte associative in maniera estremamente rapida. Capace di parallelismo, e di divagazioni involontarie.\n\nUn sistema (Sistema 2) specializzato nei ragionamenti complessi: conti a mente, ragionamenti concettuali o astratti. Può fare una sola cosa alla volta, ed ha un elevato consumo. \n
- Secondo la spiegazione di Kahneman (premio Nobel, tra le altre cose), nel cervello ci sono due sistemi in cooperazione/competizione. \n\nUn sistema istintivo/intuitivo (Sistema 1) che è sempre attivo e cerca di dare risposte associative in maniera estremamente rapida. Capace di parallelismo, e di divagazioni involontarie.\n\nUn sistema (Sistema 2) specializzato nei ragionamenti complessi: conti a mente, ragionamenti concettuali o astratti. Può fare una sola cosa alla volta, ed ha un elevato consumo. \n
- Secondo la spiegazione di Kahneman (premio Nobel, tra le altre cose), nel cervello ci sono due sistemi in cooperazione/competizione. \n\nUn sistema istintivo/intuitivo (Sistema 1) che è sempre attivo e cerca di dare risposte associative in maniera estremamente rapida. Capace di parallelismo, e di divagazioni involontarie.\n\nUn sistema (Sistema 2) specializzato nei ragionamenti complessi: conti a mente, ragionamenti concettuali o astratti. Può fare una sola cosa alla volta, ed ha un elevato consumo. \n
- Siccome il Sistema 2 consuma in sacco in termini di risorse, cerchiamo di non attivarlo, se non quando è realmente necessario.\n\nIl Sistema 1, quando può dare una risposta associativa semplice ad una domanda, che assomiglia vagamente alla domanda difficile che gli viene posta... la dà. È più forte di lui.\n
- Torniamo a Scrum ed al nostro problema.\n
- Un esempio classico di team auto-organizzante è dato dal corpo dei marines. Che è un buon esempio per parlare di un sacco di cose.\n\nI marines hanno un addestramento specifico per essere in grado di sopravvivere anche in assenza di una linea di comando. Devono poter improvvisare, perché in situazioni critiche non è detto che ci sia qualcuno in grado di dare loro ordini.\n
- Il maggiore avversario di un team auto-organizzante è il classico organigramma piramidale.\n
- Questa cosa qua. Egregiamente supportata da tool di disegno, come Visio. È un diagramma “nativo” non possiamo farne a meno, chiunque deve essere in grado di disegnare un’organigramma.\n
- Ed ovviamente questa è una scelta supportata dal nostro sistema 1. Possiamo applicare un principio di management collaudato, supportato da una citazione. Poco importa che Giulio Cesare lo applicasse al controllo delle popolazioni nemiche e non al management di un team di sviluppo software. Il bello delle citazioni latine è che sono senza tempo e soddisfano facilmente il sistema 1. Ipse Dixit. Ecco, vedete?\n
- Ma il vero problema dell’organizzazione piramidale è questa cosa qua. Il fatto che spesso tenda a portare le decisioni lontano dalle informazioni. Le decisioni si prendono al vertice. Le informazioni sono alla base.\n\nAuguri.\n
- E questo ci porta a 2 grandi categorie di problemi: decisioni prese nel posto sbagliato (al vertice, ma anche nel dipartimento sbagliato) e decisioni prese nel modo sbagliato (Sistema 1 anziché Sistema 2).\n\nOvviamente l’una non esclude l’altra. :-)\n
- Se stiamo prendendo una decisione nel punto sbagliato dell’organizzazione, un’affermazione di questo genere è perfetta per il Sistema 1.\n\nNell’ipotesi di un apporto di efficienza lineare (la più intuitiva) questa frase è assolutamente ragionevole. Ma qualsiasi team leader esperto sa che questa affermazione è maledettamente falsa: l’arrivo di 2 nuove persone sottrarrà tempo, nelle fasi iniziali ed è estremamente difficile stimare da quando l’apporto dei nuovi arrivati potrà tradursi in un vantaggio.\n\nUn team leader - guidato dall’esperienza - prenderebbe probabilmente la decisione giusta. Un manager non così competente di sviluppo software, probabilmente sarebbe soddisfatto della soluzione intuitivamente corretta.\n\nSe questa decisione è presa troppo in alto, l’energia necessaria a correggerla, può essere spropositata. Più decisioni prese nel posto sbagliato, maggiori le energie spese a correggerle. E non riusciremo a bloccarle tutte. Anche i migliori portieri non parano tutti i rigori.\n
- Passiamo ad una variazione sul tema. Qui le scorciatoie da sistema 1 sono molteplici\n
- A qualcuno, la cosa sarà sembrata sensata. Ma così non è.\n\nIl punto è che l’ipotesi che un Senior sia come uno Junior, solo più veloce (linearità di rendimento) implicitamente è lecita: “è più bravo, sarà più veloce”, quando nella pratica sappiamo benissimo che non è vero. Anzi, spesso è vero il contrario: il senior si prende più tempo perché completa il lavoro anziché consegnarlo solo plausibilmente finito.\n\nAnche se il primo punto fosse vero, sarebbe comunque una boiata. Il mercato dei programmatori ha discrepanze salariali molto basse rispetto alla differenza in produttività fra uno bravo ed uno che non lo è. Se volessimo scegliere alla cieca, converrebbe comunque assumere un senior.\n\nSenza contare i costi di avviamento: inserire UN Senior in un contesto complesso può richiedere un tempo molto inferiore che rendere produttivi DUE Junior sia in termini di tempo necessario prima di apportare valore, sia in termini di tempo sottratto alle risorse senior esistenti per farsi spiegare le cose.\n
- A qualcuno, la cosa sarà sembrata sensata. Ma così non è.\n\nIl punto è che l’ipotesi che un Senior sia come uno Junior, solo più veloce (linearità di rendimento) implicitamente è lecita: “è più bravo, sarà più veloce”, quando nella pratica sappiamo benissimo che non è vero. Anzi, spesso è vero il contrario: il senior si prende più tempo perché completa il lavoro anziché consegnarlo solo plausibilmente finito.\n\nAnche se il primo punto fosse vero, sarebbe comunque una boiata. Il mercato dei programmatori ha discrepanze salariali molto basse rispetto alla differenza in produttività fra uno bravo ed uno che non lo è. Se volessimo scegliere alla cieca, converrebbe comunque assumere un senior.\n\nSenza contare i costi di avviamento: inserire UN Senior in un contesto complesso può richiedere un tempo molto inferiore che rendere produttivi DUE Junior sia in termini di tempo necessario prima di apportare valore, sia in termini di tempo sottratto alle risorse senior esistenti per farsi spiegare le cose.\n
- A qualcuno, la cosa sarà sembrata sensata. Ma così non è.\n\nIl punto è che l’ipotesi che un Senior sia come uno Junior, solo più veloce (linearità di rendimento) implicitamente è lecita: “è più bravo, sarà più veloce”, quando nella pratica sappiamo benissimo che non è vero. Anzi, spesso è vero il contrario: il senior si prende più tempo perché completa il lavoro anziché consegnarlo solo plausibilmente finito.\n\nAnche se il primo punto fosse vero, sarebbe comunque una boiata. Il mercato dei programmatori ha discrepanze salariali molto basse rispetto alla differenza in produttività fra uno bravo ed uno che non lo è. Se volessimo scegliere alla cieca, converrebbe comunque assumere un senior.\n\nSenza contare i costi di avviamento: inserire UN Senior in un contesto complesso può richiedere un tempo molto inferiore che rendere produttivi DUE Junior sia in termini di tempo necessario prima di apportare valore, sia in termini di tempo sottratto alle risorse senior esistenti per farsi spiegare le cose.\n
- E qui la saggezza popolare impera. In realt\n
- Questa, per chi fa Kanban è evidentemente una bestemmia. Ma suona bene e mette in pace la coscienza. Sono “bloccato” e mi occupo di altro. Così, giusto per non rimanere fermo (quello è il male, mi vedono). Solo che...\n\nAprire un’altra attività è costosa. C’è un contesto ulteriore da gestire, ed il costo di ritornare nel contesto iniziale una volta che sia possibile sbloccare la cosa.\n\nL’illusione è che tutto il lavoro fatto non vada perduto, ma in un lavoro in gran parte concettuale, il lavoro di concentrazione, esplorazione e costruzione di un modello concettuale del problema va perso se non viene finalizzato in tempi rapidi. In Scrum le stime dei task vengono fatte sul tempo rimanente al completamento: se dopo una settimana nessuno ha lavorato su un’attività, mi aspetto che la stima sul tempo rimasto aumenti. Perché ricominciamo da più indietro.\n\nCominciare attività aumenta il casino ed il carico cognitivo sugli sviluppatori. ma anche sull’organizzazione. Fare partire un’attività parallela significa anche legittimare altri stakeholders ad attendersi risultati, mentre voi state anche facendo altro. Con tutte le conseguenze del caso.\n\n
- Questa, per chi fa Kanban è evidentemente una bestemmia. Ma suona bene e mette in pace la coscienza. Sono “bloccato” e mi occupo di altro. Così, giusto per non rimanere fermo (quello è il male, mi vedono). Solo che...\n\nAprire un’altra attività è costosa. C’è un contesto ulteriore da gestire, ed il costo di ritornare nel contesto iniziale una volta che sia possibile sbloccare la cosa.\n\nL’illusione è che tutto il lavoro fatto non vada perduto, ma in un lavoro in gran parte concettuale, il lavoro di concentrazione, esplorazione e costruzione di un modello concettuale del problema va perso se non viene finalizzato in tempi rapidi. In Scrum le stime dei task vengono fatte sul tempo rimanente al completamento: se dopo una settimana nessuno ha lavorato su un’attività, mi aspetto che la stima sul tempo rimasto aumenti. Perché ricominciamo da più indietro.\n\nCominciare attività aumenta il casino ed il carico cognitivo sugli sviluppatori. ma anche sull’organizzazione. Fare partire un’attività parallela significa anche legittimare altri stakeholders ad attendersi risultati, mentre voi state anche facendo altro. Con tutte le conseguenze del caso.\n\n
- Questa, per chi fa Kanban è evidentemente una bestemmia. Ma suona bene e mette in pace la coscienza. Sono “bloccato” e mi occupo di altro. Così, giusto per non rimanere fermo (quello è il male, mi vedono). Solo che...\n\nAprire un’altra attività è costosa. C’è un contesto ulteriore da gestire, ed il costo di ritornare nel contesto iniziale una volta che sia possibile sbloccare la cosa.\n\nL’illusione è che tutto il lavoro fatto non vada perduto, ma in un lavoro in gran parte concettuale, il lavoro di concentrazione, esplorazione e costruzione di un modello concettuale del problema va perso se non viene finalizzato in tempi rapidi. In Scrum le stime dei task vengono fatte sul tempo rimanente al completamento: se dopo una settimana nessuno ha lavorato su un’attività, mi aspetto che la stima sul tempo rimasto aumenti. Perché ricominciamo da più indietro.\n\nCominciare attività aumenta il casino ed il carico cognitivo sugli sviluppatori. ma anche sull’organizzazione. Fare partire un’attività parallela significa anche legittimare altri stakeholders ad attendersi risultati, mentre voi state anche facendo altro. Con tutte le conseguenze del caso.\n\n
- In generale, la piramide è intrinsecamente disfunzionale. Le decisioni prese al vertice, mentre le informazioni sono alla base generano tutta una serie di comportamenti che dovreste conoscere molto bene. Solo che spesso li consideriamo talmente normali da non renderci conto che sono disfunzioni.\n
- \n
- Questa è una delle situazioni più tristemente ricorrenti. Alla base qualcuno ha determinate informazioni ma non è nella posizione di compiere le scelte conseguenti. Siccome sa che la scelta è necessaria, allora dedica energie a convincere il capo.\n\nOvviamente il capo è impegnato anche in altre attività, non è seduto su un trono ad aspettare la processione di chi gli chiede di prendere una decisione. E spesso quando si avvicina il momento di prendere la fatidica decisione, il sistema 2 è ormai esausto.\n\nA questo aggiungiamo che per chi bussa alla porta del capo, spiegare esattamente il problema ed il motivo per cui deve essere presa una determinata decisione è un’operazione tutt’altro che semplice. Non siamo molto bravi a farla.\n\nMa non avere capito nulla non è detto che sia un ostacolo insormontabile. Posso differire (ma il nostro eroe ne aveva bisogno adesso) nell’attesa di capire meglio, oppure sparare una gigantesca boiata, che soddisfa il sistema 1. Punti extra nel caso che la boiata sia in latino.\n
- Questa è una delle situazioni più tristemente ricorrenti. Alla base qualcuno ha determinate informazioni ma non è nella posizione di compiere le scelte conseguenti. Siccome sa che la scelta è necessaria, allora dedica energie a convincere il capo.\n\nOvviamente il capo è impegnato anche in altre attività, non è seduto su un trono ad aspettare la processione di chi gli chiede di prendere una decisione. E spesso quando si avvicina il momento di prendere la fatidica decisione, il sistema 2 è ormai esausto.\n\nA questo aggiungiamo che per chi bussa alla porta del capo, spiegare esattamente il problema ed il motivo per cui deve essere presa una determinata decisione è un’operazione tutt’altro che semplice. Non siamo molto bravi a farla.\n\nMa non avere capito nulla non è detto che sia un ostacolo insormontabile. Posso differire (ma il nostro eroe ne aveva bisogno adesso) nell’attesa di capire meglio, oppure sparare una gigantesca boiata, che soddisfa il sistema 1. Punti extra nel caso che la boiata sia in latino.\n
- Questa è una delle situazioni più tristemente ricorrenti. Alla base qualcuno ha determinate informazioni ma non è nella posizione di compiere le scelte conseguenti. Siccome sa che la scelta è necessaria, allora dedica energie a convincere il capo.\n\nOvviamente il capo è impegnato anche in altre attività, non è seduto su un trono ad aspettare la processione di chi gli chiede di prendere una decisione. E spesso quando si avvicina il momento di prendere la fatidica decisione, il sistema 2 è ormai esausto.\n\nA questo aggiungiamo che per chi bussa alla porta del capo, spiegare esattamente il problema ed il motivo per cui deve essere presa una determinata decisione è un’operazione tutt’altro che semplice. Non siamo molto bravi a farla.\n\nMa non avere capito nulla non è detto che sia un ostacolo insormontabile. Posso differire (ma il nostro eroe ne aveva bisogno adesso) nell’attesa di capire meglio, oppure sparare una gigantesca boiata, che soddisfa il sistema 1. Punti extra nel caso che la boiata sia in latino.\n
- Una cosa apparentemente sorprendente, ma che in realtà non lo è affatto, è che in organizzazioni apparentemente moderne si ricreino gli stessi pattern comportamentali che caratterizzavano le regge dei secoli scorsi.\n\nNon è un problema di mentalità: è che in un sistema strutturato in questo modo, questi pattern sono la conseguenza più logica. Principalmente dal punto di vista della sopravvivenza intesa come minimizzazione del dispendio energetico.\n
- Una cosa apparentemente sorprendente, ma che in realtà non lo è affatto, è che in organizzazioni apparentemente moderne si ricreino gli stessi pattern comportamentali che caratterizzavano le regge dei secoli scorsi.\n\nNon è un problema di mentalità: è che in un sistema strutturato in questo modo, questi pattern sono la conseguenza più logica. Principalmente dal punto di vista della sopravvivenza intesa come minimizzazione del dispendio energetico.\n
- Una cosa apparentemente sorprendente, ma che in realtà non lo è affatto, è che in organizzazioni apparentemente moderne si ricreino gli stessi pattern comportamentali che caratterizzavano le regge dei secoli scorsi.\n\nNon è un problema di mentalità: è che in un sistema strutturato in questo modo, questi pattern sono la conseguenza più logica. Principalmente dal punto di vista della sopravvivenza intesa come minimizzazione del dispendio energetico.\n
- Una cosa apparentemente sorprendente, ma che in realtà non lo è affatto, è che in organizzazioni apparentemente moderne si ricreino gli stessi pattern comportamentali che caratterizzavano le regge dei secoli scorsi.\n\nNon è un problema di mentalità: è che in un sistema strutturato in questo modo, questi pattern sono la conseguenza più logica. Principalmente dal punto di vista della sopravvivenza intesa come minimizzazione del dispendio energetico.\n
- Solo che tutte queste attività sono sensate a livello individuale, ma a livello dell’organizzazione sono puro spreco. Della peggior specie.\n\nNon viene tracciato - quanti di voi riportano “complotti e congiure” sul timesheet? - ma c’è. Fa perdere tempo, non produce valore ed alimenta malumori. Ma molti di noi continuano a trovarlo dannatamente normale.\n
- Una figura tipica in questo contesto è il “cortigiano”.\nNon è malvagio in se. Risolve un’esigenza di comunicazione. Al crescere del numero delle decisioni, il grande capo ha bisogno di una sintesi comprensibile, orientata al linguaggio del capo. Inutile dire che questa sintesi può influenzare notevolmente l’esito della valutazione.\n
- Una figura tipica in questo contesto è il “cortigiano”.\nNon è malvagio in se. Risolve un’esigenza di comunicazione. Al crescere del numero delle decisioni, il grande capo ha bisogno di una sintesi comprensibile, orientata al linguaggio del capo. Inutile dire che questa sintesi può influenzare notevolmente l’esito della valutazione.\n
- Una figura tipica in questo contesto è il “cortigiano”.\nNon è malvagio in se. Risolve un’esigenza di comunicazione. Al crescere del numero delle decisioni, il grande capo ha bisogno di una sintesi comprensibile, orientata al linguaggio del capo. Inutile dire che questa sintesi può influenzare notevolmente l’esito della valutazione.\n
- Una figura tipica in questo contesto è il “cortigiano”.\nNon è malvagio in se. Risolve un’esigenza di comunicazione. Al crescere del numero delle decisioni, il grande capo ha bisogno di una sintesi comprensibile, orientata al linguaggio del capo. Inutile dire che questa sintesi può influenzare notevolmente l’esito della valutazione.\n
- Ed anche questo è sostanzialmente spreco. Allontaniamo ancora il punto in cui sono prese le decisioni dal punto in cui abbiamo le informazioni. Riassumiamo le informazioni, con il rischio di tralasciare quelle importanti. Aggiungiamo ritardi ulteriori e dobbiamo guadagnarci la benevolenza di due livelli. Due se siamo fortunati, ovviamente.\n
- Il punto è che questa roba non ha più nulla a che fare con lo sviluppo software o con scrum.\n
- ma questa cosa cozza in primis con Agile.\n
- Solo che lo sviluppo software agile, un’attività in cui prendiamo un numero spropositato di decisioni. Alcune spettano a noi. Altre sono localizzata altrove, ed è un problema.\n\nNoi siamo i primi a sbatterci contro.\n
- Ok, proviamo ad essere propositivi.\n
- Non è una contrapposizione ideologica. Non è che la democrazia è meglio della dittatura.\n
- Abbiamo bisogno di introdurre un’altra variabile.\nSenza skills, restiamo ancorati alla sterile ideologia.\n
- Una delle lezioni apprese da Management 3.0 è che ci sono ampi margini di manovra senza cadere negli estremismi ideologici.\n\nIl delegation poker ad esempio aiuta ad affrontare il problema della delega in maniera fine specifica.\n
- Possiamo ad esempio rendere esplicite le nostre scelte ed il livello di delega su problemi specifici. Senza che sia necessariamente dittatura vs anarchia. Su certi temi l’empowerment può essere totale. Su altri molto meno.\n
- E non possiamo non considerare il fatto che il livello di conoscenze sia una variabile chiave. E che il punto di partenza di un team che non è abituato a prendere decisioni sia quello di non sapere bene sulla base di cosa queste decisioni vengono prese.\n\nMa allo stesso modo, non possiamo ignorare che un team che migliora le proprie capacità tecniche legittimamente aspira ad avere maggiore autonomia decisionale. Nel caso questo non avvenga, quelli bravi se ne andranno e noi ritorneremo ad avere una piramide stabile, con la base con le informazioni e senza gli skill, e le decisioni prese al vertice ma sempre con meno informazioni.\n
- E non possiamo non considerare il fatto che il livello di conoscenze sia una variabile chiave. E che il punto di partenza di un team che non è abituato a prendere decisioni sia quello di non sapere bene sulla base di cosa queste decisioni vengono prese.\n\nMa allo stesso modo, non possiamo ignorare che un team che migliora le proprie capacità tecniche legittimamente aspira ad avere maggiore autonomia decisionale. Nel caso questo non avvenga, quelli bravi se ne andranno e noi ritorneremo ad avere una piramide stabile, con la base con le informazioni e senza gli skill, e le decisioni prese al vertice ma sempre con meno informazioni.\n
- E non possiamo non considerare il fatto che il livello di conoscenze sia una variabile chiave. E che il punto di partenza di un team che non è abituato a prendere decisioni sia quello di non sapere bene sulla base di cosa queste decisioni vengono prese.\n\nMa allo stesso modo, non possiamo ignorare che un team che migliora le proprie capacità tecniche legittimamente aspira ad avere maggiore autonomia decisionale. Nel caso questo non avvenga, quelli bravi se ne andranno e noi ritorneremo ad avere una piramide stabile, con la base con le informazioni e senza gli skill, e le decisioni prese al vertice ma sempre con meno informazioni.\n
- Il punto di partenza è quindi il livello di (in)competenza nell’organizzazione.\n
- Perdonatemi il gioco di parole. Ma per progredire un’organizzazione ha bisogno di imparare. Anzi: la capacità di imparare da parte di un’organizzazione è un fattore critico per la sua evoluzione e la sua competitività. (Provaglio ha detto le stesse cose molto meglio nel suo talk n.d.r. ed il riferimento principe è Peter Senge con “the Fifth Discipline”).\n\nSolo che (maledetto sistema 1) quando penso a learning organization il mio cervello si illude e pensa ad un’organizzazione il cui ruolo dovrebbe essere quello di formare professionisti per il mondo del lavoro e di imparare a formarli sempre meglio. Ma l’università italiana ha cauterizzato tutti i canali di feedback, per poter essere completamente autoreferenziale. Non impara, non è strutturalmente in grado di farlo ed in tempi brevi non lo farà. \n\nCome cittadini è legittimo aspettarsi di meglio, ma come saggi ...non aspettiamoci granché.\n\n\n
- Non lo gestisce. Amen.\n\nNo feedback dopo un’ora di lezione.\nNo feedback dopo un esame.\nNo feedback dopo la laurea.\nNo feedback dopo l’inserimento nel mondo del lavoro.\n\nCome può imparare?\n\nHopeless.\n
- Ok, non è un problema nostro.\n\nSolo che lo diventa una volta varcati i cancelli della nostra azienda. Ora queste persone sono il nostro vantaggio competitivo, o devono diventarlo. E qual è la nostra strategia?\n
- La gavetta.\nTermine odioso che significa “ti metto qui a fare qualcosa di non particolarmente utile, perché non ho alcuna idea su come farti crescere in maniera efficace”\n
- Anche perché, cosa credono di saper fare questi giovani dell’età di Zuckerberg, Brin, Page, Gates (posso continuare...)\n
- Se non sanno fare, la piramide non è messa in discussione.\nSe quelli bravi se ne vanno, la piramide non è messa in discussione.\n
- L’ultimo ingrediente, per essere veramente sicuri che nulla cambi è intervenire sulle strategie di recruiting.\n
- Assumiamo solo qualcuno che possa essere come noi un giorno, ma non meglio di noi. Quasi.\n\nQuante aziende assumono cercando la diversità? Il potenziale mancante?\n\nQuante aziende sono in grado di mettere i neo assunti in condizioni di esprimerlo?\n
- Purtroppo, un altro fra gli antipatterns ricorrenti nelle strutture “immutabili” è la sostituzione dell’anzianità all’esperienza (Ne parlai all’Agile day 2011 ... http://www.slideshare.net/ziobrando/volevo-solo-scrivere-codice-iad-2011-10656512 )\n\nEd una delle conseguenze più odiose è un’atteggiamento molto simile al nonnismo: “deve essere difficile per te come lo è stato per me”, o più semplicemente “devi soffrire”, mascherato da “ci siamo passati tutti”.\n\nPer quanto mi riguarda la reazione è il vomito. Ma si tratta di un antipattern sistemico, per cui cerco di trattenermi.\n
- La questione è: “siamo in grado di insegnare alle nuove leve?”, o detta in maniera più stringente: “siamo in grado di ottimizzare il loro percorso di crescita mettendoli nelle condizione di apportare valore il prima possibile al nostro team ed alla nostra azienda?”\n\n\n
- La risposta è quasi sempre questa.\n
- Non è perché siamo cattivi. È che ci siamo trovati anche noi nella stessa situazione.\n\nSiamo entrati in azienda che non sapevamo nulla. Abbiamo partecipato ad un progetto che significava molto per noi ed abbiamo imparato a fare funzionare qualcosa.\n\nMa molto raramente siamo arrivati a quel livello di competenza che ci permette di poter dire: “questa cosa si può implementare in N modi. In questo caso hai questi vantaggi, mentre in quest’altro hai questi altri”. Spesso sappiamo fare - a fatica - le cose in un solo modo, e non abbiamo alternative. L’alternativa è il caos o l’ignoto e quindi ce ne stiamo rintanati non cambiando nulla.\n\nE la cosa non è diversa fuori dall’IT.\n
- Ed ecco che rafforziamo la stabilità del sistema.\n
- Solo che con questi meccanismi generiamo una spirale negativa di potenziale sprecato. Chi impara se ne va. Chi tollera resta. E la piramide resta immobile ed immutabile, mentre il mercato va per la sua strada.\n
- Abbiamo parlato di skills, e spesso ci focalizziamo sugli skills tecnici, sul “saperne di più”.\n\nMa c’è un’aspetto che spesso tendiamo ad ignorare. La nostra abilità “tecnica” nel prendere decisioni.\n
- Seriamente: non si tratta di una disciplina sulla quale riceviamo training. È una di quelle cose che “o le sai fare oppure no” (è singolare quanto deleghiamo all’”attitudine” su temi di cui siamo pesantemente incompetenti).\n\nMa ci sono persone che sono tecnicamente molto preparate, ma assolutamente a disagio al momento di prendere determinate decisioni. In difficoltà nell’organizzare le alternative e nel valutare le opportunità. Ma anche questa è una abilità in larga parte tecnica. Che possiamo affrontare ricorrendo a massicce dosi di visualizzazione, a qualche esercizio specifico ed alla collaborazione dei colleghi.\n
- Già perché in questo caso abbiamo 2 problemi che si sommano (o si moltiplicano, o si elevano al potenza). La nostra capacità individuale di prendere delle decisioni corrette (o perlomeno accettabili) ed in un tempo finito, e la nostra capacità di convergere come team su una decisione anche in questo caso in un tempo finito.\n\nE ...non è detto che sappiamo fare. A parte il pessimo esempio dei nostri “onorevoli” ancora ad accapigliarsi sulla legge elettorale, non è che abbiamo grandi esempi od esperienze di decisioni prese collettivamente. Alcune esperienze personali (per quanto mi riguarda, suonare in un gruppo; ma le possibilità sono molteplici) possono aiutare, ma il grosso dell’esperienza è di senso diverso.\n
- Anche su questo tema possiamo imparare. Altrimenti il rischio è di ritrovarsi a cedere nuovamente il potere al boss: “se non siete in grado di prendere una decisione allora decido io”, e spesso il boss è in quella posizione principalmente per la sua capacità di prendere decisioni. Anche qualsiasi, ma sempre meglio di nulla.\n\nLa democrazia non è necessariamente lenta. Necessità di tecniche da affinare con la pratica. Come la piramide affina le nostre capacità di complotto ed imbonimento, la democrazia richiede di migliorare le nostre capacità di decision making.\n
- Un ultimo tema, caratteristico delle strutture (ed in forte relazione con la quantità di energia necessaria a “convincere il nostro capo”) è quello dello stress.\n
- Leggendo un’altro libro sul cervello (quell’inutile organo che nulla ha a che fare con il nostro lavoro) sono incappato in una spettacolare definizione di Stress.\n\nÈ una condizione che provoca una risposta psicologica (quindi qualcosa che non ignoriamo)\nLa condizione è percepita come avversa\nLa condizione è percepita come inevitabile\n
- In queste condizioni, il cervello non impara.\nNon è una scelta: la capacità di apprendimento viene inibita a livello di neurotrasmettitori. Non ci sono speranze che una persona in queste condizioni abbia un processo di apprendimento decente.\n\nSono le persone che vengono (forse) mandate ai corsi e restano sotto la tirannia del blackberry. Quelle che frequentano ma non ricordano nulla. Quelle che si assentano. Quelle che ascoltano, ma non ricevono.\n\nNel suo libro, John Medina va oltre: prolungate esposizioni a queste condizioni provocano il fenomeno di “learned helplessness”, anche rimuovendo le condizioni di stress, non è detto che siamo in gradi di approfittarne. Se siamo troppo abituati al fatalismo, non siamo nemmeno in grado di cogliere le opportunità quando si presentano.\n
- Devono essere salvate. E troppo spesso ho visto attribuire ad alcune di queste persone, logiche e livelli di consapevolezza che invece non hanno. Non si tratta di resistenza al cambiamento, non consapevole almeno. Si tratta di qualcosa di più subdolo: di un’incapacità strutturale di imparare le nuove regole, fintanto che sono valide le condizioni attuali.\n\nÈ estremamente improbabile che queste persone possano farcela da sole. Vanno aiutate. Perché la loro condizione è un attrattore stabile. Sabbie mobili. Un buco nero.\n\nE non ha senso attribuire motivazioni caratteriali. Non stanno remando contro.\n
- \n
- \n
- Il vento vince sempre. Ed in questo caso il vento per me sono le neuroscienze. Inutile aspettarsi troppo in determinate situazioni.\n\nIl sistema 2 è intelligente, ma ha risorse limitate. Se le persone fossero in grado di utilizzarlo indefinitamente ci troveremmo in situazioni completamente diverse. Ma così non è, e questa è una battaglia che non possiamo vincere. Diventa un constraint.\n\n\n
- Prendere decisioni sensate è costoso. Ed in determinate condizioni è matematico che non ci sia la possibilità di prendere una decisione sensata. Se dipendete dal boss per una decisione e aspettate la fine giornata, quando è esausto... siete degli aspiranti suicidi!\n\nPerché una risposta la otterrete. Sarà inadeguata, e ve la terrete.\n
- Ho forse spinto troppo sulla dicotomia boss/gruppo ma una delle strategie migliori per gestire le decisioni è fare in modo che queste vengano prese senza che ci sia la consapevolezza di averle prese.\n\nIl segreto è fare accadere le cose. Il meglio è quando accadono coinvolgendo tutti senza che questi si accorgano di averlo fatto. Swarming e simili. Chi ha partecipato ad una unconference sa a cosa mi riferisco.\n\n\n
- \n
- Strategie per la gestione del cambiamento che non prescindono dalle risorse limitate a nostra disposizione e dal “come siamo fatti”?\n\nQuesto libro è grandioso.\n
- È un problema dell’IT perché la situazione è nella maggior parte dei casi oscillante tra l’imbarazzante ed il drammatico. Vedi anche il mio talk del giorno precedente in cui parlo proprio di questo.\n\nNon è un problema dell’IT perché è in realtà un problema di tutta l’organizzazione che risulta molto più visibile nell’IT.\n
- Ed è nella struttura che pone le decisioni disaccoppiate dalle informazioni. È inadeguato (vedi anche Cynefin Framework), ed è un problema generale\n
- Si manifesta nell’IT, perché l’IT strutturalmente è un’amplificatore di casino.\n\nPrendiamo requisiti contraddittori e speriamo di implementarli in applicazioni non contraddittorie (in bocca al lupo ragazzi!). Siamo incompetenti quanto gli altri ma le conseguenze delle nostre scelte entrano in circolo e ricadono su di noi, molto più che negli altri dipartimenti. \n
- Si manifesta nell’IT, perché l’IT strutturalmente è un’amplificatore di casino.\n\nPrendiamo requisiti contraddittori e speriamo di implementarli in applicazioni non contraddittorie (in bocca al lupo ragazzi!). Siamo incompetenti quanto gli altri ma le conseguenze delle nostre scelte entrano in circolo e ricadono su di noi, molto più che negli altri dipartimenti. \n
- Si manifesta nell’IT, perché l’IT strutturalmente è un’amplificatore di casino.\n\nPrendiamo requisiti contraddittori e speriamo di implementarli in applicazioni non contraddittorie (in bocca al lupo ragazzi!). Siamo incompetenti quanto gli altri ma le conseguenze delle nostre scelte entrano in circolo e ricadono su di noi, molto più che negli altri dipartimenti. \n
- Si manifesta nell’IT, perché l’IT strutturalmente è un’amplificatore di casino.\n\nPrendiamo requisiti contraddittori e speriamo di implementarli in applicazioni non contraddittorie (in bocca al lupo ragazzi!). Siamo incompetenti quanto gli altri ma le conseguenze delle nostre scelte entrano in circolo e ricadono su di noi, molto più che negli altri dipartimenti. \n
- Si manifesta nell’IT, perché l’IT strutturalmente è un’amplificatore di casino.\n\nPrendiamo requisiti contraddittori e speriamo di implementarli in applicazioni non contraddittorie (in bocca al lupo ragazzi!). Siamo incompetenti quanto gli altri ma le conseguenze delle nostre scelte entrano in circolo e ricadono su di noi, molto più che negli altri dipartimenti. \n
- Si manifesta nell’IT, perché l’IT strutturalmente è un’amplificatore di casino.\n\nPrendiamo requisiti contraddittori e speriamo di implementarli in applicazioni non contraddittorie (in bocca al lupo ragazzi!). Siamo incompetenti quanto gli altri ma le conseguenze delle nostre scelte entrano in circolo e ricadono su di noi, molto più che negli altri dipartimenti. \n
- Si manifesta nell’IT, perché l’IT strutturalmente è un’amplificatore di casino.\n\nPrendiamo requisiti contraddittori e speriamo di implementarli in applicazioni non contraddittorie (in bocca al lupo ragazzi!). Siamo incompetenti quanto gli altri ma le conseguenze delle nostre scelte entrano in circolo e ricadono su di noi, molto più che negli altri dipartimenti. \n
- Si manifesta nell’IT, perché l’IT strutturalmente è un’amplificatore di casino.\n\nPrendiamo requisiti contraddittori e speriamo di implementarli in applicazioni non contraddittorie (in bocca al lupo ragazzi!). Siamo incompetenti quanto gli altri ma le conseguenze delle nostre scelte entrano in circolo e ricadono su di noi, molto più che negli altri dipartimenti. \n
- Si manifesta nell’IT, perché l’IT strutturalmente è un’amplificatore di casino.\n\nPrendiamo requisiti contraddittori e speriamo di implementarli in applicazioni non contraddittorie (in bocca al lupo ragazzi!). Siamo incompetenti quanto gli altri ma le conseguenze delle nostre scelte entrano in circolo e ricadono su di noi, molto più che negli altri dipartimenti. \n
- Odio la metafora del dogfood. Veramente la trovo inaccettabile. Io mangio quello che preparo, e preparo cibo di buona qualità.\n\nma nell’IT questo è quello succede. Se produciamo cibo per cani, mangeremo cibo per cani. Se produciamo cose fatte bene, allora possiamo influenzare il nostro ecosistema e quello dell’azienda migliorando la situazione di tutti.\n
- Il problema è complesso. Non posso stabilire chi comincia prima. Non c’è un prima.\nApprezzo infinitamente l’orgoglio e la professionalità di chi dice, “prima di guardare all’esterno dobbiamo guardare all’interno”, ma è tutto da dimostrare che questa sia una soluzione valida in ogni contesto. Se il contesto è tale che il vicino di casa scarica il pattume nel nostro guardino ...hai voglia a fare dei kata di pulizia del giardino! Non è un problema di velocità, ma di conoscenza e di etica.\n\ne ... DEVI PARLARE CON IL VICINO. \n\nNon necessariamente armato.\n
- E se volete approfondire il tema delle strutture alternative alla piramide, ho trovato estremamente interessante l’intervento di Niels Pflageing a Stoos Stampede (Amsterdam 2012) sulle strutture alternative alla piramide.\n\nVeramente molto interessante.\n
- Come è molto interessante il fatto che buona parte di questi temi non siano più confinati solo al mondo dello sviluppo software agile, ma siano patrimonio di una comunità più vasta.\n\nAgile sta procedendo a braccetto con la comunità Lean da un po’. Radical Management mostra come ci sia un nuovo modo di fare management e gli esempi salienti vengono - pensate un po’ - dal mondo dello sviluppo software. Beyond Budgeting è partito sfidando la madre di tutti i waterfall: il budget annuale, ed è andato oltre. Management 3.0 ha contaminato lo sviluppo software con influenze da tutti i questi campi, inclusa la teoria della complessità, per poi arrivare all’iniziativa di Stoos verso un nuovo modo di fare ...sostanzialmente tutto.\n\nNon è più solo sviluppo software.\n
- Come è molto interessante il fatto che buona parte di questi temi non siano più confinati solo al mondo dello sviluppo software agile, ma siano patrimonio di una comunità più vasta.\n\nAgile sta procedendo a braccetto con la comunità Lean da un po’. Radical Management mostra come ci sia un nuovo modo di fare management e gli esempi salienti vengono - pensate un po’ - dal mondo dello sviluppo software. Beyond Budgeting è partito sfidando la madre di tutti i waterfall: il budget annuale, ed è andato oltre. Management 3.0 ha contaminato lo sviluppo software con influenze da tutti i questi campi, inclusa la teoria della complessità, per poi arrivare all’iniziativa di Stoos verso un nuovo modo di fare ...sostanzialmente tutto.\n\nNon è più solo sviluppo software.\n
- Come è molto interessante il fatto che buona parte di questi temi non siano più confinati solo al mondo dello sviluppo software agile, ma siano patrimonio di una comunità più vasta.\n\nAgile sta procedendo a braccetto con la comunità Lean da un po’. Radical Management mostra come ci sia un nuovo modo di fare management e gli esempi salienti vengono - pensate un po’ - dal mondo dello sviluppo software. Beyond Budgeting è partito sfidando la madre di tutti i waterfall: il budget annuale, ed è andato oltre. Management 3.0 ha contaminato lo sviluppo software con influenze da tutti i questi campi, inclusa la teoria della complessità, per poi arrivare all’iniziativa di Stoos verso un nuovo modo di fare ...sostanzialmente tutto.\n\nNon è più solo sviluppo software.\n
- Come è molto interessante il fatto che buona parte di questi temi non siano più confinati solo al mondo dello sviluppo software agile, ma siano patrimonio di una comunità più vasta.\n\nAgile sta procedendo a braccetto con la comunità Lean da un po’. Radical Management mostra come ci sia un nuovo modo di fare management e gli esempi salienti vengono - pensate un po’ - dal mondo dello sviluppo software. Beyond Budgeting è partito sfidando la madre di tutti i waterfall: il budget annuale, ed è andato oltre. Management 3.0 ha contaminato lo sviluppo software con influenze da tutti i questi campi, inclusa la teoria della complessità, per poi arrivare all’iniziativa di Stoos verso un nuovo modo di fare ...sostanzialmente tutto.\n\nNon è più solo sviluppo software.\n
- Come è molto interessante il fatto che buona parte di questi temi non siano più confinati solo al mondo dello sviluppo software agile, ma siano patrimonio di una comunità più vasta.\n\nAgile sta procedendo a braccetto con la comunità Lean da un po’. Radical Management mostra come ci sia un nuovo modo di fare management e gli esempi salienti vengono - pensate un po’ - dal mondo dello sviluppo software. Beyond Budgeting è partito sfidando la madre di tutti i waterfall: il budget annuale, ed è andato oltre. Management 3.0 ha contaminato lo sviluppo software con influenze da tutti i questi campi, inclusa la teoria della complessità, per poi arrivare all’iniziativa di Stoos verso un nuovo modo di fare ...sostanzialmente tutto.\n\nNon è più solo sviluppo software.\n
- Come è molto interessante il fatto che buona parte di questi temi non siano più confinati solo al mondo dello sviluppo software agile, ma siano patrimonio di una comunità più vasta.\n\nAgile sta procedendo a braccetto con la comunità Lean da un po’. Radical Management mostra come ci sia un nuovo modo di fare management e gli esempi salienti vengono - pensate un po’ - dal mondo dello sviluppo software. Beyond Budgeting è partito sfidando la madre di tutti i waterfall: il budget annuale, ed è andato oltre. Management 3.0 ha contaminato lo sviluppo software con influenze da tutti i questi campi, inclusa la teoria della complessità, per poi arrivare all’iniziativa di Stoos verso un nuovo modo di fare ...sostanzialmente tutto.\n\nNon è più solo sviluppo software.\n
- Come è molto interessante il fatto che buona parte di questi temi non siano più confinati solo al mondo dello sviluppo software agile, ma siano patrimonio di una comunità più vasta.\n\nAgile sta procedendo a braccetto con la comunità Lean da un po’. Radical Management mostra come ci sia un nuovo modo di fare management e gli esempi salienti vengono - pensate un po’ - dal mondo dello sviluppo software. Beyond Budgeting è partito sfidando la madre di tutti i waterfall: il budget annuale, ed è andato oltre. Management 3.0 ha contaminato lo sviluppo software con influenze da tutti i questi campi, inclusa la teoria della complessità, per poi arrivare all’iniziativa di Stoos verso un nuovo modo di fare ...sostanzialmente tutto.\n\nNon è più solo sviluppo software.\n
- Come è molto interessante il fatto che buona parte di questi temi non siano più confinati solo al mondo dello sviluppo software agile, ma siano patrimonio di una comunità più vasta.\n\nAgile sta procedendo a braccetto con la comunità Lean da un po’. Radical Management mostra come ci sia un nuovo modo di fare management e gli esempi salienti vengono - pensate un po’ - dal mondo dello sviluppo software. Beyond Budgeting è partito sfidando la madre di tutti i waterfall: il budget annuale, ed è andato oltre. Management 3.0 ha contaminato lo sviluppo software con influenze da tutti i questi campi, inclusa la teoria della complessità, per poi arrivare all’iniziativa di Stoos verso un nuovo modo di fare ...sostanzialmente tutto.\n\nNon è più solo sviluppo software.\n
- Come è molto interessante il fatto che buona parte di questi temi non siano più confinati solo al mondo dello sviluppo software agile, ma siano patrimonio di una comunità più vasta.\n\nAgile sta procedendo a braccetto con la comunità Lean da un po’. Radical Management mostra come ci sia un nuovo modo di fare management e gli esempi salienti vengono - pensate un po’ - dal mondo dello sviluppo software. Beyond Budgeting è partito sfidando la madre di tutti i waterfall: il budget annuale, ed è andato oltre. Management 3.0 ha contaminato lo sviluppo software con influenze da tutti i questi campi, inclusa la teoria della complessità, per poi arrivare all’iniziativa di Stoos verso un nuovo modo di fare ...sostanzialmente tutto.\n\nNon è più solo sviluppo software.\n
- \n
- \n