Author Archives: Felice Pescatore

Don’t dirty my Backlog: flow/no-flow

Si è cominciato a parlare (si veda qui) dell’importanza di preservare la consistenza del proprio Product Backlog, facendo si che esso rispecchi le effettive esigenze di prodotto onde evitare che diventi un “accumulo” di decine e decine di richieste che poi si perdono al suo interno.

Il Basket, proposto come contenitore di “draft item”, è al centro di una precisa strategia:

  • Vengono raccolte le informazioni da ogni fonte disponibile e meritevole di attenzione
  • Viene eseguito il refinement delle informazioni per ottenere degli Item consistenti
  • Vengono spostati gli item nel Product Backlog

3phases

 

La raccolta delle informazionida parte dei diversi stakeholder è un’attività continua che trova nel Product Owner il riferimento operativo e che si può realizzare sfruttando gli strumenti più disparati: dalla comunicazione diretta a soluzioni di change request management

La cosa fondamentale è la capacità di aggregarele richieste guardando oltre la specifica singolarità, in modo da creare featureche portino ad un mutuo beneficio tra le parti, sottoponendole continuamente ad un refinement che consenta di ottenere item lavorabiliche non siano dei banali placeholder. 

Qui nasce la necessità di definire con chiarezza che cosa significhi “item lavorabili”, per il contesto specifico, per l’iniziativa e per il team, stabilendo una specifica Definiton of Ready(DoR) per abilitare il flow/no-flowfunnel che porta un Basket Item ad essere promosso a Product Backlog Item.

flow noflow

Come sempre bisogna fare molta attenzione alla DoR: una sua specifica troppo estremapuò portare ad allungare in modo irragionevole i tempi, perdendo di vista l’importanza applicativa del Cono di Incertezzae provando a rendere “perfetto” qualcosa che “by definition” non può esserlo nei sistemi complessi. Dualmente, una DoR troppo superficialeporta ad avere item che sono tutt’altro che pronti ad entrare nel Product Backlog e che porterebbero solo ad “aumentarne il peso” senza dare un contributo apprezzabile al valore complessivo.

Quando un Basket Item soddisfa la DoR e viene promossoin un Product Backlog Item, entra di diritto nella “lista delle cose da fare”, anche se questo, come è ben noto, non da certezza che verrà realizzato, ma solo che è “meritevole” dell’attenzione dell’intero team. 

Guai a pensarla diversamente: si ricadrebbe nel “tranello” di effettuare una elicitazione completa dei requisiti, perdendo la capacità di operare dinamicamente rispetto ai cambiamenti e di adattarsi alle evidenze piuttosto che seguire un piano.

Stay tuned J

Don’t dirty my Backlog!

Che il Product Backlog sia uno degli elementi cardini per il lavoro dei team Agile è una verità sperimentata da tutti i team che hanno intrapreso un percorso di “Agilità” scegliendo di partire da un riferimento simil-Scrum. Accettando la verità assodata che i “requisiti sono imperfetti by design”, il Product Backlog risponde alla necessità di avere uno strumento più flessibile del tradizionale SRS (System Requirements Specification, o comunque lo chiamate) per gestirli.

Se a prima vista la gestione di un elenco di attività (Storie se preferite J) non sembra un lavoro particolarmente complicato ed oneroso, entrando nel vivo della questione viene fuori, invece, che un Backlog “pulito e parlante” è tutt’altro che facile da creare, manutenere ed evolvere.

Non di rado ci si imbatte in Backlog costituiti esclusivamente da dei “placeholder”, come ad esempio: “fare la login”, senza alcuna altra informazione di dettaglio, a partire dai tanto bistrattati Criteri di Accettazione. Proprio questa situazione da il là ad uno degli aspetti primari che possono vanificare il senso stesso del Backlog: avere al suo interno decine e decine di elementi, inseriti preventivamente stile “waterfall”, che rendono praticamente incomprensibile il Valore che dovrebbe essere espresso dal loro insieme.

salad

In pratica, si prende la cattiva abitudine di buttare ogni richiesta, ogni specifica se si vuole, che arriva, direttamente nel Backlog, assegnandogli ogni volta la priorità più alta senza minimamente preoccuparsi di effettuare un opportuno refinementdell’elemento ne tantomeno degli impatti che avrà sul Valore per il cliente e sulle attività in essere.

Un possibile approccio per limitare tale mescolamentoè quello di creare un Basket in cui raccogliere le richieste provenienti dai diversi stakeholder, e, solo successivamente, procedere alla creazione di un elemento da inserire nel Product Backlog che rappresenti l’item lavorato o, eventualmente, la sintesi delle diverse richieste che incidono su un elemento o un’area specifica.

basket

L’idea è quella di creare un’area flessibile in cui raccogliere tutte le informazioni necessarie a soddisfare una Definition of Readyminimale che evidenzia il livello minimo di dettaglio previsto per poter promuovere effettivamente un’attività da Basket Item Product Backlog Item.

Per quanto possa sembrare inizialmente un’attività che va ad “affaticare” le incombenze tipiche del Product Owner, inserendo di fatto un pre-step nella creazione del Product Backlog, una volta assorbita e adattata al contesto, diventa decisamente funzionale e centrale per avere un cosiddetto Healthy Product Backlog.

Si evita, infatti, di trasformare il Backlog in un “repository” di richieste, allungandolo oltre ogni ragionevole dimensione, solo perché non si sa dove mettere le cose. Inoltre, introducendo il concetto di Aging, ovvero di invecchiamento di una attività, si può evitare di avere Zombie Itemche restano nel Backlog anche per molte iterazioni senza alla fine riuscire mai a trovare spazio di realizzazione concreta.

Torneremo presto a parlare del Basket con alcune idee per gestire la prioritizzazione degli elementi e la personalizzazione di tool per poterne creare una versione digitale.

Stay tuned J

L’inconfutabile momento del “come”

Durante l’evento DevOps Heroes 2018, abbiamo avuto modo di riflettere su DevOpse di come esso sia un volano per la competitività aziendale, partendo dall’assunto che:

            “ogni azienda è un’azienda software, indipendentemente dal settore diapplicazione”

Molti gli spunti di riflessione, tecnici/tecnologici e metodologici.
In particolare voglio sottolineare una pillola emersa durante la round table “Il grande fallimento di DevOps” (titolo chiaramente provocatorio), riguardo al cosiddetto DevOps Engineer

Personalmente sono stato sempre estremamente contrario ad utilizzare questo titolo, o altri similari, all’interno di un’organizzazione che si incammina nel percorso di trasformazione DevOps. Ho ascoltato con attenzione, però, il parere di Scott Ambler(opsite dell’evento) che ha suggerito un approccio più morbido rispetto a questo tema: secondo Ambler, può aver senso avere questo ruolo all’interno dell’organizzazione, purché sia un ruolo temporaneo, ovvero una sorta di “specialist” che supporta i team (e gli operations in particolare, visto che viene generalmente associato a loro) nell’apprendimento delle pratiche di automazione della pipeline di rilascio.

today devops engineer

Si tratta, in sintesi di un Coach tecnicoche, come tale, ha primariamente lo scopo di supportare la crescita tecnicae consentire rapidamente al team di muoversi in autonomia.

In pratica, è il ruolo del Coach ad evolvere ulteriormente, arricchendosi di nuove capacità specialistiche, e, probabilmente, evidenziando ulteriormente come l’idea che sia sufficiente un solo Coach per una trasformazione DevOps sia fortemente limitativa, perché difficilmente è possibile abbracciare i vari aspetti ormai richiesti.

Esiste a questo punto anche un ulteriore aspetto rilevante: la maggiore centralità chel’HR(o People Management) continua ad acquisire. Se dobbiamo portare a bordo nuove persone, l’HR dispone degli strumenti necessari per individuare e scegliere i nuovi profili? Ha la capacità di guardare avanti, settando nuovi percorsi di crescita per le Persone che lavorano nella propria organizzazione? È in grado di comunicare adeguatamente i Valori dell’organizzazione in modo da renderla attrattiva agli occhi dei potenziali candidati?

agile hr

Tutti aspetti che oggi sono sotto la lente di ingrandimento, tanto che nei vari percorsi di trasformazione l’HR è sempre più presente e costantemente ingaggiato. E altre aree organizzative sono alle porte: sales, marketing, PMO, architecture, ecc.

Segno definitivo che non è più tempo di chiedersi “se”avviare una trasformazione Agile (o DevOps se volete), ma l’unica domanda che conta è“come” iniziare il percorso di rinnovamento

 

Stay tuned J

La difficile equazione dell’introspezione adattiva

Quando penso e parlo di DevOps, il mio focus è sempre rivolto al valore nobile della Continuous Delivery: produrre costantemente (e non velocemente!) valore per gli stakeholder, interni o esterni che siano.

Si tratta di temi fondamentali, in funzione della verità assodata che oggi ogni azienda è una software house, ovvero che nessuna organizzazione può fare a meno di un nucleo IT che sviluppa soluzioni abilitanti per il business.

Durante i vari workshop e le azioni di coaching, prima o poi, salta sempre fuori una domanda: “Ma queste cose a loro [ai Manager] verranno dette?” “Faranno anche loro [i Manager] lo stesso corso?

Sembra quasi che i Dev e gli Ops farebbero tutto (poi “tutto” bisogna capire cosa sia) domattina, ma il loro freno sono sempre i responsabili che non vogliono ragionare e investire sulla trasformazione Culturale che io dico, affermo e riaffermo, essere indispensabile. Se non lo si fa, si condanna l’azienda ad una sopravvivenza forzata e non la si mette nella condizione di innovare e guardare ai nuovi traguardi

Poi, però, quando cominciamo a soffermarci sul ruolo che Dev e Ops devono avere in tutto ciò, le facce cambiano espressione: 

Non dovete più ritenervi coder, ma professionisti in grado di usare tecniche e tecnologie innovative per innovare il Business”.

Molte volte si stenta a capire l’importanza di questa frase, perché significa, in soldoni, assumersi responsabilità guardare oltre il proprio monitor.

Eppure, la realtà è così! 

Non esiste il “DevOps Engineer” (si tratta di un Sistemista che sa usare i tool di automazione per il deploy… chiamiamo le cose con il loro nome per favore), ma esiste una organizzazione che abbraccia DevOps (Lean, Agile, quello che preferite) avendo come obiettivo l’Enterprise Agility, ovvero essere in grado di rispondere prontamente al mercato, guardando al proprio interno, ma al contempo contribuendo a formarlo.

Non si tratta più di trovare il programmatore più bravo nello scrivere codice, si tratta di trovare il professionista che sa dove mettere le mani, ma che è in grado di supportare un cambiamento continuo in relazione alle nuove sfide che si presentano.

nerd vs thinker

Bisogna tornare a PENSARE!

I manager non sono persone generalmente “ottuse” e capiscono bene il valore dei diversi elementi di cui discutiamo, solo che anche loro sono trascinati nell’operatività giornaliera e spesso hanno difficoltà a fare quello che dovrebbe essere il loro obiettivo primario: mettere in atto quanto necessario per le prossime sfide, non quelle attuali, perché se siamo in quest’ultimo caso… è già tardi!

In pratica dobbiamo allontanarci dall’idea di essere “macchine banali” e riappropriarci del nostro essere “macchine non banali”, ovvero un giacimento di risorse inesauribili.

Ricordate sempre: il vero valore è nelle Persone e non nel codice scritto!

Stay tuned J

La rilevanza del Piano B

Si è appena chiusa l’edizione 2018 del Coach Camp Italy

Due giornate condite da spunti, riflessioni e discussioni legate alla tematica del Coaching Agile, nel panorama magnifico di Garda e del suo lago. Una grande agorà in cui è stato possibile confrontarsi con gli esperti italiani e non solo (forte la presenza degli omologhi tedeschi).

In particolare, durante la sessione “Resident Coach, Consultant Coach… DOs and DON’Ts”, si è discusso delle azioni che ci si aspetta da un Coach, soffermandosi in modo specifico sulla domanda: “ma un Coach esterno è un Consulente nella tradizionale accezione dell’esperto che deve fornire risposte?”

acci 2018 1

La questione può sembrare solo “filosofica”, eppure ha generato un’ampia riflessione, sintetizzata dall’ottimo Alessandro Giardinache ha evidenziato come, alla fine, i partecipanti abbiano concordato sul fatto che le azioni di un Coach non dovrebbero dipendere dal suo status di dipendente/consulente. Questo perché le attività sono sostanzialmente le stesse: dalla capacità di guida, a quella di supporto e sprono alla trasformazione. Il bandolo della matassa si è sciolto quando è emerso come il problema, in realtà, sia nell’idea che l’agile Coach è un “consulente esperto di Agile” e non un Coach in senso lato che, per definizione, è qualcuno che aiuta gli altri negli specifici ambiti sfruttando le proprie attitudini e conoscenze.

La discussione si è poi estesa, virtualmente, nel pomeriggio con il panel “Be a Coach” in cui ci si è soffermati sulle pressioni che un Coach “interno” può subire quando è rigidamente inquadrato nell’organigramma, cosa che potrebbe pregiudicarne la libertà d’azione in funzione delle dinamiche di management e di “capi” poco inclini agli aspetti tanto cari al mondo Agile (self-organizing team, continuous improvement, fail fast/fail often, ecc).

acci 2018 2

Quanto emerso è che il Coach deve essere capace di creare una forte Empatia con il contesto interessato, e conquistare la necessaria Fiducia per avere un ruolo di leadership nel percorso di trasformazione e rinnovamento.

Molto interessante l’idea del “Plan B”: avere un piano di riserva se non si è messi nelle condizioni di operare in modo indipendente nel proprio ambito professionale. Bisogna sempre essere alla ricerca del proprio State of Flow.

 

Chiudo ringraziando gli organizzatori del Coach Camp Italy 2018 e tutti i professionisti che hanno reso le giornate fruttifere e di indubbio valore.

Stay tuned J

Spazio… ultima frontiera…

Persone e Interazioni più che Processi e Tool”, il primo Valore è il punto di partenza di qualsiasi cambiamento che si ispiri all’Agile, Lean e DevOps, e sottende esplicitamente la necessità del cambiamento Culturale come aspetto portante.

Spesso però c’è un elemento che viene dimenticato o sottovalutato, ma che rappresenta un aspetto portante se si vuole promuovere la cultura Team basedalla base stessa dell’agilità: lo spazio fisico di lavoro.

Se ci si riflette per un momento, si riesce subito a capire come spazi adeguatisono essenziali per tutta una serie di motivi: dalla comunicazione diretta(come suggerito dai Principi), alla possibilità di avere i necessari Information Radiator, come la classica Kanban/Scrum Baord, che accompagnano il team nella visualizzazione e gestione dell’avanzamento delle attività.

Ogni team dovrebbe avere la propria area sufficientemente aperta, per comunicare trasparenza e disponibilità verso gli altri, e chiusa quanto basta, per garantire una condizione di privacy e generare il senso di appartenenzaal team.

In pratica, solo varcando la sogliadel working space del team possiamo conoscerlo realmente senza però trasformarci in ospiti indesiderati che vanno ad alterarne le dinamiche naturali.

L’importanza degli spazi è ben evidente in Lean, dove la tecnica/tool delle 5S (Seri, Seiton, Seiso, Seiketsu, Shitsuke) è tra quelle primarie, evidenziando come un’area di lavoro ordinata sia abilitante per poter lavorare in modo efficace ed efficiente. 

poster 5s leanproducts

In questo caso, però, la postazione è più intesa come scrivania personale di lavoro che come area del team. La connotazione più “Agile” è, invece, ben esplicitata in Disciplined Agile, rappresentando uno dei Goal della fase di Inceptiondi DAD: Form Work Environment.

dad goal form work environment

L’attenzione, però, non si limita ai soli ambienti fisici, ma si estende anche alla selezione dei tool e la creazione degli ambienti digitali di lavoro, aspetto fondamentale per introdurre un approccio che guarda a DevOps sin dall’inizio, andando ad abbracciarne le principali pratiche abilitanti come la Continuous Integration e Continuous Deploy o la creazione automatizzata di ambienti consistenti per il testing.

Interessante anche il concetto di “Tailor initial process”, recentemente aggiunto, che nella creazione degli ambienti tiene conto dello specifico lifecycle adottato e della relativa incidenza sul resto (principio “Choice is Good”) 

Tornando agli ambienti fisici, è fondamentale affidarsi ad esperti che vadano a studiare effettive soluzioni di riorganizzazione, tenendo anche conto di vincoli come, ad esempio, la sicurezza delle persone e gli spazi minimi individuali previsti per legge. Fondamentale è ricordarsi di creare, oltre alle aree dedicate ai team, le cosiddette Quite Room in cui potersi “ritirare” per fare delle riunioni che richiedono un isolamento completo e massima concentrazione.

Il tutto non deve mai portare alla creazione di enormi “pollai”, ovvero mega open-space con decine di persone in cui il caos comincerà a regnare sovrano non appena si inizierà a lavorare e comunicare.

 

Stay tuned J

Un Leader non è per sempre… meglio non essere Chief di se stessi

Devo ammetterlo: non riesco a trattenermi dal sospirare ogni qual volta, in una organizzazione che si ispira all’Agile, incontro qualcuno che aggiunge ai ruoli specifici il suffisso “Chief”, trasformando di fatto quel ruolo in una posizione di implicito comando.
Se ho la fortuna di lavorare con persone che amano mettersi in gioco, e sono predisposte nello sfruttare l’ironia come strumento di crescita, spesso scherzo evidenziando come “Chief” mi ricordi il noto detersivo,

cif spruzzatore

e di come, tale suffisso, potrebbe indicare, in chiave Lean (DevOps), una persona che ispirandosi alle 5S e al concetto di Servant Leader, si occupi di pulire la scrivania dei propri colleghi per aiutarli a migliorare la propria organizzazione locale. Di certo non è il “capo”!

poster 5s leanproducts

Le 5S di Lean

Al di la del “suffisso” (che potrebbe essere anche “chief”, vista l’implicita accettazione che ormai gli si associa), è innegabile che una visione complessiva di un’azienda in chiave Lean/Agile richieda l’aggiunta di diversi ruoli di coordinamento, ma la loro “istituzione”, se avviene a freddo e senza coinvolgimento dal basso, rischia di trasformarsi in una nuova piramide organizzativain cui c’è un “capo” che da degli “ordini” espliciti ai subalterni, piuttosto che un Leaderin grado di ascoltare, risolvere le problematiche e guidare, quando necessario, le Persone con autorevolezza e raramente (se dicessi “mai” sarei poco realista) con autorità.

La questione, chiaramente, è riuscire a coltivare delle Persone che sviluppino le caratteristiche primarie di un Leader, riassunte nell’esplicita infografica di Alessandro Ferrari, andando al di là del titolo assegnato e dell’atteggiamento di aver raggiunto una “posizione” di comando sugli altri.

leader infografica

Un’azienda che ha la bravura, e un pizzico di fortuna, di far crescere i propri Leader, non ha bisogno di assegnargli titoli che richiamino il “comando”, perché queste Persone sono implicitamente riconosciute al suo interno come “trascinatori”, contemplando il fatto che ogni membro dell’organizzazione può diventare Leader in qualsiasi momento, catalizzando l’attenzione dei propri colleghi.  

Ciò, ovviamente, implica che un “Leader non è per sempre” solo perché è un “chief”, ma deve guadagnarsi tale riconoscimento giornalmente sul campo per non trasformarsi, nella migliore delle ipotesi, in “chief di se stessi”.

Stay tuned J

Asciughiamo il Lago dei Difetti, aka Lake of Defects

Build-in Quaility è uno dei principi fondamentali di Lean, base del pillar Jidokadella famosa House of Lean. Il concetto di per sé rasenta il “banale”: ogni prodotto realizzato deve incorporare e abbracciare strutturalmente gli aspetti di qualità. La questione, però, è che il significato specifico di “qualità” e le azioniche concorrono al suo raggiungimento sono elementi tutt’altro che univoci e definibili in modo predefinito e/o predittivo. In fondo, siamo nel modo dei sistemi complessi, dove dobbiamo costantemente validare le nostre assunzioni per trovare la soluzione migliore adatta al prodotto e al contesto. 

Strumentipraticheprocessitoolci consentono di validare gli aspetti realizzativi e funzionali del prodotto, ma essere opportunamente innestatiall’interno del ciclo di sviluppo, dando dignità soprattutto alle Persone che ne sono i veri detentori, operativi e di know-how.

Nel mondo del software è comune associare l’idea di qualità al testing (anche se è un pelino riduttivo) ma spesso non si ha un approccio strutturato relativo, andando a fare “azioni artigianali” che finiscono per concentrarsi soprattutto alla fine delle attività di coding. Paradossalmente, questo modo di procedere genera uno dei più grandi Waste (Muda, Sprechi) che si possano incontrare lungo la filiera di Delivery, creando a valle del flusso di lavoro un Lake of Defects in cui i tester devono improvvisarsi sommozzatoriper poter individuare le deficienze del nostro prodotto e comunicarle in qualche modo agli sviluppatori. 

lake of defects

Lake of Defects

Si intuisce come tale azione sia estremamente lunga e costosa, aumentando notevolmente il Lead Time (che, lo ricordiamo, è il tempo totale di realizzazione di una funzionalità, da quando viene inserita nel Product Backlog a quando viene rilasciata) e diminuisce la capacità di avere feedback rapidi il più vicino possibile la cellula(o team) che fattivamente sta realizzando la specifica attività. 

L’approccio che mi capita spesso di utilizzare per cominciare a “drenare il lago” è quello di introdurre il noto modello della Piramide di Testing(Testing Pyramid, rif Mike Cohn), facendo attenzione sempre ad evidenziare che, appunto, si tratta di un modello e che, in perfetta chiave Agile, lo stesso va contestualizzato e validato operativamente sul campo.

testing pyramid

Testing Pyramid

Lo scopo è quello di spalmareil testing, ma più in generale tutte le attività annesse al raggiungimento dell’obiettivo build-in quality, lungo l’intera filiera di delivery. Si tratta di un approccio fondamentale e portante per avviare una “vera” trasformazione in chiave DevOps

Facciamo un esempio: se non ho un insieme valido di unit testall’atto della Continuous Integration, non sto facendo Continuous Integration (CI), ma semplicemente merge del codice! Ricordo che l’obiettivo della CI è quello di fornire rapidamente un feedback su quanto realizzato, non quello di generare la build!

Con un approccio strutturato alla qualità (o al testing, se preferite leggerlo in tal modo), si riesce ad asciugare il lago, trasformandolo progressivamente in una pozzanghera (Puddle of Defects) e, idealmente, facendolo scomparire del tutto.

puddle of defects

Puddle of Defects

Migliorando costantemente il proprio approccio alla qualità, la necessità di avere un “team di testing” viene tendenzialmente meno e le Persone che prima si comportavano da sommozzatori, possono dedicarsi a portare un reale e costante valore aggiunto, mettendo al centro il cliente in chiave Customer centric.

Stay tuned J

La Teoria della Scarpa a Rovescio

Più si cresce e più si tende ad amalgamarsi alle regole che tipicamente condizionano il nostro ambienteil nostrostile di vita. Si tratta di un processo che ci accompagna in modo silente, non accorgendoci nemmeno del fatto che esso sia in atto e di come limiti, in modo crescente, la capacità di guardare oltre gli schemi, così come quella di trovare modi ed atteggiamenti che riescano ancora a stupirci in risposta alla condizione di appiattimento generale.

Una metafora che “calza a pennello” è quella dei bambini che provano a camminare con le scarpe dei genitori: incoscientemente, e divertendosi, provano a indossarle in tutti i modi possibili, fin anche mettendola a rovesciorispetto al piede e provare a fare qualche passo.

scarpa rovescio

Ecco la magia! I bambini sperimentano per apprendere, senza nessuno che debba dirglielo o insegnarglielo… è così e basta.

Eppure, più si diventa grandi, meno possiamo mettere la “Scarpa a Rovescio”, non fosse altro che “fisicamente” non riusciamo a farlo: anche se prendessimo una scarpa della taglia doppia rispetto alla nostra, la cosa è probabilmente impossibile.

Riportando la metafora al nostro contesto, ciò significa che più ci amalgamiamoal contesto operativo a cui apparteniamo, più ne diventiamo contaminati, e più diventa difficile provare a guardare fuori dagli schemi.

Assimiliamo un modo di fare che ci porta in una comfort zone, trasformandoci in “pigroni” che provano a galleggiare sulle attività giornaliere, riducendo, se non perdendo del tutto, lo spirito disperimentazione della Scarpa a Rovescio.

Più cadiamo in questo limbo, meno siamo soddisfatti di quanto facciamo e, cosa che spesso sfugge alle organizzazioni, meno facciamo l’interesse per il contesto in cui operiamo: un manager che non sbaglia mai, non prova ad innovare, trovare nuove strade, non si ferma a riflettere, è, con molta probabilità, un cattivo manager che non sta guardando al futuro dell’organizzazione essendo “soffocato” dal quotidiano. Stesso discorso per tecnici, operativi, e tutte gli altri ruoli aziendali che possono venirci in mente.

Ma come reagiamo a questa condizione? Dobbiamo tornare un po’ bambini, andando a riscoprire la soddisfazione intrinseca nello sperimentare, nel porsi fuori dalla propria area di sicurezza, in modo da reinventarsi e reinventare la propria professione e professionalità.

Dobbiamo continuamente rincorrere l’effetto “WOW!”, rilassandoci ed imparando a guardare le questioni da una moltitudine di angolazioni, cercando lo spazio che gli altri ignorano e che ci permetterà di fare la differenza.

effetto wow 

Certo, per fare questo, è necessario che la nostra azienda abbia una cultura orientata alla sperimentazione ed all’apprendimento (la terza via di DevOps e uno dei pilastri di Lean), creando una safety-netin cui muoverci con la certezza che qualsiasi sarà il risultato della nostra azione, avremo comunque raggiunto un risultato apprezzato in quanto tale.

Chiudiamo con una frase resa famosa da Steve Jobs che sembra fatta a pennello: Stay Hungry, Stay Foolish!

Stay tuned J

Il Fattore Tempo dell’Obiettivo Sostenibile

Nel mondo Agile, il team è praticamente alla base di ogni aspetto operativo, tant’è che uno degli elementi primari che da coach affrontiamo è quello di “creare il team” in quanto “cellula vivente”, non considerando come team singole persone sedute adiacentemente.

Non potrebbe essere altrimenti, visto che questo aspetto è il succo del primo Valore del Manifesto: Persone e Iterazioni, più che Processi e Tool ed è anche il cuore dei movimenti che cercano di guardarne l’evoluzione, come Heart of Agile e Modern Agile, senza dimenticare Lean.

Ma, per quanto non sia mai semplice supportare questo percorso di amalgamazione, le azioni cambiano in funzione anche ad una considerazione profonda rispetto al motivo stesso di esistenza del team: siamo in presenza di un team di mercato (o di prodotto) o un team di progetto?

Per prodotto intendiamo un manufatto che soddisfi un’esigenza di uno o più stakeholder e che richiede un supporto appropriato per poter essere “consumabile” ed evolvibile nel tempo. Per progetto, invece, un’azione limitata nel tempo, sia relativa ad un prodotto che isolata da altri contesti.

SelfOrgTeam

Nel caso del team di mercato, il lavoro sarà proprio quello di creare una squadra orientata a soddisfare i propri clienti, andando così a lavorare sui concetti tanto cari al mondo Agile come: team cross-funzionali, skill t-shaped, comunicazione, collaborazione e così via. In questo caso il Fattore Tempo è legato agli impegni rispetto al mercato e non è un elemento caratterizzante il team.

Nel caso del team di progetto, le dinamiche possono essere completamente differenti. Il caso più articolato è quando il team viene “assemblato” per realizzare una iniziativa isolata, portando al tavolo persone che prima si conoscevano appena (o non si conoscevano affatto) e sono appartenenti anche ad aree organizzative diverse o, addirittura, a fornitori diversi. In questo scenario, il Fattore Tempo scandisce l’esistenza del team, un po’ come nel film Time Out, del 2011, dove la vita delle persone è scandito da un orologio biologico artificiale e ogni azione o acquisto comporta una riduzione del tempo a disposizione, spingendo, dualmente, a sacrificare il superfluo per aumentare o mantenere stabile quello residuo.

timeout film

L’orologio biologico artificiale del film Time Out

Partendo da queste considerazioni, come possiamo aiutare il team, sapendo che ogni azione comporta una riduzione del tempo alla base stessa della sua esistenza? Prima, probabilmente, bisogna fare un passo indietro e chiedersi perché in una tale situazione si voglia adottare un approccio Agile che predilige, come detto, il concetto di stabilità del team e orientamento alla soddisfazione del cliente, e se le motivazioni sono convincenti (prima di tutto per il Business!), andare ad intervenire in funzione dell’Obiettivo Sostenibile

Provo ad esplicitare questo concetto con un esempio: se so già che il team a fine progetto verrà sciolto, potrei provare a concentrare l’azione di coaching sulle pratiche più tecniche orientate all’aumento della qualità, piuttosto che dedicare il tempo all’adozione di un framework come Scrum. Potrebbe infatti bastare una Kanban-like board, con gli elementi essenziali inerenti alle Storie e alcune metriche annesse, per favorire una maggior comunicazione tra i membri del team, evitando di “consumare” troppo tempo.

Ecco, qui si evidenzia ancora una volta come l’esperienza, la caparbietà e lo spirito di osservazione di un coach possono fare la differenza nel portare l’Agile anche in quei contesti che, a prima vista, sembrano fortemente disfunzionali, evitando di cadere nella trappola di pensare che Agile significhi appendere post-it al muro [cit. Giulio Roggero]!

 

Stay tuned J