Premessa

Nel riordinare il materiale di MokaByte, in vista dell’imminente restyling del sito, ci stiamo soffermando, qua e là, in diversi articoli di molti anni fa. Ce ne sono alcuni che, a distanza di tanti anni, mantengono una loro validità. 

L’articolo che presentiamo uscì esattamente cinque anni fa. Fu l’ultimo di una serie di resoconti che a partire dal 2010, pubblicammo ogni anno dopo aver preso parte alla conferenza Better Software. Cominciata con l’edizione del 2009 (alla quale però non prendemmo parte) la conferenza Better Software andò avanti per otto edizioni, concludendosi appunto con Better Software 2016, qui raccontata.

Nel panorama italiano delle conferenze, Bettere Software ha rappresentato un’esperienza molto eclettica, che subì un naturale processo di evoluzione nel corso degli anni spostandosi dagli iniziali argomenti strettamente IT ad orizzonti più legati al mondo Agile e del management. A nostro giudizio, ha rappresentato un momento davvero importante per la diffusione di idee e approcci innovativi.

Il cambiamento degli scenari, e forse anche il fatto che la conferenza aveva esaurito il suo compito “istituzionale”, fecero sì che quella del 2016 fosse l’ultima edizione. Ma restiamo molto legati a quell’esperienza e volentieri ripubblichiamo quell’articolo.  (n.d.r.).

Luglio 2016

Formula workshop

Per il 2016, Better Software [1] torna nella sua collocazione temporale “classica” vale a dire a ridosso dell’inizio dell’estate, come era stato per molti anni. Con le giornate del 13 e 14 giugno scorsi [del 2016, n.d.r.], questa particolare conferenza, eclettica e dedicata ai temi del management in ambito sviluppo software e non solo, raggiunge l’ottava edizione (quarta del nuovo ciclo) a meno di un anno dall’evento precedente, che si era svolto a inizio autunno dell’anno scorso.

Quest’anno la formula ha puntato decisamente sui workshop anche se non sono mancati un paio di interventi “frontali”. Non che la cosa rappresenti una assoluta novità, perché anche in molte precedenti edizioni erano presenti i workshop, in cui si sperimentano principi, pratiche e novità dal panorama della gestione Lean/Agile. Ma nell’edizione appena trascorsa, il workshop è stato il centro dell’intera conferenza, anche in virtù dei riscontri ottenuti negli eventi degli anni passati. Con uno di quei discutibili giochi di parole che tanto sembrano piacere, si potrebbe dire che ormai Better Software è diventata una conferenza adatta a chi sia interessato a formarsi piuttosto che a informarsi.

Limiti e punti di forza

Le due giornate si sono svolte all’insegna di una serie di workshop che duravano 2, 4 o 6 ore. Va detto che almeno un “limite” è emerso chiaro: certe sessioni hanno un po’ sofferto per i tempi stretti. Qualche workshop di 2 ore ne avrebbe meritate almeno 4. E anche le sessioni più lunghe, che hanno preso una giornata intera, forse si sarebbero svolte ancora meglio se spalmate su due giorni. Però questo è uno scotto da pagare al fatto che siamo in presenza di una conferenza e non di un vero e proprio workshop dedicato.

Utilizzando una metafora enogastronomica, diciamo che un evento come Better Software è una sorta di ottima degustazione: si assaggiano cibi e bevande di qualità, se ne capiscono le caratteristiche e il gusto, ma il “pranzo completo” o l’acquisto di una determinata “specialità” in quantità più ampia è qualcosa di successivo.

Se teniamo per buono questo esempio, si può dire che il limite della degustazione — molte cose diverse, in quantità relativamente limitate — ha come positivo contraltare la possibilità di “assaggiare” — e non solo di leggere sul menù — numerosi piatti capaci di incuriosire e di lasciare una corposa impressione al palato.

Non vorrei essere frainteso, però: i workshop hanno raggiunto sicuramente il loro scopo di far comprendere certi concetti e di mandare a casa i partecipanti con un bagaglio di competenze ampliato e approfondito. Certo è, però, che chi è rimasto particolarmente interessato da alcune tematiche potrebbe trovare utile approfondire ulteriormente l’argomento in maniera dedicata e unitaria.

Partecipando ai workshop, uno degli aspetti emersi è stato il livello medio dei partecipanti: persone in genere molto attente, molto cordiali, che hanno interagito in maniera collaborativa e informale. È una costante di Better Software, che è sempre emersa anche nelle edizioni precedenti, che abbiamo raccontato sempre su queste pagine. E va notato che, in particolare quest’anno, non tutti i partecipanti erano già degli “esperti” del management Lean/Agile: per alcuni, certe tematiche erano quasi una novità e ciò nonostante hanno partecipato in maniera coinvolgente alle attività.

I workshop e le attività

Riportiamo nelle pagine seguenti dei brevi resoconti sui workshop e sulle altre attività cui abbiamo partecipato. Nelle edizioni precedenti, i nostri resoconti erano lunghissimi; e per rendersene conto basta leggere qualcuno degli “Articoli nella stessa serie” nel box in alto a destra. Del resto, viste le mumerose “presentazioni” a cui partecipavamo in maniera serrata, le cose da raccontare erano moltissime.

In quest’occasione, invece, racconteremo meno, visto che i workshop cui abbiamo partecipato sono stati ovviamente limitati, ma ci auguriamo di riuscire comunque a trasmettere il valore riscontrato dalla partecipazione a tali attività. Infine, prima di entrare nel resoconto, permetteteci una nota personale: non so se a scriverlo si perde quella minima parvenza di serietà professionale ancora rimasta, ma, sappiate che, per chi scrive, partecipare ai workshop è stata anche ottima occasione di sano divertimento…

Felice Pescatore. Agile IoT. IoT becomes a serious business

Il primo workshop a cui abbiamo preso parte è stato quello di Felice Pescatore — che peraltro da questo mese collabora con MokaByte con una bella serie di articoli su Disciplined Agile 2.0 — dedicato alla gestione agile dei processi legati a Internet of Things [2].

Il workshop si è svolto con una breve introduzione sul mondo Agile IoT [3] in cui si è mostrato come si tratti di un “esperimento” che tenta di legare la gestione dei processi di matrice Agile con il mondo dei makers e la “fisicità” dei dispositivi elettronici. È richiesto un mix tra competenze software, elettronica, data science. In questa presentazione si sono visti brevemente anche l’importanza e i limiti di Arduino.

IoT è Internet + dispositivi: c’è quindi un lato “materiale” dell’IoT (Things) che è “concreto” e non è solo software. Questo implica una serie di problemi pratici da affrontare e risolvere, che nello sviluppo del software immateriale non sono presenti. In Agile IoT, quindi, occorre la compresenza di capacità “materiali e immateriali”, proprio come succedeva nella bottega artistica rinascimentale.

Il “gioco” da svolgere per arrivare a comprendere alcuni concetti prevedeva la creazione simulata di dispositivi IoT. In pratica, si ipotizzava di dover costruire dei segnalatori intelligenti da installare nei pressi delle statue del centro storico di Firenze, che avrebbero dovuto fornire informazioni e messaggi pubblicitari. L’altro requisito importante era che essi fossero autoalimentati e connessi al server centrale.

Qui sono emerse fin da subito le differenze tra processo strettamente informatico e un processo che invece contempli anche la presenza di dispositivi elettronici fisici. I dispositivi, infatti, prevedono anche delle fasi di prototipazione rapida su oggetti “concreti” che venivano simulati dalla costruzione di una torcia a mano.

Il flusso di lavoro veniva visualizzato utilizzando una peculiare Kanban board in cui oltretutto dei piccoli post-it contribuivano con il loro codice colore a identificare la natura dei diversi task:

• Rosso = hardware
• Giallo = software / firmware
• Blu = internet / servizi cloud

Con molta fantasia e qualche piccola difficoltà, si arrivava alla “costruzione” dei dispositivi dotati di torce intelligenti al loro interno.

In tutto questo processo emergeva chiarissima la differenza di terminologia tra sviluppo software e IoT con la sua componente elettronica. Un altro aspetto cruciale è che si notava mediamente un certo disallineamento tra stato effettivo di avanzamento delle attività e Kanban board: la lavagna deve riflettere lo stato di quello che succede, ma invece veniva lasciata un po’ indietro. E questo era dovuto sia ai tempi stretti imposti dalla formula del workshop, sia anche proprio alle difficoltà insite in un progetto “hardware” come questo, in cui appunto si evidenziavano gli aspetti “fisici” di IoT a cui gli sviluppatori “immateriali” non sono abituati.

Se possibile, in progetti come quelli Agile IoT, il ruolo chiave del Product Owner diventa ancora più cruciale, e questa è stata una delle riflessioni finali emerse dal gioco, unitamente alle già citate difficoltà create dalla presenza di oggetti fisici elettronici che si riflette su aspetti tipici delle metodologie Lean/Agile: per esempio, dal prototipo Arduino a un certo punto occorre passare al prodotto industriale; oppure, il Daily Standup Meeting va fatto dove si trovano le “macchine” e non nella sala in cui si è soliti farlo e così via.

Il workshop è riuscito nel suo scopo di mettere in luce le peculiarità di Agile IoT con la sua combinazione di aspetti software ed elettronici. Un elemento che avrebbe ulteriormente migliorato il gioco sarebbe stata la presenza, tra i materiali forniti, di un “riassunto” scritto che riportasse in dettaglio il compito da svolgere — costruire “segnalatori” pubblicitari da applicare in prossimità delle statue cittadine, autoalimentati e connessi etc. — e della terminologia specifica.

Ma, al di là di questi dettagli, si è trattato di un’interessante introduzione in un mondo particolare: chi tra i partecipanti era già più addentro al discorso IoT ha sicuramente apprezzato; ma certi concetti chiave sono passati anche a chi lavora sull’immateriale, purché avesse i rudimenti base di Kanban.

Silvia Toffolon. “People at work” canvas

Ossia… “come trasformare assieme ai clienti idee in progetti coinvolgenti e fare salire sul carro tutti fin dall’inizio” [4].

Silvia Toffolon presenta il suo metodo Creography [5] vale a dire un sistema basato su canvas e carte pensato per raccogliere informazioni spesso sfuggenti quando si delineino i contorni di un’idea o di un progetto. Il metodo Creography è basato su regole precise, è costituito da tabelloni (canvas) e carte ispiratrici, ed è molto adatto a far partecipare anche le persone più introverse.

Nel workshop si simula la seguente situazione: un gruppo di lavoro deve “costruire” una nuova modalità/strategia di brief per raccogliere dati ai fini di progetti di comunicazione, sia online che offline. Il tema è volutamente “non software” proprio per dimostrare come questo sistema di discussione e focalizzazione delle idee sia adatto a ogni tipo di azienda e attività.

Il canvas serve come strumento di focalizzazione per chi lavora sull’azione richiesta nell’obiettivo. È suddiviso in varie aree tematiche:

1. Valori
2. Altri scenari
3. Timori
4. Condizioni
5. Elementi distintivi
6. Persone e organizzazioni
7. Passato e presente
8. Passione

Accanto al canvas è presente un promemoria con le “regole del gioco” riportate ordinatamente su un foglio in modo che siano sempre presenti e disponibili per i partecipanti.

In pratica, si comincia a fare un giro di opinioni in cui i componenti del gruppo ascoltano, senza discuterlo, il parere degli altri presenti. Questo facilita l’esposizione anche alle persone più timide, che non vengono interrotte o “contrastate” e che possono quindi contribuire alla discussione.

C’è un coordinatore del gruppo, ma esso cambia a ogni fase successiva per creare un modello di leadership diffusa.

Alla fine del primo giro di esposizioni, c’è la discussione, il cui obiettivo è raggiungere una sintesi esplicativa delle diverse posizioni emerse: non deve trattarsi di un testo lungo — e questo viene “obbligato” dallo spazio presente nel modulo del canvas che è comunque limitato — ma deve essere sufficientemente chiaro per far capire a chi lo legge qual è stato il concetto condiviso raggiunto.

Con il succedersi dei diversi giri di opinioni, si riempiono i diversi moduli del canvas e il tabellone a poco a poco si completa, con le soluzioni che vanno a riempire le diverse “caselle” a mano a mano che la discussione procede. Questo fa sì che le persone si rendano conto dell’avanzamento dei lavori e del passaggio alle diverse fasi, eliminando quel senso di inconcludenza che spesso si percepisce in molte “riunioni” di stampo classico.

La “rigidità” a cui questo modello di focalizzazione e discussione costringe viene adeguatamente mitigata dalla presenza di carte ispiratrici. In maniera analoga a quanto accadeva in ambito artistico per le Oblique Cards di Brian Eno o a quanto si fa con le Points of You utilizzate nell’ambito del coaching aziendale [6], queste carte forniscono delle “suggestioni” di tipo visuale e testuale, che stimolano anche l’aspetto emozionale della discussione. Ci sono indicazioni come “Rendi esplicita la visione”, “Per vedere il futuro occorre identificare gli schemi ricorrenti” e altre frasi ispiratrici del genere.

Nel processo di individuazione delle soluzioni, non tutto è positivo e fila liscio. Tutti, più o meno hanno anche dei dubbi, delle perplessità, più o meno grandi. Un aspetto interessante, è che ai partecipanti viene chiesto di disegnare — non di scrivere testualmente — i loro timori nel modulo opportunamente dedicato: il disegno è capace di evocare e rappresentare aspetti che non emergerebbero necessariamente con la scrittura.

Al di là della strutturazione del sistema, due aspetti hanno colpito in particolare: il primo è che si tratta di un metodo che tutti i tipi di organizzazione possono adottare e che è possibile imparare grazie alla presenza di un facilitatore, che poi potrà comunque intervenire a supportare il gruppo quando ci sarà bisogno del suo contributo.

La seconda cosa è che si tratta di un’idea tutto sommato “semplice”, ma realizzata veramente bene e messa a punto in modo efficace: i materiali a disposizione (canvas, carte), le regole chiare e facile da seguire, l’adeguato bilanciamento tra strutturazione e creatività fanno di Creography una metodologia di focalizzazione e discussione che si presta a un’adozione in contesti molto differenti.

Stefano Leli & Giulio Roggero. Product acceleration track

Questo workshop ha preso un’intera giornata di lavori, dalla mattina al pomeriggio: sebbene fosse suddiviso in tre fasi, la stragrande maggioranza di coloro che ha partecipato alla prima, ha poi optato per rimanere anche nelle due sessioni successive. Personalmente, invece, non ho partecipato a tutte e tre le fasi, ma solo all’ultima.

Racconterò pertanto solo a brevi linee quello che è stato fatto, basandomi soprattutto sulle impressioni di alcuni dei partecipanti, con i quali ho potuto scambiare le varie impressioni al termine del pomeriggio e nella giornata successiva. È infatti anche in questo aspetto — il continuo confronto, lo scambio di impressioni, le discussioni sulle esperienze appena vissute — che si basa la possibilità di fissare i principi e le pratiche che vengono trasmesse nel corso dei diversi workshop.

Giulio Roggero e Stefano Leli [7] conducono un workshop di ampia portata: dall’idea al prodotto (quasi) finito, passando attraverso le diverse fasi, compresa la definizione dell’architettura e la prima stesura del codice. Ovviamente nelle 6 ore a disposizione non è possibile completare il percorso, ma alla fine del workshop i partecipanti sono andati via avendo visto, almeno a grandi linee, come si svolge l’intero processo. E anche i due speaker, per quanto piuttosto “stravolti” di stanchezza, sono apparsi abbastanza soddisfatti di essere riusciti a trasmettere il quadro d’insieme di questo modo di creare un prodotto.

Operativamente, le tre sessioni del workshop si sono svolte in una sorta di “Obeya room”, vale a dire una grande stanza sulle cui pareti sono affissi tabelloni, lavagne, kanban board e quant’altro sia necessario a visualizzare i diversi momenti ed elementi del progetto, vale a dire una serie di information radiators intorno ai quali tutti possano collaborativamente fare le loro considerazioni e apportare il loro contributo. Si tratta di uno “strumento” nato nell’ambito della “produzione industriale snella” o Lean Manufacturing che dir si voglia.

Con questi strumenti di supporto si parte dall’idea e si percorrono i vari passi che scandiranno l’arrivo al prodotto finale.

Si comincia con un elevator pitch ossia il tentativo di definire il proprio prodotto con una formula breve e concisa, ma completa, come se si dovesse spiegarlo a un importante finanziatore mentre saliamo con lui in ascensore.

Si passa poi allo studio delle personas creando personaggi fittizi ma realistici che interpretino gli utenti più o meno comuni del nostro prodotto.

Si approfondisce il rapporto tra utente e prodotto attraverso lo strumento dei customer journeys, ossia ipotizzando quei “viaggi” che gli utenti possono fare “navigando” all’interno della nostra applicazione, tenendo in considerazione l’interattività e la UX.

Segue la delicata fase dello story mapping in cui si inizia a raccordare quanto pensato in fase di definizione del prodotto con quelle che saranno le funzionalità che poi dovranno essere effettivamente sviluppate da chi realizza il codice.

Realizzando dei wireframe dell’applicazione, magari con fogli di carta disegnati che poi vengono “animati” con applicationi tipo POP – Prototyping on Paper, si passa a una vera e propria fase di realizzazione, in cui comincia a prendere forma il prodotto vero e proprio.

Ma anche il lato architetturale deve rientrare in questo processo: per questo esiste una fase dedicata al domain e una per la scelta dell’architettura (cominciando magari a definire un più generale stile architetturale per concentrarsi sulla sua implementazione solo in un secondo tempo).

Tutti questi aspetti devono convergere in una scrittura e riscrittura del codice dell’applicazione, in iterazioni successive, con rilascio progressivo di funzioni e miglioramenti, in un’ottica di continuous delivery.

Ci vuole poco a capire che approfondire tutti questi aspetti in una mattinata e in un pomeriggio (per quanto lungo…) è impossibile: accompagnare personale del business e team di sviluppo e farli passare dall’idea al codice richiede un lavoro di coaching agile della durata di più giorni. Ma la cosa buona ed efficace di questo workshop è stata quella di fonire un quadro d’insieme con un approccio al tempo stesso pragmatico e globale: non si tratta di pensare alla singola fase come slegata dalle altre, ma di concepire l’intero processo con una visione d’insieme e con la continua attenzione al feedback che ne scaturisce.

Marco Calzolari. A framework for Adaptive Career Design

Marco Calzolari affronta l’argomento delle Human Resources con un taglio particolare e innovativo [9]. In pratica, viene presentato un “modello esplorativo”, concretizzato in un canvas, per indagare a riguardo della carriera di un professionista, intesa in senso evolutivo.

Ogni carriera, infatti, viene vista come un processo di evoluzione professionale in cui è fondamentale il feedback. Occorre sviluppare talento e competenze, ma occorre anche capire come tali aspetti si possano inserire all’interno di un modello organizzativo e aziendale sempre più liquido.

Il workshop si incentra sulla presentazione e sull’uso di uno “strumento di progettazione” — un apposito canvas — che consente di mettere a fuoco svariati aspetti del proprio profilo professionale e di capire in che modo il proprio talento e le proprie competenze si mettano in relazione a quelle degli altri nel quadro più ampio della realtà organizzativa in cui si opera. Aspetti fondamentali per il funzionamento di questo approccio sono la trasparenza e la motivazione.

Si è trattato di una sessione estremamente coinvolgente: il lavoro nei diversi gruppi che sono stati formati ha dato ai partecipanti la possibilità di capire il senso e la “meccanica” del canvas utilizzato. Uno sguardo alle slide di supporto [10] può aiutare a farsi un’idea approssimativa, se non altro delle voci che compongono il canvas; ma si è trattato di un workshop in cui effettivamente soltanto la presenza e la partecipazione, unite all’opera di coaching di chi l’ha condotto, potevano portare alla comprensione dei concetti che si intendeva far passare.

In pratica, il canvas spinge il gruppo di persone a confrontarsi e consente a ciascun partecipante di mettere a fuoco diversi elementi legati al suo ruolo professionale e, di conseguenza, alla sua carriera. Le voci che compongono il canvas sono

• Unique value contribution
• Job title
• Favorite things / (don’t like too much)
• Overall strengths
• Purposes
• Main activities / (better not)
• Areas of improvement
• Needs
• Mutual commitments
• Overall outcomes

Esse non sono collocate a caso, ma sono distribuite ordinatamente in maniera da risultare orientate su diverse “direttrici”: ci si sposta da aspetti più legati all’individuo a quelli maggiormente orientati all’organizzazione, da aspetti che riguardano l’autonomia del professionista a elementi maggiormente legati al sistema nel suo complesso, da uno sguardo verso il proprio passato a una introspezione sul presente fino a una visione proiettata verso il futuro.

Una delle affermazioni che mi hanno maggiormente colpito in questo workshop è stato che il Job title si definisce gradualmente, in base ad altri elementi: è il ribaltamento di quello che spesso accade nelle aziende, dove esistono precisi organigrammi realizzati proprio in base a un ruolo professionale che poi magari rischia di essere solo un’etichetta applicata che non riflette perfettamente ciò che il professionista fa veramente.

Creati i gruppi con una sorta di “puzzle” in cui occorreva trovare le altre persone che completavano una particolare frase con dei frammenti pescati a caso, la simulazione prevedeva il seguente schema: si “inventava” una azienda che realizzava un determinato prodotto/servizio e poi si cominciava a compilare il canvas per far emergere una possibile struttura di ruoli professionali all’interno di quell’azienda.

L’impressione condivisa fin da subito è stata che il canvas per la progettazione adattativa della carriera svolgesse bene il suo compito: il gruppo in cui ho lavorato ha ben presto cominciato a entrare nei dettagli e le “caselle” da riempire nella creazione dei ruoli aziendali si sono andate pian piano completando. In pratica, si crea la struttura aziendale a partire dalle propensioni, dai talenti e dalle capacità effettive che sono presenti nel gruppo. E la cosa particolarmente interessante è che, dopo poche decine di minuti, i partecipanti riuscivano abbastanza fluidamente a discutere e confrontarsi: questo è successo tra persone che fino ad allora non si erano mai conosciute.

Dovendo esprimere un giudizio su questo workshop, direi che si è trattato di un’esperienza impegnativa e convincente: impegnativa perché affronta aspetti spesso trascurati o non messi a fuoco — o volutamente ignorati — che richiedono uno sforzo di comprensione e di approfondimento; convincente perché a un gruppo eterogeneo sono bastati un po’ di tempo, un approccio incentrato sulla trasparenza e la motivazione e qualche indicazione dal facilitatore per cominciare a intravedere nel giro di un paio d’ore la potenzialità “rivoluzionaria” che è presente in questo modo di affrontare le tematiche della gestione delle risorse umane.

E questo vale nei due sensi: da parte del professionista che voglia rispondere al meglio alla domanda “chi sono?” intesa in senso professionale, e da parte dell’azienda che intenda basare la sua strutturazione organizzativa anzitutto sulle persone e sui loro talenti. Un argomento sicuramente da approfondire.

Non solo workshop

L’abbiamo detto: i workshop hanno rappresentato il pièce de résistance dell’edizione 2016 di Better Software. Ma ci sono state anche alcune presentazioni “frontali” di cui vi diamo un rapidissimo resoconto.

Emiliano Soldi & Stefano Lucantoni. “The harder you push, The harder the system pushes back” ovvero “Quanti coach servono per cambiare una lampadina?”

Si è trattato di un talk che ha affrontato l’annosa questione delle transizioni in senso Lean/Agile delle organizzazioni [11]. Per rispondere all’interrogativo presente nel titolo del loro intervento, gli speaker dicono subito che può bastare la facilitazione di un solo coach se nell’organizzazione esiste una reale volontà di cambiamento.

Attraverso una serie di esempi, sia in senso negativo come nel caso di Kodak rimasta schiacciata dall’incapacità di cambiare, sia in senso positivo, si mostra come siano possibili comunque le transizioni agili, a patto di non confondere i modelli di cambiamento che si applicano alle persone con quelli che si applicano alle organizzazioni nel loro insieme.

Le persone devono sentirsi motivate e desiderose di cambiare per una convinzione che loro maturano: non devono essere spinte a cambiare in maniera “obbligata”. Anche perché il cambiamento investe diversi ambiti: il modo in cui si comunica, il modo in cui interagisce, il modo in cui si concepisce il tema del lavoro. In questo processo aiuta molto la creazione di spazi di consapevolezza all’interno dell’organizzazione tramite tecniche quali il diffuso World cafe o il Lean coffee (che è simile, ma con una lavagna Kanban).

Così come si cambia la cultura delle persone è possibile anche cambiare la struttura, perché è essa che a sua volta genera la cultura: le strutture governano i comportamenti. A tal proposito, vengono presentati dei modelli strutturali di Change Management, come il cosiddetto ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) e quello di Kotter, che si declina su un processo in 8 passaggi.

Soprattutto nelle grandi strutture, il processo è lungo e complesso e necessita di attori competenti in grado di portare strategie e tattiche comprovate per favorire tale transizione: creare team cross-funzionali svincolati dall’organigramma, impiegare dei format strutturati e ormai consolidati come il release planning meeting, il litf off, la open space technology.

In tutto questo, la figura e l’attività del facilitatore resta molto importante.

Francesco Fullone. Continuous budgeting

Il “keynote” di chiusura tocca a Francesco Fullone che parla di Continuous Budgeting [12] in maniera priva di ogni enfasi, ma guidando la platea attraverso una serie di riflessioni molto concrete.

L’intervento parte da una considerazione tanto semplice quanto evidente: oggigiorno la parola continuous è sempre più abbinata ai diversi aspetti dello sviluppo software, come nel caso di continuous integration, continuous deploy e continuous delivery.

Ma il budget che, in definitiva sta alla base di queste attività, non deve anch’esso essere continuous? Il budget definisce delle aspettative e lo deve fare con efficacia, efficienza e adeguatezza. Il budget è fluido e dinamico ed evolve proprio come evolve il codice… anche se a volte questo aspetto non appare chiaro come dovrebbe. Non si tratta di idee nuovissime, visto che di beyond budgeting si iniziò a parlare già dal 1998.

C’è un rischio insito nelle pur ottime pratiche agili ed è che esse si concentrano sulla risoluzione dei problemi nell’immediato, utilizzando metodi e tecniche sicuramente valide nell’immediato ma che possono far dimenticare il medio e lungo periodo. Questo rischio di mancanza di prospettiva va evitato quando ci si occupi di budget che deve diventare continuous: così come evolve un programma, evolce anche la complessità che esso comporta e deve evolvere anche il budget. Il software “scade”, l’hardware “scade” e le infrastrutture “scadono”. Questo va tenuto presente: occorre guardare ai possibili scenari futuri e considerarli nel budget, controllando il mercato e le sue evoluzioni e realizzando, di fatto, dei budget iterativi.

Da un punto di vista dei tool, se è vero che esistono degli strumenti specificamente dedicati al beyond budgeting, è anche vero che per il continuous budgeting può bastare un foglio di calcolo ben strutturato e utilizzato con il giusto approccio.

Conclusioni

Quella del 2016 è stata un’edizione stimolante e proficua. È decisamente formativa la possibilità di prendere parte a workshop in cui, fattivamente, si imparano valori, principi e pratiche che poi è possibile approfondire in altre sedi. Chi investe denaro e tempo per partecipare a un evento come questo deve comunque “portarsi a casa” un bagaglio di conoscenze, e la consapevolezza di aver preso parte a un evento con una spiccata caratterizzazione.

L’impressione è stata che questa formula funzioni e che, almeno in un momento in cui sono sempre meno le “novità” da raccontare in maniera frontale nei talk, possa rappresentare la colonna portante delle prossime edizioni. Better Software, quindi, si conferma anche quest’anno come marchio di qualità per le discipline del management legate allo sviluppo software.