Category Archives: ALM

Application Lifecycle Management

La congiunzione astrale dell’indipendenza del Verbo

Qualsiasi trasformazione richiede tre elementi fondamentali: tempobudgetsponsorship. Questo è un dato di fatto a prova di smentita, tant’è che il venir meno di uno di essi compromette fortemente, se non inesorabilmente, le possibilità di successo dell’azione intrapresa.

In particolare, è necessario riflettere molto sulla sponsorshipe capire se essa sia reale opportunistica:

  • la sponsorship è realequando gli sponsor sono i primi ad essere coinvolti nell’azione di trasformazione, calandosu di sé quando si sta sperimentando e accettandodi rimettersi in gioco, consci che il tutto possa portare un reale beneficio all’intera organizzazione. Bisogna essere convinti della necessità del cambiamento, unitamente ad una buona dose di umiltà e capacità di guardarsi intorno per capire se il percorso intrapreso sta portando benefici;
  • la sponsorship è opportunisticaquando non è minimamente sentita, ovvero quando si supporta un cambiamento solo perché “qualcuno lo ho detto o perché tutti lo fanno”. In tal caso si cerca di piegare la stessa ai propri interessi, intervenendo fortemente nelle diverse azioni al fine di plasmarle secondo le proprie necessità e mantenere la propria confort zone, eventualmente appuntandosi una nuova “etichetta” che però non modifica la sostanza. 

Come diceva Tancredi ne “Il Gattopardo”: Se vogliamo che tutto rimanga come è, bisogna che tutto cambi… e quindi bisogna fare molta molta attenzione nel rispondere rapidamente alla condizione che ci vede difronte ad una sponsorship opportunistica. 

lampedusa gattopardo

Purtroppo, è molto difficile riuscire inizialmente ad indentificare la specificità: solo il tempo ci da la possibilità di captarecapireed analizzarei segnali ed i fatti che possono portarci ad avere un’idea in merito. 

Un elemento che però è fortemente indicativo è l’Indipendenza degli Agenti di Trasformazione (o dei Coach se siete in chiave Agile), che devono potersi muovere calando sulle evidenze le azioni che ritengono più consone, dando messaggi chiari che evidenzino sempre quale sia l’obiettivo ideale e quali, invece, sono i compromessi da accettare per cominciare ad innescare il cambiamento e generare miglioramenti.

Guai se i messaggi sono “tarati” sui desideri dello sponsor: in questo caso non stiamo solo dicendo addio al nostro “viaggio”, ma anche alla credibilità stessa dell’approccio che stiamo proponendo. Nessun commento superfluo è ovviamente utile per definire chi si presta a tale azione.

Se si verifica una congiuntura astraleche allinea tutti questi elementi, il risultato ultimo si sintetizza con una frase che purtroppo si sente non di rado: “Agile non funziona!”che di per sé è priva di significato essendo Agile un mindset formato da Valori e Principi e non da processi che invece vanno contestualizzati… …nel modo giusto.

Stay tuned J

La frizione implosiva del connettore sdoppiato

Non di rado si assiste alla creazione di un ruolo aggiuntivo nei team Agili che si imbarcano nel lungo e tortuoso cammino della propria evoluzione: si tratta del Team Leader.

Come sappiamo, Scrum, non contempla questa figura specifica, mentre, ad esempio, in Disciplined Agile Delivery è contemplato il ruolo di Team Lead, inteso come colui che supporta il team nella crescita organizzativa e che può assumere anche alcune connotazioni tecniche a supporto (spesso, nei piccoli contesti, il Team Lead è anche l’Architecture Owner).

 

dad roles

DAD Roles

Se si istituisce il ruolo di Team Leader, il focus di chi lo impersona (attenzione alla solita questione ruolovs posizione) è quello di supportare la crescita del teamin chiave Servant Leader, sia in ambito organizzativo che in ambito tecnico.

Operando in quest’ottica, l’approccio permette di creare una figura chiave che diventa un connettoredel team con le diverse interfacce aziendali, andando effettivamente ad accelerare la crescita dell’autonomia del singolo team e creando un ecosistema in grado di operare secondo i più nobili principi agili.

Esistono però tutta una serie di rischi relativi: primo tra tutti, il Team Leader non deve diventare il “capo” del team che dice agli altri cosa fare. Purtroppo, si tratta di una deriva spesso comune, sorretta anche dalla difficoltà dell’organizzazione stessa nell’inquadrare correttamente il ruolo. Se si torna ad operare in chiave command-and-control, il team agile smette semplicemente di esistere, trasformandosi in un insieme di persone a cui vengono assegnate attività che sono definite, decise e strutturate da qualcun altro.

Inoltre, il Team Leader non riesce a “coltivare” la crescita del team, trasformandosi a sua volta in una sorta di “controllore” e “passa carte”, ovvero uno strumento di un’organizzazione strettamente piramidale.

Certo, è possibile avere due figure separate, una per il “Team Leader” e l’altra per Scrum Master/Coach, all’interno di un singolo team, ammesso che questo sia economicamente sostenibile. Il rischio è quello di creare due figure “lead” per il team, generando confusione e anche frizione:chi è più qualificato nel prendere decisioniChi risponde ai quesiti?Chi dirime le controversie tra i due? Insomma, la cosa può funzionare, ma richiede una forte maturità e la capacità personale di capire il proprio perimetro operativo.

InterruptionCop

Nel caso in cui il tutto resti estremamente nebbioso, il rischio è che il team cominci a procedere in modo indipendente, ovvero prendendo decisioni localiper ottenere quanto possibile, senza però preoccuparsi del perché delle cose e, soprattutto, rendendo di fatto il ruolo del Team Lead una sorta di “guscio vuoto”.

Si crea così una spirale implosivache porta ad una rottura di fiducia tra il Lead e il team (eventualmente anche con lo Scrum Master ed il Coach) che a sua volta si trasforma in frustrazione e incapacità di produrre miglioramenti sui diversi fronti. 

In generale, il Team Leader non deve necessariamente essere il “più bravo”, ma deve essere una persona capace di ispirare gli altri e mettersi al servizio del team e dell’organizzazione per generare valore, gestendo rapidamente i rischi, attivando quanto e chi necessario per risolvere gli impediment e celebrando i successi del team.

Il suggerimento è sempre quello di individuare persone che abbiano una spiccata capacità di “guardare agli altri”, con forte esperienza in ambito Agile e che abbia maturato competenze tecniche a differenti livelli tanto da porre la tecnologia a servizio del Business e non piegare quest’ultima in funzione della prima.

E ricordate: si tratta di un ruolo, per cui se la persona candidata/scelta non si trova a suo agio o non è accettata dal team… si può sempre cambiare!

 

Stay tuned J

Il panorama nebbioso della terminologia ambigua

DevOps oppure Agile? Ma sono la stessa cosa? Che c’entra Lean?… il nostro mondo è un mondo che sembra amare la confusione, fattore che, unito alla complessità tipica dei problemi affrontati, porta ad un panorama nebbioso che sembra non diradarsi mai.

La tendenza è ormai ventennale, tant’è che gli stessi autori di Scrum utilizzano spesso la Teoria dei Giochi per descrivere il proprio framework, mettendone in evidenza i principi di equilibrio e muto interesse. Tutto bello, ma possibile che non riusciamo a trovare un modo sintetico per raccontarlo a chi vuole andare diritto al sodo?

Stesso problema per Deploy e Delivery: cosa li differenzia? Da un lato, fino a qualche anno fa, si parlava di Deploy per indicare il rilascio fino agli ambienti di pre-produzione, mentre la Delivery era il rilascio finale in produzione. Ok, ma in fondo cosa cambia da un punto di vista tecnico? Probabilmente ben poco e se si automatizza l’ultimo miglio (dalla Continuous Integration al Deployment in produzione) tendenzialmente niente.

Ecco che quindi oggi, con l’ascesa di DevOps, il Delivery viene ricondotto al più nobile significato contemplato in Lean, ovvero la produzione continua di Valore per il cliente…. interessante, ma… un attimo… ricordiamoci del primo principio dell’Agile:

La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua”

hmmm… praticamente dice la stessa cosa…siamo di nuovo punto e a capo!

Anche le pratiche che vengono definite di DevOps sono riconducibili all’Agile: si pensi alla Continuous Integration, Pratica di Extreme Programming.

Provando a cercare qualche suggerimento in letteratura, un post di Sakshi Gaurav propone una interessante lettura di DevOps rispetto all’Agile, secondo la quale:

            “DevOps è una pratica, laddove Agile è un Processo”

presentando un’infografica che mette a confronto le due affermazioni.

devops to agile infographics

Ora, per quanto è vero che, comunemente, Agile viene associato agli aspetti di sviluppo, mentre DevOps a quelli di rilascio, se si legge il tutto in chiave Lean, dove è importante ragionare in termini di Value Stream e di organizzazione complessiva e non locale, qualcosa sembra non tornare in questo… e anche i framework di Scaling mixano il tutto.
Quindi DevOps non può essere ricondotto solo a “pratiche e tool”, ma ad una visione complessiva che coinvolge anche team terzi (differenti da Dev e Ops) ma comunque funzionali alla creazione di una Soluzione Consumabile, così come enfatizzato da Disciplined DevOps.

La definizione che spesso mi piace utilizzare è che “DevOps è la declinazione più efficace di Lean applicato al mondo del Software”, una sorta di Lean Software Development 2.0, in cui i tool hanno un forte impatto perché ormai maturi a supportare l’automazione dell’ultimo miglio ma il tutto è sempre funzionale ad obiettivi di business. Si parla quindi di Work Center e, in quest’ottica, Dev e Ops sono il fulcro delle attività, con Dev che utilizza gli approcci Agili ben consolidati, estendendoli ad Ops, e Ops che si occupa di creare l’infrastruttura a supporto per il deployment (fino in produzione) e garantire l’affidabilità dei servizi, condividendoli con Dev.

Se poi vogliamo completare il discorso… beh… un po’ di Design Thinking può esserci di aiuto per la fase di Inception e per tirare giù nuove idee e Lean StartUp per validarle velocemente rispetto ai potenziali clienti… ma di questo parleremo prossimamente.

Stay tuned J

La metafora del Mappazzone

Ebbene lo ammetto! Spesso mi diverto a guardare la nota trasmissione televisiva masterchef, non tanto per la gara in sé (a malapena so cucinare un piatto di pasta con il sugo pronto), ma per la capacità dei giudici di creare un’atmosfera che coniuga il momento gioviali all’interno di attività che richiedono forte concentrazione, preparazione e precisione.

In realtà, in masterchef troviamo molti elementi comuni del mondo Agile: timeboxed, capacità di adattamento (es: mistery box), l’importanza fondamentale di lavorare in team (brigate), l’obiettivo ultimo di soddisfare sempre l’utente (i giudici).

Potremmo, probabilmente, immaginare addirittura qualcosa di simile ad un’Agile Masterchef workshop.. e non è detto che prima o poi non lo faremo J

Quello su cui però voglio soffermarmi è un termine, preso in prestito proprio dalla trasmissione in oggetto, che mi è capitato spesso di utilizzare ultimamente nell’azione di coaching, soprattutto quando affrontiamo questioni tecniche inerenti al design applicativo: il mappazzone!

Il termine è usato dallo chef Bruno Barbieri e, come lui lo usa per descrivere un piatto che non ha anima, ma che è semplicemente l’insieme caotico di ingredienti mischiati alla meglio, così lo si può utilizzare per descrivere un cattivo design applicativo.

barbieri mappazzone

Ma cos’è un cattivo design applicativo? E ci mancherebbe altro che, da Coach, non rispondessi “dipende” J, anche se abbiamo a disposizione diverse linee guida: dai principi SOLID, a GRASP e quindi ai Design Pattern e ai concetti di Separation of Concern.

Per scoprire se quanto stiamo realizzando si sta trasformando in un mappazzone, suggerisco spesso ai team di sfruttare approcci come TDD o, se preferiscono qualcosa di meno stringente, Test First Programming, e farsi una semplice domanda: il codice è facile da testare? Riesco a creare uno o più test che mi verificano quanto realizzato in chiave end-to-end?

Ecco, se la risposta a queste domande è tendenzialmente no, stiamo creando un mappazzone!

È sempre interessante riuscire a parlare con i team in modo diretto, trovando formule di uso comune che, con semplicità, apra una riflessione e porti a delle azioni di miglioramento… a mio avviso, un bravo coach si riconosce spesso dalla capacità di sintesi, ovvero di riuscire a esprimere in con poche parole o metafore, concetti complessi, portando il team a farsi delle domande e cercare delle risposte… un po’ alla Lubrano.

Stay tuned J

La dissonanza delle sfere di azioni del valore

Nel precedente post abbiamo parlato del Fattore Canguro, ovvero del fatto che lo Scrum Master è spesso costretto a saltare da un’attività all’altra non potendo garantire l’impegno totale sul proprio ruolo, troppo spesso “non capito”.

Ma anche il Product Owner non vive sempre (o spesso, decidete voi J) momenti felici.

po

Questa cosa può decisamente stupire, visto che il ruolo del PO è ormai universalmente riconosciuto nel mondo agile, indipendentemente dal framework o dalla metodologia che si decide di utilizzare

Troppo spesso, però, il PO viene inquadrato al pari del Product Manager, o ancora peggio del Project Manager, ovvero il garante dei “tempi”: la sua attività primaria diventa quella di riportare al management di livello superiore l’andamento delle attività e preoccuparsi di “assegnare” le cose da fare. Se poi si utilizza un tool per la gestione digitale delle Storie, diventa colui che scrive le storie nel tool…

In tal modo si spoglia il PO della sua attività chiave che, come sappiamo, è quella di mantenere costante il focus sul Valore, supportando il proprio team e l’organizzazione nell’adattamento costante in relazione alle attese degli stakeholder e in funzione del contesto corrente.

po role

Una cosa ben diversa dal “dover guidare” il team nelle proprie decisioni, soprattutto se di carattere prettamente tecnico, appartenendo quest’ultime primariamente alla sfera di azione del team di sviluppo, con l’eventuale supporto di specialist e team esterni.

Ma allora, come rispondiamo a domande come:

  • Ma il PO stima le storie?
  • Il PO può dare suggerimenti tecnici?
  • Il PO può dire di “no” al management?
  • ….

Sono tutte domande che non hanno una risposta assoluta (se si esclude ovviamente quanto specificamente previsto dalla letteratura) ma dipendono, banalmente, dal contesto operativo di riferimento. Prendiamo la prima: se l’intero team ritiene che la stima del Product Owner abbia un “valore” per la Storia specifica, nonostante valga sempre la regola “stima chi fa il lavoro”, non c’è nessuna legge divina che impedisce al PO di effettuare la stima, dotandosi, ad esempio, di un planning poker deck esattamente come tutti gli altri. Non è una scelta che mi piace consigliare e adottare, ma in alcuni contesti può effettivamente aver senso.

Restano però imprescindibili i doveri del PO di accertarsi che quanto si stia realizzando ha un effettivo valore (per il committente così come per il service provider), così come è suo diritto/dovere apportare tutte le modifiche che ritiene opportuno al Product Backlog, possibilmente sempre in maniera collaborativa.

Chiudiamo sottolineando che nche per il PO valgono le stesse identiche considerazioni fatte per lo Scrum Master rispetto alla distinzione “ruolo/posizione”: bisogna avere un ingaggio a tempo pieno sul ruolo per consentire alla Persona di coprirne i diversi aspetti e poter migliorare costantemente nelle proprie attività.

Stay tuned J

Kangaroo Factor: il Fattore Canguro nell’agilità del dualismo Ruolo e Posizione

Se vi siete imbarcati nella lunga strada che porta all’Agilità, e avete deciso di adottare uno dei framework più comuni (Scrum, DA, SAFe, ecc…), vi sarete sicuramente scontrati con un problema estremamente comune in tale scenario: il cambiamento e l’associazione dei Ruoli.

Per evidenziare il concetto, prendiamo come riferimento Scrum che, come ben sapete, prevede tre ruoli fondamentali: Scrum Master, Product Owner e Developers.

scurm roles

Scrum Roles

Quello su cui tipicamente ci sono le maggiori difficoltà, sia da un punto di vista aziendale dell’inquadramento sia nel riconoscerne l’ambito in modo da lasciarlo operare attivamente e full-time rispetto a propri compiti, è il ruolo dello Scrum Master.

Molto spesso non si intende il ruolo dello Scrum Master come un “ruolo”, ma come una “posizione” che viene assegnata al più bravo degli sviluppatori, come se fare lo SM desse potere e rappresentasse una scalata nella gerarchia organizzativa. Si può facilmente intuire come questo porti ad innumerevoli rischi, mettendo in crisi l’adozione del framework selezionato (e prima ancora il percorso di trasformazione Agile) a causa di una serie di disfunzioni primarie:

  • Tipicamente “il più bravo tecnicamente” non è detto che abbia i soft skill (caratteriali) e gli hard skill (know-how agile) necessari… anzi!
  • Se anche le condizioni del punto precedente fossero verificate in positivo, il “più bravo tecnicamente” è tipicamente preso, per la maggior parte del suo tempo, dalle attività di sviluppo e nel relativo supporto ai propri colleghi, occupandosi dell’Agilità nei tempi morti… praticamente mai!

Possiamo sintetizzare il discorso, evidenziando come la disfunzione di avere un ruolo di Scrum Master non ricoperto da una persona dedicata in modo esclusivo (o praticamente esclusivo) attivi il Fattore Canguro (Kangaroo Factor), costringendo la stessa a “saltellare” tra più attività con il risultato di perdere costantemente concentrazione ed eleggere sempre e comunque un ambito di focus primario: tipicamente quello tecnico. In tal modo l’azione di coaching e supporto costante in chiave Servant Leader dello Scrum Master è solo un miraggio, un bell’intento scritto in letteratura.

kangaroo

Fattore Canguro (Kangaroo Factor)

Per essere pragmatici, è comunque doveroso evidenziare come l’associazione del ruolo di SM al technical leader ha dalla sua almeno un vantaggio, ovvero il fatto che gli altri membri del dev team sono generalmente portati ad ascoltarlo, vedendo in lui una figura di riferimento rispetto alle proprie attività.

Il consiglio, in linea con quanto suggerito da DAD (in cui il technical leader è definito Architecture Owner, mentre lo SM assume il nome di Team Lead), è quello di optare per questa scelta solo se il team è di piccole dimensioni, non è necessario confrontarsi con gli aspetti di scaling e anche il progetto è relativamente piccolo.

In tutti gli altri casi, ma direi in generale, evitiamo tale scelta e poniamoci come obiettivo quello di eliminare l’effetto canguro non solo per il ruolo dello Scrum Master, ma per tutte le figure della nostra organizzazione: meglio uno Scrum Master che segue due team (se il problema è economico/giustificativo) che uno Scrum Master allo 0,00001%!

Stay tuned J

La perfezione alchemica del numero 7 che porta alla disciplina

Disciplined Agile (Delivery) è un framework di cui parlo spesso, sia perché apprezzo l’approccio estremamente pragmatico all’Enterprise Agility, sia perché mi risulta molto utile per parlare ai diversi livelli organizzativi di elementi e “fasi” che possono paragonare all’organizzazione in essere.

Nel corso dell’ultimo anno, il DA Consortium ha fatto un importante lavoro per rendere consistente il passaggio da Disciplined Agile Delivery (lifecycle) a Disciplined Agile che si occupa dell’intera organizzazione.

In particolare, come da tradizione del mondo Agile e Lean, partire dai Principi è un approccio consolidato che consente di chiarire la linfa essenziale che contraddistingue il framework o la metodologia specifica. DA definisce 7 Principi essenziali, incarnazione della perfezione alchemica, rappresentati in una struttura a nido d’ape:

da values

Alcuni sono in diretta relazione con quando presentato da Modern Agile ed Heart of Agile, di cui abbiamo già discusso nei nostri approfondimenti.

Vediamo di dare più corpo a tali principi:

  • Delight Customer (meravigliare il cliente), questo principio affonda le proprie radici nel primo principio Agile “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, declinandolo in un’ottica maggiormente Lean Oriented con la consapevolezza che per fidelizzare i clienti bisogna fornirgli quel quid in più, andando a sorprenderli oltre le proprie aspettative;
  • Be Awesome (essere incredibili), il nostro successo aziendale dipende dalla capacità di aiutare le persone ad essere vincenti e renderli in grado di risolvere problematiche grazie alle proprie capacità. Come affermato da Richard Branson: “Take care of your employees and they’ll take care of your business”;
  • Pragmatism (pragmatismo), le persone devono confrontarsi continuamente con situazione che sono tutt’altro che ottimali. Diventa, quindi, indispensabile trovare la propria “Agile way”, accettando il fatto che sia necessario individuare il giusto equilibrio ed il giusto compromesso rispetto ad un possibile approccio ideale;
  • Context Counts (tener conto del contesto), contesti diversi richiedono strategie diverse. Questo comporta che, qualunque sia la pratica o il processo scelto, è necessario ricamarlo nel contesto specifico, andando a creare una cultura orientata al Continuous Learning ed Experimentation;
  • Choice is Good (poter scegliere è sempre positivo), ogni persona, ogni team ed ogni organizzazioni è unica. I team devono poter gestire e plasmare i processi, sperimentando cosa funziona realmente nel proprio ambiente, micro e macro;
  • Optimize Flow (ottimizzare il flusso complessivo), un’organizzazione è un Sistema Adattativo Complesso (CAS) composto da team che interagiscono tra loro e che evolvono costantemente influenzandosi a vicenda. La sfida è quella di trovare il giusto equilibrio e il ritmo che consenta di ottimizzare il flusso complessivo delle attività;
  • Enterprise Awarness (essere parte integrata dall’azienda), tutte le persone appartengono ad un unico ecosistema: l’azienda. I team possono trarre vantaggio da quanto fatto dagli altri, contribuendo al valore complessivo di quanto realizzato.

Tutti questi principi guidano l’Agilità all’interno di una visione olistica della sua adozione, creando le basi per l’approccio Goal-Driven caratteristico di DA.

Stay tuned J

Attenzione a non farvi distrarre dalla Big “A” dell’Agile

Il raggiungimento dello status quo è uno dei grandi rischi del mondo Agile.

Pensare di aver completato il proprio cammino è sintomo stesso che c’è ancora tanto lavoro da fare perché, probabilmente, non abbiamo capito in profondità il senso stesso dell’Agilità. Non dovremmo mai affermare “sono diventato Agile”, ma piuttosto “siamo continuamente al lavoro per far si che la nostra azienda sia in grado di rispondere sempre al meglio alle sfide di contesto”.

D’altronde una delle pratiche prese in prestito da Lean, ovvero il Kaizen, ci porta proprio a dire che bisogna migliorare continuamente a piccoli passi, in modo da limitare e gestire gli impatti senza per questo rinunciare a evolversi giorno per giorno. Stesso discorso per il dodicesimo principio.

kaizen

Ecco, in tal modo l’Agilità diventa un meccanismo implicito, uno strumento al servizio dell’obiettivo primario, e non l’obiettivo stesso.  È un aspetto fondamentale, ma che spesso sfugge, rendendo di fatto vano il percorso di rinnovamento e rischiando di sostituire il processo in essere con qualcosa che ha una maggiore tendenza, ma svuotato dell’essenza.

Se spalmassimo una trasformazione Agile sul quadrante di un cronometro, dopo aver raggiunto i primi risultati apprezzabili è come se la lancetta dei secondi fosse sulla prima unità aggregativa (tipicamente il 5) e, osservandolo, capiremmo quanto c’è ancora da fare. Ma la stessa metafora è utile anche per ricordarci che il tempo scorre velocemente e che rischiamo di restare indietro, se quanto stiamo facendo non è contestualizzato al dominio in cui ci muoviamo.

5chrono

Identificare un percorso di azione è fondamentale per consentire di avere sempre chiari almeno due obiettivi: quelli a breve e quelli a medio termine. In tal modo si evita di andare a naso e si riesce a comunicare ai diversi livelli interessati quelle che sono i “touch point” da attraversare per proiettarci e prepararci ai “momenti di verità”.

Troppo spesso si corre appresso alla “big A” di Agile, ovvero appresso alla brandizzazione di un approccio, una tecnica, un tool, che danno la falsa sensazione di essere al sicuro e di poter essere certi che il percorso intrapreso porti a risultati certi. Una sola sentenza: statene alla larga! Concentratevi su quando porta reale utilità e su quanto riesce a portare sul carro quanti più viaggiatori possibili.

Ovviamente, nessun dubbio che l’Agilità sia un’arma potentissima, ma come tale va maneggiata con cura per evitare che diventi un’occasione perduta e che non si riesca ad attuare i miglioramenti che ci si aspetta.

Stay tuned J

L’Incognita costellazione sottesa dalla “i” di Agile

La storia potrebbe cominciare così: una nuova organizzazione ci chiama, ci racconta come percepisce sé stessa, dicendoci dove vorrebbe migliorarsi, e ci chiede di supportarla.

Qui parte la “sfida previsionale”, dell’organizzazione e di noi stessi, sfida che deve accettare di buon grado il fatto di non potersi sottrarre alle regole implicite del Cono di Incertezza (Cone of Uncertainty), tanto decantate ed utilizzate quando si parla di Stime e Pianificazioni Agili.

cone of uncertainty

Cone of Uncertainty

Il Cono di Incertezza è uno strumento fondamentale, “portato” nel mondo del software da Barry Boehm come “Funnel Curve” e basato su una serie di lavori che hanno origine nell’ambito di uno studio sul Risk management nell’ingegneria chimica promosso dall’American Association of Cost Engineers alla fine degli anni ’50 del secolo scorso.

Il nome Cone of Uncertainity viene coniato da Steve McConnel, dopo che il lavoro di Boehm è stato raffinato, tra gli altri, dalla US Air Force e dalla NASA.

La potenza di questo strumento si trova nell’essenza stessa dello sviluppo dei sistemi appartenenti alla sfera del “Complesso” e dall’accettazione che le conoscenze relative aumentano in relazione al grado di avanzamento stesso del progetto: è praticamente impossibile, dati gli strumenti e gli approcci attuali, conoscere in anticipo con certezza quanto impiegheremo per la realizzazione di un progetto software.

Ogni progetto è unico, nella sua realizzazione, e si fonda sul lavoro di Persone, che sono uniche a loro volta ed evolvono costantemente.

Quindi, tornando ad un’azione di trasformazione: come possiamo dare un tempo certo per raggiungere il risultato, se l’ecosistema a cui ci riferiamo è costellato da una serie così ampia di incognite? La risposta è semplice: non possiamo!

multiple time

Quello che è possibile fare è sfruttare anche per le azioni di trasformazione i principi fondanti del Cono di Incertezza e considerare le stesse come un progetto (o meglio un programma) in cui si identificano degli obiettivi progressivi che consentono di attuare due aspetti primari:

  • Innestare nel contesto elementi di trasformazione e crescita progressiva, in modo da sviluppare il percorso di cambiamento;
  • Aumentare costantemente il nostro know-how di contesto, valutando i feedback ed i segnali che arrivano direttamente e indirettamente da quanto approcciato e dalle persone coinvolte.

In tal modo è evidente come un’azione di trasformazione debba realizzarsi a step progressivi, individuando finestre temporali (chiamatele Sprint o Iteration se preferite J) sufficientemente ampie da poter rendere significativa l’azione specifica, ma al contempo sufficientemente strette da poter intervenire rapidamente per correggere il tiro.

Al termine di ogni finestra temporale, è fondamentale validare quanto raggiunto, riflettere sugli step successivi e, di conseguenza, capire come allocare sufficienti risorse per raggiungere i nuovi obiettivi: approccio Lean Startup docet!

E qui si lega anche la classica domanda: ma come contrattualizzare il tutto?

La tematica è molto ampia, ma, in generale, valgono le stesse considerazioni e la maggior parte degli approcci che vanno sotto il cappello di “Contratti Agili”, dai più tradizionali Fixed-Price Contracts ai Cost-Plus Contracts.

Un approccio progressivo e legato alle evidenze, è un approccio che, nella mia esperienza, piace molto alle aziende, sentendosi “coccolate” e contando su un’azione “ricamata” sulle loro necessità e progressivamente rivista in funzione dei risultati ottenuti, piuttosto che essere vincolati ad un Piano realizzato up-front e poi preso a riferimento di tutte le scadenze a discapito del Valore prodotto…. waterfall memento!

Stay tuned J

La finta illusione dell’escapologia organizzativa indotta nella “e” di Agile

Avviare una trasformazione profonda come quella che porta un’azienda a scoprire la propria Agilità, diventando un’organizzazione in grado di adattarsi continuamente ai cambiamenti, richiede un Programma di forte intensità che incide sull’essenza stessa dell’“io organizzativo”.

Non di rado capita che si decida di “testare con mano” gli effetti del cambiamento, creando l’arcinoto Progetto Pilotta. Se a molti sembra un passaggio ovvio e dovuto, bisogna evidenziare che il successo di un progetto pilota non implica automaticamente il successo nell’adozione sistemica di quanto sperimentato, anzi!

pilot project

Il problema è che spesso si cade nella trappola di “proteggere” tale progetto, creando un ambiente specifico dissociato da quello reale, non soggetto proprio alle dinamiche che invece si vorrebbero risolvere con il cambiamento ipotizzato. Si tratta di una vera e propria azione di escapologia organizzativa, ovvero la capacità di isolarsi dal contesto specifico, creando le condizioni ideali che ci portano ad un successo apparente, ma non replicabile in quello reale.

Partendo da questa premessa, diamo un sguardo ai fattori primari di cui dovremmo tener conto affinché un progetto pilota sia realmente significativo:

  • Contesto. In un progetto pilota tutti ne conoscono la natura e i diretti interessati, e sentendosi “osservati” possono comportarsi come atteso piuttosto che come farebbero normalmente, falsando completamente il risultato;
  • As-Is. L’outcome del progetto dovrà confrontarsi con i processi esistenti ed abbattere la tipica resistenza al cambiamento prima di poter essere assorbito come sistemico. Bisogna sempre tenere in considerazione, inoltre, che quanto valido a livello locale potrebbe non funzionare a livello globale;
  • Risorse. Tipicamente sono sufficienti solo per il progetto stesso e l’estensione dei risultati richiede un programma di investimento specifico;
  • Coinvolgimento. Chi resta fuori dal progetto pilota può sentirsi escluso e fare quanto in suo potere, in modo più o meno esplicito, per affossare il tutto;
  • Tempo. Non esiste una diretta correlazione tra il tempo impiegato per il progetto pilota e il tempo che sarà necessario per rendere i risultati organici a tutta l’azienda;
  • Coraggio. Bisogna avere persone “illuminate” che non temono il cambiamento e non si arenano sul “… tanto qui non cambia mai nulla!”.

Questi fattori, non esclusivi, sono sempre presenti e ci portano a riflettere su quanto possiamo fare per porci almeno nelle condizioni di avere un progetto pilota che possa avere successo. L’obiettivo è che tale progetto deve rappresentare un valore concreto per la nostra organizzazione, andando a toccare almeno i seguenti elementi chiave:

  • Massimizzare gli elementi positivi. Bisogna sempre selezionare i progetti più promettenti che consento di validare rapidamente i risultati, senza costi e rischi eccessivi;
  • È fondamentale individuare Persone energiche ed entusiaste, tipicamente prone all’innovazione e al cambiamento. Inoltre, si deve avere a bordo uno sponsor aziendale di alto livello che senta propria l’iniziativa, aiutando a trovare le risorse necessarie;
  • Benefici di business. Il progetto pilota dovrà evidenziare chiaramente i benefici aziendali ai diversi livelli, dimostrando come il relativo saldo con gli investimenti sia positivo. I vantaggi ottenuti devono sempre riguardare sia le singole Persone che il contesto organizzativo complessivo;
  • Oltre il perimetro. Al progetto vanno associati un ambito preciso e obiettivi ragionevoli, evitando di “volare alla cieca” e dando un senso alle diverse azioni di pivot che generalmente lo accompagnano. Resta comunque fondamentale che il tutto sia “estendibile” al contesto complessivo e che non abbia senso solo nello specifico;
  • Apprendimento. Il progetto pilota non ha successo se produce qualcosa (o almeno non solo): si ha successo se chi lo attua e l’organizzazione tutta è in grado di imparare da esso, anche in caso di fallimento. Ricordate: “fail often, fail fast”;
  • Training e Coaching. Nessun progetto pilota può avere successo se non è accompagnato da opportune azioni di training e coaching. Il tutto è tanto più evidente e rilevante quanto più l’innovazione introdotta è dirompente;
  • Visibilità. Rendere il progetto visibile anche a chi non è direttamente coinvolto è fondamentale per cominciare a disseminarne i risultati e rimuovere la presunzione di “proprietà” che, tipicamente, chi non è coinvolto tende ad associare al Team pilota.

Infine, ricordate sempre che se il progetto pilota non ha più senso di continuare, allora è meglio interromperlo subito, rivolgendo la nostra attenzione a qualcosa di più utile per la nostra organizzazione.

Stay tuned J