[iterazione 2 (27/9)]

Come già il buon FRANK ha notato, ultimamente il blog ha subito mutazioni di look giornaliere e da far girare la testa…

Tutto nasce dal post sul TDD e gli Unit Test che con il tema vecchio di wordpress, veniva visualizzato in modo poco chiaro. Da lì è cominciata la ricerca del tema, che per ostinazione somigliava più a quella del Santo Graal che ad un semplice cambio di look del sito. Sono infatti caduto nel problema del “Best is the enemy of Good“(TM), cambiando di giorno in giorno il tema senza mai esserne soddisfatto, al punto che il mio amico Simone è arrivato a dirmi “l’agile enri disagilizzato da un tema!”… Di seguito la mia breve autodifesa: Read the rest of this entry »

Chi mi segue da questa piccola finestra (la puntata precedente è comunque qui) sa che da circa un mese non mi è più “permesso” di scrivere codice in PP: il mio attuale e unico collega infatti è allergico alle coppie. Non solo, purtroppo io ed il mio collega abbiamo anche principi prospettive di visione del codice molto differenti, direi addirittura opposte. Ma non è del mio collega (per altro simpatico e di vecchia data) che vi voglio parlare, quanto invece delle mie reazioni e dei miei peccati in questo mese.

Nell’ultimo mese e fino a qualche giorno fa ho prodotto software di bassa qualità, voglio cercare di capire il perché con voi. Sicuramente e per onestà nei miei confronti il motivo principale è la scarsissima conoscenza dei tool utilizzati. Ma questo lo sapete già. Più interessante è invece come il rapporto tra me ed il mio collega, i miei timori e il disallineamento di valori hanno influenzato la mia capacità di creare qualità.

Read the rest of this entry »

Se volessimo estendere i valori Agili non solo al processo di sviluppo, ma a tutta la struttura organizzativa di cui fa parte un team, in modo ricorsivo trasversale a tutta la società, a cosa si arriverebbe? La risposta probabilmente è: un sistema sociocratico.

Un sistema sociocratico si basa su queste quattro pratiche:

Decisioni prese “by consent”
Termine inglese che si differenzia dal più comune “consensus”: la nozione di consensus è tipica dei sistemi democratici, cioè dei sistemi basati sulla quantità di voti (cioè di consensi) ricevuti a fronte di una proposta.
Il consent invece è il principio del “nessuna obiezione”. In pratica se un membro del gruppo propone qualcosa, questo qualcosa viene accettato se nessun altro membro del gruppo muove obiezioni serie, ragionate, e di somma importanza. Ciò garantisce che ogni decisione sia nei limiti di tolleranza di tutti gli aspetti del sistema nel momento in cui tale proposta viene effettuata.
Obiezioni del tipo “potrebbe accadere che…” o “penso che potremo trovare…” non sono valide. Qui entra in gioco il paradigma agile: per scoprire obiezioni valide scrivi ed esegui un test. Vuol dire che se ci si trova di fronte ad un problema da risolvere, per trovare la soluzione migliore, non si passano ore in riunioni, ma si propone “by consent” di provare “una” soluzione, così da collezionare dati e misure che permetteranno di migliorare la strategia fino a quel momento adottata. Esattamente come quando si scrive del codice: test-minimal code-refactor. Provare e sperimentare! In questo modo le obiezioni diventano realmente una grande risorsa migliorativa, perché di fatto si trasformano in analisi degli output e dei fallimenti. L’adagio di Kent Beck ancora una volta si rivela fondato: “quando non sai come avere successo, fallisci”.
Tutte le decisioni in un sistema sociocratico sono prese “by consent”, a qualsiasi livello.

Organizzazione a cerchi
L’organizzaione è costruita su una gerarchia di cerchi semiautonomi. Questi cerchi sono team con propri propositi ed obiettivi, che mantengono una propria memoria, e soprattutto si organizzano in modo autonomo (hanno un proprio processo) per raggiungere gli obiettivi posti dal cerchio superiore.

Double Linking
Ciascun cerchio è un “holon”, un “tutto” completo che è anche parte di un tutto più largo (ad esempio un team che è parte di un dipartimento, ecc). Le decisioni e le azioni intraprese da un cerchio non sono completamente indipendenti da quelle prese dagli altri cerchi vicini. Ogni cerchio ha il diritto di essere rappresentato nelle decisioni che lo coinvolgono, partecipando alle decisioni prese “by consent”. Il double linking prevede che vi siano almeno due persone che collegano un cerchio con un altro: una persona scelta dal cerchio superiore e l’altra scelta dal cerchio che gli sta sotto. Ciascuna di queste persone rappresentano il contesto del cerchio di cui fanno parte.
Il sistema di cerchi forma così un’”olarchia”, cioè un sistema di holon collegati tra loro.

Elezioni by consent

Tutte le elezioni (dei rappresentanti o dei leader) avvengono by consent dopo oppurtune discussioni aperte.Questo è quanto. Altra cosa importante di questo sistema è che il leader (cioè semplicemente chi pone obiettivi di alto livello) di un cerchio non è un componente del team stesso, ma un membro del cerchio superiore.Personalmente ritengo questo modello molto stimolante per i membri del team soprattutto per mezzo delle decisioni by consent. Ho sempre creduto infatti che ogni persona all’interno di un team debba avere voce di ugual peso a quella degli altri membri del team, qualsiasi sia il ruolo che ricoprono. E’ interessante notare come questo modello, al contrario di quanto si possa credere, dà orgine ad un sistema dove i conflitti e le situazioni in cui sia necessario l’intervento di un qualche “paciere” sono ridotte al minimo. Altra cosa interessante è che questo modello è applicato, tra le altre, da un’azienda di informatica, la TernarySoftware.Sicuramente ne parlerò ancora in futuro, magari chiarendo a cosa porta un sistema così fatto dal punto di vista dei rapporti tra le persone e dell’efficienza del processo.
Alcuni link per chi voglia approfondire l’argomento:
Ternary
Brian Robertson blog
Sociocracy
Intervista a Robertson