Parte II/II
Nell’articolo precedente abbiamo introdotto i concetti di Antipattern e System thinking.
In estrema sintesi abbiamo definito gli Antipattern come dei design pattern, o più in generale delle procedure o modi di fare, usati durante il processo di sviluppo del software, che pur essendo lecitamente utilizzabili, si rivelano successivamente inadatti o controproduttivi nella pratica.
Abbiamo detto che in molti casi gli Antipattern possono essere evitati, o almeno riconosciuti e affrontati in modo più efficace, adottando un approccio di system thinking, che propone un modo di integrare persone, obiettivi, processi e prestazioni.
Occorre sottolineare però che tale approccio consente anche di:
- mettere in relazione i Sistemi con il loro ambiente
- comprendere le situazioni inerenti a problemi complessi
- massimizzare i risultati raggiunti
- evitare o minimizzare l’impatto di conseguenze non intenzionali
- allineare gruppi di lavoro, discipline specialistiche e non, gruppi di interesse
- gestire incertezza, rischi ed opportunità
- creare valore
Il vero pericolo che viene dagli adattamenti alle pratiche consolidate è infatti che si finisca per “diagnosticare” (in effetti misurare) l’effetto delle modifiche apportate, piuttosto che consegnare vero valore al cliente.
Ciò è evidente e particolarmente controproducente, quando ad esempio, poniamo l’accento sull’aumento di velocità di un team, che ha deciso di seguire questa strada per ottenere più tempo per lo sviluppo.
L’aumento di velocità in questo caso, dimostra solo che questo adattamento sta “funzionando”, ma non significa che il team stia consegnando vero valore, cosa che può essere evidenziata solo a livello di altri indicatori, ad esempio quello della “qualità del software”. Inoltre, se queste “modifiche” sono fatte (e spesso lo sono) senza riferimento e comprensione del sistema nel senso più ampio (sia a livello di team che a livello organizzativo) e quindi non si sono ben capiti né la causa né l’effetto risultante, i problemi si perpetuano aggiungendo ulteriori modifiche per accogliere o compensare quelle originali.
Ci sono poi una serie di fattori ambientali che favoriscono questo modello di Antipattern, il principale è la prontezza dei componenti del team agile a dimostrare flessibilità di adattamento a requisiti organizzativi e sistemici più ampi, cioè in un contesto che riguarda la “gestione agile” complessiva dell’azienda.
Questa mancanza di flessibilità, spesso si manifesta all’interno di programmi di trasformazione agile adottati dalle organizzazioni, in cui qualsiasi trasformazione reale è localizzata a livello di team e non viene trasmessa con successo all’organizzazione nel suo complesso, poiché i “canali di connessione” tra il team e il sistema all’interno del quale esso risiede hanno interazioni forzate in contesti di costo, ambito e tempo. In questo modo, detta trasformazione a livello di squadra, avviene solo al fine di compensare una mancanza di cambiamento di visione del sistema nel suo complesso.
In sintesi, in molte aziende, la complessità organizzativa si traduce in problemi organizzativi che a loro volta diluiscono l’efficacia delle soluzioni che l’organizzazione e i suoi team agili possono creare e implementare. Questo problema è aggravato dal fatto che spesso, i sostenitori del cambiamento agile creano impatto a livello di squadra e hanno un ambito limitato per effettuare il cambiamento all’interno dell’organizzazione più ampia.
Un approccio system thinking, dovrebbe essere visto come un mezzo per confondere i confini e ridurre la rigidità delle barriere tra i team agili e l’organizzazione più ampia. Un principio chiave è che si riconosca che le prestazioni del sistema non sono la somma delle sue parti; piuttosto che esso è il risultato delle interazioni tra queste parti.
Gli Antipattern che emergono e persistono sono spesso il risultato delle inefficaci interazioni tra team agili e il più ampio sistema organizzativo all’interno del quale operano.
Pensando ai sistemi in questo modo, possiamo iniziare a riconoscere gli schemi, che caratterizzano queste interazioni subottimali e così facendo, possiamo effettuare cambiamenti che affrontano le “cause” anziché i sintomi.
Il vecchio adagio secondo cui “i problemi di oggi sono le soluzioni di ieri”, incapsula la natura problematica degli Antipattern, ma suggerisce anche la natura evolutiva del panorama di risoluzione dei problemi.
È importante stabilire se il team o l’organizzazione ha una storia di adozione di Antipattern e riconoscere che il più delle volte questi ultimi sono il risultato di interazioni inefficaci tra i team agili e i sistemi in cui operano.
Vale la pena categorizzare le problematiche sollevate e le soluzioni proposte a livello di team, in modo che queste possano essere trattate in modo non solo tempestivo ma anche strategico (causa ed effetto non siano sempre strettamente collegati sul perimetro di azione attuale e nel tempo presente) e quindi possiamo identificare con più esattezza da dove proviene il problema e se l’azione intrapresa si farà sentire nello stesso spazio.
I team Agile ad alte prestazioni sono abili nel creare trasparenza all’interno del proprio gruppo di lavoro, ma l’uso di un approccio basato sul system thinking, può creare in modo più efficace la trasparenza in termini di come il team Agile interagisce con il sistema.
Ciò rende più facile evidenziare dove queste interazioni sono inefficaci o dannose e come queste interazioni si manifestano come Antipattern.
