The reason for EPOC "is the general disturbance to homeostasis brought on by exercise" (Brooks and Fahey, "Exercise physiology. Human bioenergetics and its applications", Macmillan Publishing Company, 1984).
In the next few days, inspired by different readings, I began thinking of process as the company's homeostatic system.
I've often claimed that companies have their own immune system, actively killing ideas, concepts and practices misaligned with the true nature of the company ("true" as opposed to, for instance, a theoretical statement of the company's values).
However, the homeostatic system has a different purpose, as it is basically designed to (wikipedia quote) "allow an organism to function effectively in a broad range of environmental conditions". Once you replace "organism" with "team", this becomes the best definition of a good development process that I've ever (or never :-) been able to formulate.
It is interesting to understand that the homeostatic system is very sophisticated. It works smoothly, but can leverage several different strategies to adapt to different external conditions. In fact, when good old Gerald Weinberg classified company's cultural patterns on the 1-5 scale, he called level-2 companies "Routine" (as they always use the same approach, without much care for context), level-3 "Steering" (dynamically picking a routine from a larger repertoire) and level-4 "Anticipating" (you figure :-). Of course, any company using the same process every time, no matter the process (Waterfall, RUP-inspired, XP, whatever), is at level 2.
For instance, if we find ourselves working with stakeholders with highly conflicting requirements and we don't apply a more "formal" process based on the initial assessment of viewpoints and concerns (see, for instance, my posts Value and Priorities and Requirements and Viewpoints for a few references) because "we usually gather users stories, implement, and get feedback quickly", then we're stuck in a Routine culture. Of course, if we always apply the viewpoints, we're stuck in a Routine culture too.
Well, there would be much more to say, especially about contingent methodologies and about congruency (another of Weinberg's favorite concepts) between company's process and company's strategy, but time is up again, so I'll leave you with a question. We all know that some physical activity is good for our health. Although high-intensity exercises bring disturbance to homeostasis, in the end we get a better homeostatic system. So the question is, if process is the company's homeostatic system, what is the equivalent of good training? How do we bring a dose of periodic, healthy disturbance to make our process stronger?
14 comments:
Magari un team di R&D che si occupi di sperimentare nuovi processi? forse sarebbe un po' antieconomico a conti fatti...:D
Premetto che non dedico mai tempo all'attività fisica, eccetto le faccende domestiche, e quindi non mi ossigeno mai abbastanza da avere brillanti idee.
Salire di livello non è facile e poi più si va in alto più costa fatica. Pensate alle ascese in montagna.
Ricerca e sviluppo potrebbe essere una buona attività perturbativa che però, per sua natura, porta frutti. Forse ho già detto che in passato, quando ero alle prime armi con la programmazione, (e forse per questo con più tempo a disposizione) amavo scrivere pezzi di codice per vedere come risolvere determinati problemi preso semplicemente da curiosità. Puntualmente, dopo non molto, tante di quelle soluzioni venivano impiegate produttivamente nel lavoro di ogni giorno. Attualmente, vista la discreta mole di codice a disposizione (personale e reperibile in internet), capita raramente di fare quest'attività di ricerca. Trovo comunque profittevole sondare in micro-progetti strade alternative. Mi sembra che hai scritto qualcosa in proposito. Così facendo diminuisce l'inerzia che con l'aumentare dell'età diviene notevole e contribuiamo a ridurre l'accumulo di ruggine fra i nostri neuroni...
Mi rendo conto che ho scritto più o meno la stessa cosa di Fulvio. Pare copiato, anche se detto con più parole.
Fulvio, Romano: la domanda era piu' difficile di quel che sembrava :-).
La metafora:
corpo umano <-> azienda
sistema omeostatico <-> processo
va colta a fondo.
Mettere un team dedicato di R&D a sperimentare processi e' come mettere qualcun altro a fare esperimenti di biologia. Il mio sistema omeostatico non cambia.
L'attivita' che suggerisce Romano e' diversa, e credo che andrebbe sempre praticata, ma non e' relativa al processo. Romano giustamente fa notare come sperimentare con idee, tecnologie, soluzioni che non ci sembrano di immediata applicazione ci fa comunque diventare piu' bravi, e che cio' che sembra non immediatamente utile tende a diventarlo in modo inaspettato e repentino. Ma non e' un "training" del processo aziendale, e' una attivita' personale.
Chi ne ha voglia, giochi ancora un po' con l'idea :-)
Secondo me il punto è "accettare sfide".
Lo sport è rigenerante e proficuo se le attività sono leggermente superiori alle proprie capacità. Certo, esiste un livello di mantenimento e di routine ma con una certa frequenza è necessario "mettersi in gioco" per 1) misurarsi 2) evolvere. La cosa deve avvenire entro parametri di sicurezza per non compromettere l'organismo nel suo complesso (estremamente pericoloso affrontare l'everest se le imprese abituali sono le collinette dietro casa) ma è indispensabile per mantenere passione, interesse e attenzione (se continuo a salire sempre la stessa collina probabilmente prima o poi mi fermerò direttamente al bar ;-)
Applicato ad un gruppo significa che: evoluzioni tecnologiche, messa in cantiere di nuove funzionalità un po' ardite, accettazione di tempi magari un po' più ristretti del solito possono essere il tipo di allenamento che rinsalda il gruppo e gli fa scoprire nuove "ricette".
Anche qui c'è un limite di guardia oltre il quale si creano situazioni di tensione fra componenti del gruppo o con la direzione e che possono diventare punti "di non ritorno" che necessitano di mesi o anni (nello sport l'equivalente è di una gamba rotta per aver voluto strafare) per essere appianati
Penso che questo punto di vista e questa similitudine si possano sviluppare ulteriormente. Esempio: a cosa è dovuto è il fallimento di un azienda? il fatto che ha affrontato una sfida troppo superiore alle proprie capacità o viceversa si è adagiata sugli allori. Ne consegue che il ruolo di una direzione illuminata è quello di "allenatore": scelgo gli incontri (per usare un termine pugilistico) in base alla capacità del team
Significa che un management illuminato mette in conto che è possibile non centrare tutti gli obiettivi che si è posto (non si può vincere tutti gli incontri) ma, se è capace, avrà anche svolto trattative di mercato in modo trasparente ed esperto mettendo in conto di dover gestire un cliente inizialmente insoddisfatto (In nessun campionato scendo di categoria a causa di un solo incontro andato male!)
Ritornando al team (e lasciando il management che comunque non mi compete ;-) se c'è un livello di guardia oltre il quale ci "si rompe la gamba" c'è comunque un livello sopra il quale "manca un po' il fiato" (acc. dover riaprire un libro e magari rischiare di fare un po' la figura degli ignoranti)
"i muscoli dolgono" (accidenti perchè va così lento!, come cavolo si fa a fare il profiling in questa versione del Visual, etc.)
Un altro punto di contatto tra similitudine e realtà è la soddisfazione finale: i 200 metri di dislivello in più rispetto alle fatiche solite 1) ti caricano per la prossima volta 2) ti fanno dimenticare i "crampi" (tensioni createsi, figure da ignorante) 3) ti "allungano il fiato" per la prossima salita
Forse mi sono fatto prendere troppo dal parallellismo ma l'idea di Carlo ha avuto il grande pregio di farmi riflettere e questo è sempre ... un ottimo allenamento ;-)
Grazie
Marco: ottimi spunti, hai centrato bene il parallelismo; occorre, come hai fatto notare, prendere dei rischi calcolati, uscire dalla propria comfort zone, spingersi dove prima non si arrivava.
Sulla gestione del rischio connesso con questa attivita' di "training" ci sarebbe molto da dire, prima o poi trovero' il tempo. E' utile ricordare subito il concetto di portfolio, che si applica sia ai diversi progetti aziendali che al singolo progetto complesso. Un portfolio azionario ben scelto distribuisce il rischio intrinseco di un mercato volatile. Un portfolio di progetti, e di feature nella singola release di un progetto, distribuisce il rischio in modo bilanciato se scegliamo il giusto portfolio (cosa che molte aziende non fanno :-).
E' utile notare, peraltro, come l'idea di spingersi fuori dalla comfort zone richieda spesso un adattamento, o una modifica, del processo. Ad esempio, molte aziende di automazione sono cresciute con la tecnica del copy&paste: si prende la commessa piu' simile, si clona tutto il codice, si scrive la prossima commessa. Spingersi fuori, verso un modello a componenti riusabili, richiede un cambiamento notevole, che va ben pianificato e distribuito, un po' come allenarsi per la maratona :-).
Per varie ragioni, mi torna alla mente anche un pensiero di Tom DeMarco in "Why does software cost so much" (peraltro un libro molto carino). Tom dice, ad un certo punto: benefit is maximized by taking chances and venturing into new territory. Productivity is improved by familiarity and repetition. [...] Is this progress? [...] Have we missed an opportunity to build one meta-product [...]?
Da questa riflessione Tom deriva il DT#5: (il signigicato di DT e' lasciato come esercizio :-) Are we learning to do best what we shouldn't be doing at all?
Le (non necessariamente ovvie) relazioni con certi principi tipo "fare la cosa piu' semplice che funzioni" et similia sono troppo provocatorie per essere espresse :-).
Nota a margine: ovviamente, quando spostiamo il focus dalla societa' / team al singolo, torna ad essere interessante anche quanto diceva Romano, ovvero di mantenere interessi varii, esplorare senza pressione argomenti di non immediata utilita', eccetera. Il grande :-) Tom Peters suggeriva ai manager "suprise yourself with your readings", consigliando di leggere a proposito di argomenti anche molto distanti dai loro abituali interessi. Io credo possa essere un buon consiglio per tutti :-).
A proposito di uscire dalla "comfort area", nel prossimo futuro potrei assumere un nuovo ruolo dai contorni non perfettamente definiti. Il ruolo assomiglia a quello di engagement manager, ma non si limita solo a quello. Un aspetto che dovrò curare è il project management.
Probabilmente in questo campo l'esperienza, unitamente ad una buona apertura mentale, rappresenta la migliore formazione. Tuttavia mi domandavo se avete letture da consigliarmi sull'argomento. Grazie.
La letteratura sul Management e' molto ampia, il subset sul Project Management sempre molto ampio, sul Software Project Management le cose vanno un po' peggio, nel senso che a mio avviso i testi di valore sono pochi.
Pero' esistono libri che io definirei "di riferimento", nel senso che non si possono non leggere (e meditare):
- i 4 volumi "Quality Software Management" di Gerald Weinberg. Se 4 vi spaventano :-), leggete almeno i primi 2.
- The Laws of Software Process" di Armour, anche questo un libro che ho citato spesso nei miei post.
Un paio di testi "complementari", molto semplici da leggere ma con buone idee a cui lo sviluppatore non viene normalmente esposto:
- "Peopleware" di DeMarco e Lister
- "Journey of the Software Professional" di Hohmann.
Un altro testo che ogni tanto ho citato, e che contiene buone idee quantitative, e' "Software by Numbers", di Denne e Cleland-Huang.
Poi a mio avviso, nel medio termine, non farebbe male prendere una buona confidenza con la letteratura generale sul management. Sfogliarsi ogni tanto Harvard Business Review, insomma, male non fa :-).
Di metafora in metafora, aggiungerei che uno dei fattori critici per l'omeostasi di un organismo è il suo sistema immunitario: è infatti esso a stabilire la prima linea di confine fra l'organismo e il mondo esterno, è la fondazione biologica del principio di identità.
E' interessante la patologia auto-immune: per esempio quando, faccio per dire, un programmatore "si converte" a un altro paradigma di programmazione o a un'altra metodologia di sviluppo... rischiando di venire considerato corpo estraneo.
Scherzi a parte, ho l'impressione che nel tuo post tu abbia evitato volontariamente di mettere sotto i riflettori il passaggio fondamentale del tuo ragionamento. L'elemento indispensabile per l'omeostasi è il feedback: la "raccolta informazioni" su cui si basa la "correzione di rotta" per mantenersi nella zona di equilibrio. Applicare la metafora alle strutture sociali, significa chiedersi: qual è la percezione che il gruppo/azienda/team ha di se stesso? Solo dopo si può discutere dell'efficacia dei correttivi che tentano di introdurre. E il vagliare nuovi elementi, integrarli o respingerli è esattamente il contributo immunitario alla omeostasi: è quello che le conferisce la sua evolutività.
Guido Marongiu
guidomarongiu@yahoo.it
Sono giorni che mi ripropongo di prendere parte alla discussione ma poi non trovo mai il tempo necessario quindi butto li velocemente uno spunto:
la mia visione di fondo e' quella di un sistema autopoietico (cosi come definitoda Maturana e Varela nel loro lavoro seminale "Autopoiesis and Cognition: The Realization of the Living".
L'argomento e' complesso e c'e' tantissimo materiale al riguardo (non + solo in biologia).
In particolare penso che la definzione di macchina autopoietica come un sistema omeostatico sia centrale all'argomentazione che Carlo ha portato.
Spero di trovare il tempo di contribuire di + a questa discussione.
Guido,
piuttosto curiosamente, nella prima stesura del post parlavo anche di malattie autoimmuni (con tanto di link a wikipedia), poi mi pareva diventasse un po' troppo lungo (e forse "specializzato") ed ho rimosso quella parte.
Pero' l'ho tenuta :-) e quindi incollo qui il passaggio piu' rilevante:
Sometimes the immune system of a company gets messed up and develops some sort of autoimmunity, where different functions or business units inside the same company are constantly fighting each other.
Esempi tipici di malattie auto-immuni delle societa', piu' che il programmatore che si converte ad un altro paradigma, sono proprio i diagrammi degli effetti (disfuzionali) che ho mostrato in alcuni vecchi (e meno vecchi) post. Gruppi che non si riconoscono come parte della stessa azienda, manager e sviluppatori in conflitto permanente e distruttivo, eccetera.
Un link che volevo aggiungere in coda al post, e che si ricollega molto bene a quanto dici sulla percezione che l'azienda ha di se stessa, era relativo al post An organization consists of conversations, ed in particolare al pamphlet che li' suggerisco (e che continuo a suggerire). Non si fatichera' a vedere l'adozione di una nuova struttura comunicativa come un eccellente "training" dell'azienda, in grado di assestare il sistema omeostatico ed immunitario su migliori equilibri.
Chi ama cercare connessioni tra soggetti diversi potrebbe anche trovare interessante riflettere sull'analogia tra sistema immunitario e la funzione della "tradizione" citata nel mio post On the concept of Form (1)
Marco,
come direbbe un tizio che conosco: "ah, andiamo sul pesante" :-)))).
Scherzi a parte, mi sfugge un piccolo :-) dettaglio: cosa esattamente vedi come un sistema autopoietico? Forse la societa' nel suo insieme, piuttosto che il processo che utilizza?
Grazie per i consigli sul SPM. Comprerò il libri suggeriti.
Da altre fonti ho ricevuto nuove indicazioni tra cui una che vorrei condividere con voi:
The New CIO Leader: Setting the Agenda and Delivering Results
Grazie, e' un libro che non conoscevo, e fa sempre bene conoscerne altri :-).
Ho dato un'occhiata su amazon (table of contents e excerpt), e' sicuramente un libro molto diverso da quelli che suggerivo io, sia nello stile che nei contenuti.
Il che, ovviamente, non fa male... :-)
Post a Comment