Anche quest’anno abbiamo partecipato all’evento che raccoglie coach agili da tutta Italia e anche dall’Europa. Nei giorni passati a Trento, confrontandosi con decine di partecipanti, è stato possibile vedere le tendenze e le evoluzioni del mondo agile grazie ai contributi e alle esperienze di numerosi coach.
Agile Coach Camp Italy: istruzioni per l’uso
L’evento Agile Coach Camp Italy [1] si è svolto a Trento con la formula della un-conference di cui abbiamo già parlato diffusamente nel resoconto [2] relativo all’edizione del 2013, cui rimandiamo per dettagli su questa modalità. In breve, a differenza delle conferenze a programma prestabilito, questa formula prevede una fase iniziale in cui si organizza collettivamente il programma dei vari talk. Grazie a quello che viene definito market place, una sorta di vero e proprio “mercato rionale” dei contenuti, i partecipanti portano la loro “merce” (cioè i temi su cui sono preparati e che possono trattare con competenza) e la offrono agli “acquirenti”.
Figura 1 – Le lavagne con il programma del venerdì.
Dopo una serie di “contrattazioni”, volte a ottimizzare tempi e collocazione spaziale degli interventi, si arriva a definire il programma dei vari talk, distribuiti nei vari spazi a disposizione e nei vari orari a seconda dell’interesse alla partecipazione manifestato dai presenti.
Figura 2 – Le lavagne con il programma del sabato.
Partecipazione transnazionale
Sebbene si tratti principalmente di un evento dedicato al pubblico italiano, non sono mancati esponenti del movimento agile provenienti da altre nazioni, come è comune in questo tipo di ritrovi. Proprio per facilitare la partecipazione di tutti, Agile Coach Camp si svolge in italiano e in inglese: sono svolte in inglese le fasi comuni, come il market place o le introduzioni e le conclusioni, nonchè i singoli interventi cui partecipino persone che non parlano l’italiano; laddove però, nelle discussioni specifiche, ci siano solo parlanti italiani, si usa tranquillamente la nostra lingua.
Rompere il ghiaccio
Anche se il grosso delle attività è concentrato al venerdì e al sabato, il Camp comincia al giovedì sera, per dare modo ai partecipanti di “rompere il ghiaccio” con momenti conviviali e con attività ludiche che consentano di fare squadra ed entrare in confidenza.
Quest’anno abbiamo sperimentato il domino run, un gioco creato con le tessere del domino, in cui le persone erano divise in 4 gruppi: ognuno doveva costruire il suo “percorso” con le tessere del domino, che poi sarebbero state fatte cadere innescando la “reazione a catena” tipica di questi giochi, ma il concetto era che a “innescare” le tessere di un gruppo doveva essere il “percorso” di tessere creato da un altro gruppo. E questo presupponeva una certa collaborazione, e una serie di accorgimenti cui i partecipanti dovevano arrivare in maniera intuitiva e con un processo di successivi raffinamenti.
La componente “metodologica” era rappresentata dal fatto che i gruppi non potevano parlare tra loro, ma dovevano avvalersi del lavoro di un product owner che si coordinava con gli altri, in un luogo separato, per poi riportare le “specifiche” al proprio team.
Molto divertente e istruttivo, ma è stato difficile mantenere in piedi il proprio circuito di domino…
Figura 3 – Domino run: un ottimo modo per rompere il ghiaccio e creare un positivo clima di collaborazione.
Le tematiche
Al di là dei singoli interventi, e di qualche tema specifico, ci sono state alcune tematiche generali che hanno raggruppato diversi contributi.
Scalabilità
Un argomento abbastanza dibattuto e presente in svariati interventi è stato quello della scalabilità dell’agile: portare Scrum a un piccolo team (la dimesione micro) così come allargarlo a intere divisioni aziendali o ad aziende di grandi dimensioni (l’aspetto macro).
Test
Altra tematica piuttosto diffusa è stata quella relativa ai test e al Test Driven Design, che ha affrontato da un lato l’importanza e la validità di queste metodiche, ma al contempo ha messo in luce come ci sia stata un’adozione meno forte di quello che inizialmente si pensava.
Transizioni
Si è poi discusso diffusamente di transizioni ossia di come favorire e gestire il passaggio da situazioni “tradizionali” a organizzazioni basate su metodologie agili. Qui, con la presentazione di esperienze dirette, si è anche un po’ sfatato quel mito che vede le resistenze all’adozione di un paradigma agile dovute sempre e solo al management e al vertice della piramide organizzativa tradizionale. In certi casi, infatti, a fronte di un management “illuminato”, si sono sperimentate delle forti resistenze proprio a partire dai membri del team di sviluppo, che si vedevano eccessivamente responsabilizzati e chiamati a un profilo di maggiore decisionalità e autonomia.
Portfolio management
Infine, si è dato un certo spazio al portfolio management, ossia alle tecniche per gestire in maniera agile tutto l’insieme dei progetti e delle attività di una organizzazione, in maniera da avere una visione globale, in senso lean/agile di quello i diversi gruppi di lavoro portano avanti parallelamente nell’azieda.
Gli interventi
Riportiamo di seguito brevi note su alcuni degli interventi cui abbiamo partecipato o di cui abbiamo avuto ampio resoconto. Lo scopo di tali note è di fornire alcuni spunti di riflessione, più che quello di fare una precisa cronistoria del contributo, che per ovvie ragioni non è possibile riportare in tutti i suoi aspetti sulle pagine di una rivista. Un altro buon motivo per partecipare a eventi come questi: l’aspetto esperienziale, l’essere presenti fisicamente, consente di sperimentare non solo i contenuti, ma anche tutto quell’insieme di feedback, di scambi, di confronti con gli altri che arricchiscono il valore dei contenuti stessi.
Event storming
Molto interessante è lo strumento di lavoro portato avanti da Alberto Brandolini [3]: Event Storming è un metodo per modellare un qualsiasi processo (ad esempio la ideazione, creazione ed erogazione di corsi) tramite un sistema basato sugli eventi. In pratica, si lavora con un grande rotolo di carta, la cui altezza è di circa 50 cm, che è possibile srotolare sul pavimento. Su questo foglio, si applicano dei post-it di colore diverso che rappresentano gli eventi, gli attori interni ed esterni, e così via.
Figura 4 – Una sessione di event storming: un tool molto utile per modellare i processi.
A mano a mano che i diversi eventi vengono in mente ai partecipanti, questi li scrivono su un foglietto del colore giusto a seconda dell’entità (evento, attore, etc.) e lo collocano sul grande rotolo. In questo modo, si effettua un “brainstorming” ordinato per eventi. Una successiva fase di “normalizzazione”, facilitata dal coach, tende a mettere ordine in questi eventi.
Il punto di forza di questa metodica sta nel fatto che essa non richiede una soglia di ingresso elevata: la notazione non esiste a priori e non è necessario che tutti conoscano delle notazioni standard, per esempio UML, per poter contribuire. Inoltre, in questo modo, i sistemi si formano a poco a poco e non devono essere concepiti in maniera precostituita. Si tratta di un workshop di sicuro interesse: consigliamo a tutti coloro che ne avessero la possibilità di seguire questo seminario, visto che Alberto lo sta portando in giro in numerose conferenze.
No estimates
Abbiamo visto i sistemi di stima agile, utilizzabili ad esempio con Scrum, proprio nel numero scorso di MokaByte [4]. Nell’intervento intitolato No estimates (“nessuna stima”), si è parlato di stime in questo senso: prima ancora di preoccuparsi su come fare le stime, cioè che tecnica e che strumenti adottare per fare le stime, preoccupiamoci di capire se ha senso in quel progetto fare le stime oppure no.
Figura 5 – No estimates.
In certi casi, le stime hanno poco senso, e rispondono più a un desiderio di placare l’ansia (del team, del committente, del management…) che non a quello di una realistica valutazione in anticipo dei molti fattori che entreranno nel progetto. La conclusione è che, se qualcuno ce le chiede in ordine al contratto da firmare, le stime si fanno comunque; ma in alcuni casi, fare le stime non ha una reale affidabilità e può risultare addirittura in un impiego di tempo che sarebbe meglio dedicare ad altre attività. Una riflessione di Martin Fowler, citata nella bibliografia dell’articolo del mese scorso sulle stime agili, permette di approfondire il discorso.
La definzione dei requisiti
Matteo Vaccari ha fatto una riflessione sul modo in cui consideriamo i requisiti, sul fatto che occorra farli emergere in una conversazione con il cliente, e sul peso che viene dato a quelli funzionali rispetto a quelli non funzionali. Un intervento ricco di spunti di riflessione, affinchè i requisiti siano soprattutto requisiti “di valore”.
Gestione del portolio
Giulio Roggero e Stefano Leli hanno affrontato la grande tematica del portfolio management. Hanno mostrato degli esempi in cui è stato ricostruito l’intero insieme dei progetti in corso in una organizzazione. Spesso, nelle aziende, non c’è un quadro completo e dettagliato dei progetti in corso e del loro stato di avanzamento, nonostante i tanti strumenti tradizionali che si utilizzano. Nelle transizioni agili, semplificando al massimo, creare una “kanban delle kanban” consente invece di avere una visione globale su quel che sta succedendo, anche nel caso di centinaia di progetti, come illustrato da Giulio a riguardo di una grande azienda editoriale. In quel caso, le pareti di una intera stanza sono diventate la kanban board che ha consentito visualizzare e gestire i molti progetti in corso.
Il Disney Model
Fabio Fabbrucci ha affrontato il Disney Model, tecnica di cui abbiamo già parlato su queste pagine, e che era usata come strumento di “brainstorming” negli studi della casa di produzione di Walt Disney. Questa tecnica si basa su tre fasi distinte e diverse, che vanno mantenute separate e che hanno funzioni ben precise. La prima fase è quella del dreamer in cui si punta produrre idee. La seconda fase è quella del realistic in cui si analizza l’idea precedentemente emersa e si cerca di implementarla valutandone la fattibilità, ma in un’ottica positiva. Nella terza fase, quella del critic, si cercano i punti deboli dell’idea e del piano appena identificato, per poi ripartire con un ulteriore ciclo. In questo intervento si è messo in luce come questo approccio in tre fasi possa essere utile sia nella fase di visioning e creazione, che nelle retrospettive di progetto.
Creare una startup tecnologica
Un intervento breve e non molto affollato, ma estremamente interessante, è stato quello in cui si è parlato di creazione di startup tecnologiche. Attraverso il caso di Make It App [5], sono stati illustrati i fallimenti e le conquiste di una startup innovativa e attiva in un ambito molto importante come quello delle app mobile.
Figura 6 – Creare una startup: l’esempio di MakeItApp.
Interessante una considerazione: al di là di tutte le analisi preventive, dei business plan e delle stime previsionali, la startup ha cominciato a funzionare… quando ha cominciato a fare qualcosa, ossia quando si è investito un budget per del personale e dei locali e si è messo un gruppo a lavorare su dei progetti.
Shark model
Pierluigi Pugliese ha presentato il cosiddetto Shark model che è un nome provvisorio per un sistema volto a guidare i coach nei loro interventi. Infatti il tipo di situazione in cui si va ad operare, e i modi di agire del coach agile non possono essere sempre gli stessi, ma necessitano di flessibilità e di adattamento al contesto. In tal senso, è differente la situazione del gruppo di lavoro in cui sta per “esplodere una bomba”, rispetto a quello del gruppo che va “semplicemente” motivato per fare l’ultimo kilometro che lo separa dal traguardo, così come è ancora un’altra storia quella del gruppo di lavoro in situazione di “nebbia”, cioè a dire che non sa esattamente come e in che direzione muoversi. Attraverso una serie di diagrammi e di indicazioni, Pierluigi ha mostrato dei punti di partenza da cui il coach può muoversi, fermo restando che non esistono soluzioni preconfezionate.
Figura 7 – Pierluigi Pugliese durante uno dei suoi interventi.
Hosting leadership
Sempre Pierluigi Pugliese ha parlato di hosting leadership. Così come la servant leadership ha preso il posto del classico management command & control, la hosting leadership rappresenta la nuova frontiera del modo di intendere il ruolo di manager. In cosa consiste? La metafora è quella del “padrone di casa” che invita le persone a una festa e deve assicurarsi che tutto funzioni al meglio: che il cibo e le bevande siano in quantità adatta, che siano di qualità opportuna, che sedie e tavoli siano disposti nel modo migliore, deve accogliere gli invitati che arrivano, presentare le persone che non si conoscono, alimentare la conversazione e, nello spiacevole caso che qualcuno beva troppo e abbia comportamenti sconvenienti, deve “tenerlo a bada”. Questo esempio serve a spiegare che la leadership si deve estrinsecare sostanzialmente come funzione attiva ma non di “comando militaresco”, nè tantomento di “servitù sottomessa”. In tal senso, il concetto di hosting leadership riassumente bene questo punto di equilibrio: si partecipa al processo, ma non come “eroi” che guidano a testa bassa il proprio gruppo, nè come “serventi” che risolvono tutti i problemi del gruppo. Lo host leader è un facilitatore che prende parte alle attività e mette tutti nelle condizioni migliori affinchè svolgano serenamente i loro compiti.
Il futuro dell’agile
Una sessione è stata dedicata alla discussione sul futuro dell’Agile. Non si è trattato di un momento di rabdomanzia o lettura dei tarocchi, ma di una riflessione su due interrogativi: “Agile: cosa ci aspettiamo che sarà?” e “Agile: cosa vogliamo che sia?”. Quello che è emerso è stato molto interessante: per molti un punto importante è stato che, al di là delle competenze acquisite, al di là del concetto di “transizione”, al di là delle pratiche ormai assodate, diventa importante in questo periodo mettersi in relazione con i “non agili” che ancora conoscono solo Gantt e fogli di calcolo e trovare un modo per comunicare e condividere punti di incontro. In tal senso, era stato interessante un altro intervento in cui un ingegnere ci aveva mostrato il modo in cui aveva portato metodologie agili e kanban board all’interno di un processo industriale “classico” che non ha a che fare con lo sviluppo software (si trattava di una azienda di automazione industriale e di produzione di macchinari per la lavorazione della pietra). Con un approccio molto “empirico”, era riuscito a collocare in questo processo tutta una serie di pratiche agili (kanban board, scrum) senza andare a sconvolgere, almeno in modo esplicito, certe “sicurezze” dei manager.
Soft skills
Non sono mancati interventi dedicati alle pratiche legate alle dinamiche dei gruppi e alla psicologia dei processi di lavoro. Queste competenze risultano importanti per favorire i processi decisionali, gestire i conflitti, ottimizzare i tempi e, in definitiva, mettere le persone nelle condizioni migliori. Pierluigi Pugliese ha mostrato un metodo per favorire le scelte tra varie soluzioni, che utilizza una sorta di “psicodramma” teatrale, con diversi “attori” che rappresentano i diversi elementi (soluzioni, elementi di disturbo, elementi di ausilio) e che vengono disposti nella stanza in una sorta di “costellazione”. Sulla base di domande, movimenti, riflessioni, colui che doveva prendere la decisione, e che assisteva dall’esterno alla “rappresentazione”, teatrale otteneva una visione più ampia, e al tempo stesso più profonda, del processo decisionale di cui doveva essere protagonista. L’esercitazione ha messo in evidenza una tecnica che è difficile da raccontare, ma che, se provata dal vivo, potrà risultare risolutiva per molte persone.
Conclusioni
Come diciamo sempre, questi eventi rappresentano degli episodi esperienziali in cui non si tratta solo di assistere, ma di partecipare apportando le proprie esperienze e uscendo arricchiti sia sul piano delle competenze tecniche che del coinvolgimento emozionale.
L’Agile Coach Camp 2014 ha rappresentato in questo senso un interessante esempio di “non-conferenza” poichè, oltre a presentare alcune novità e a favorire la riflessione, ha costituito un momento in cui si è anche tentato un sguardo in prospettiva su quello che potrà essere, negli anni immediatamente a venire, lo sviluppo delle metodologie agili e delle discipline ad esse connesse.
Riferimenti
[1] Il sito dell’ACCit 2014
[2] Giovanni Puliti, “Agile Coach Camp 2013. Reportage da Trento”, MokaByte 186, luglio/agosto 2013
https://www.mokabyte.it/cms/article.run?articleId=EM2-NOL-PDC-R4X_7f000001_11885319_cec3f68c
[3] Event Storming
http://ziobrando.blogspot.it/2013/11/introducing-event-storming.html#.U5sj4y8Zfhc
[4] Giovanni Puliti, “Guida Galattica per scrummers – VIII parte: Le stime.Che cosa sono, come e quando farle in un progetto agile”, MokaByte 195, maggio 2014
https://www.mokabyte.it/cms/article.run?articleId=3IR-4Z5-C4S-B3Z_7f000001_10073811_f5528cb6
[5] MakeItApp, la piattaforma server per app mobile