La maggioranza ha sempre ragione. O no?

Un intervento di Gabriele Lana sulla mailing list XP nazionale mi convince oggi a pubblicare questa draft in agguato da qualche mese tra i miei post in sospeso.

Gabriele fa riferimento nella sua mail al rigore di un processo, all’autorità all’interno di un team e alle buone pratiche scrivendo:

Durante il primo stadio dell’apprendimento (di qualsiasi cosa) si
devono seguire delle regole per non farsi male e per non fare male,
non c’è molto spazio per la democrazia, se fossi sotto i ferri e ci
fosse un team di medici pronti ad operarti vorresti che per democrazia
vincesse il “per questa volta non ci laviamo le mani prima di
operare”?

Leggere queste righe mi ha fatto subito pensare che avevo intenzione da un po’ di parlare di buone pratiche e di processi di decisione nei gruppi facendo riferimento al dottor Ignác Fülöp Semmelweis, noto come il Salvatore delle madri.

Semmelweis è amaramente celebre per aver scoperto che l’elevata incidenza di febbre puerperale tra le partorienti della sua epoca era dovuta alla scarsa igiene dei medici. Semplicemente i medici non si lavavano le mani, ciò causava un alto tasso epidemico nei reparti ospedalieri e di conseguenza un’alta mortalità tra le pazienti. Fin qui, oggigiorno, nessuna sorpresa. Ti potrai chiedere quindi perché la sua sia stata una storia amara.

Semplicemente i colleghi di Semmelweis decisero di non credere alle sue parole. Anzi, peggio, di non credere ai numeri che Semmelweis portò in sostegno ai suoi argomenti. Lo isolarono, lo screditarono e, sebbene in qualche occasione Semmelweis riuscì anche ad implementare i protocolli igienici che salvarono già in quelle prime occasione vite preziose, il riconoscimento dovuto alle ricerche del medico ungherese arrivarono solo postumi. Addirittura il povero Semmelweis venne estromesso dalla comunità scientifica dell’epoca in virtù di un risentimento diffuso nella classe medica dell’epoca: noi medici causa di queste morti??? Non ci si permetta!

Purtroppo anche in quell’occasione la maggioranza ebbe la meglio, perlomeno in prima battuta – ad un costo comunque alto, anche fosse stato di una sola vita umana.

Il regime democratico assiste spesso ad una sua degenerazione verso un mero criterio numerico maggioritario: “siccome siamo tanti a dire questa cosa, abbiamo ragione sicuramente; tanta gente non può sbagliarsi tutta insieme.” Una specie di principio di autorità distribuito, con tutti i difetti dialettici tipici del principio di autorità.

Nello sviluppo agile si centra molta dell’attenzione sulla condivisione delle responsabilità e delle decisioni e si punta a non ignorare nemmeno le sensazioni che le persone, poste al centro del processo di sviluppo, devono usare come spunto per andare avanti, motivarsi, analizzare la qualità di ciò che si fa e di come lo si fa. Questo potrebbe indurre a pensare che si possa quindi

  1. dirigere i nostri sforzi solo dove ti porta il cuore
  2. ignorare l’oggettività di dati rilevati, anche solo qualitativamente

E invece no! Un solo membro del team che misurasse con precisione sufficiente e in base ad una metrica valida che una scelta di processo porta dei concreti vantaggi al progetto su cui si lavora basterebbe da solo a controvertire il parere congiunto di una muraglia di colleghi più istintivi.

Per questo l’adozione dei metodi agili può essere così ardua nelle aziende che non siano nativamente basate su queste metodologie: perché richiedono l’adozione di un compendio culturale ed etico che deve necessariamente essere presupposto del processo e non conseguenza del processo stesso. Un compendio che permetta da una parte l’individuazione delle vere sorgenti dei problemi, con franchezza, onestà e, perché no, spirito di sacrificio, dall’altra di essere rigorosi quanto basta perché si possa essere certi che la mancanza di risultati sia dovuta ad una vera inappropriatezza di una data pratica al contesto di applicazione e non all’imprecisione nell’attuazione.

Si tratta di essere disposti a guardare in faccia lo stato delle cose, qualunque verità rischi di saltare fuori. Il movimento open source, esponendo il codice e i relativi bug, ci ha abituati al successo di questo approccio riguardo la qualità del codice. Non credi che per la qualità del processo di sviluppo esistano altrettali margini di miglioramento?

June 02 2009 06:56 pm | Visione agile

Trackback URI | Comments RSS

Leave a Reply