Prima avevamo un solo team di 6-8 persone e un service owner che si occupava del contatto con i clienti e di facilitare la pianificazione. Tutti i progetti di tutti i clienti venivano gestiti in un unico calderone, poco strutturato ma molto fluido, tenendo sotto controllo il work in progress con l’utilizzo di una kanban board e pratiche di rilascio continuo, user story per user story.

Adesso ideato ha esattamente la stessa struttura di prima, duplicata e ogni nuovo team è grande la metà del primo: due team da 3-4 persone, due service owner ormai inglobati nel team (il vecchio service owner ha ricominciato a programmare!) e due kanban board separati.

La mentalità dietro la scelta

Tra i principi dell’Extreme Programming troviamo annoverati l’autosomiglianza e il flusso. I due nuovi team provengono dallo stesso insieme di soluzioni operative e, per certi versi, condividono già tutto l’implicito che regna sovrano nel lavoro di gruppo. L’organizzazione preesistente ci sembrava non avere grossi problemi se non per quanto riguardava il bilanciamento del flusso: troppo lavoro da conoscere (leggi stimare, ma la stima non è il vero obiettivo, quanto comprendere e sciogliere la complessità dei requisiti del cliente) e un team di sviluppo fin troppo efficace, troppo spesso a secco di backlog. Il service owner si trovava in difficoltà a capire quale priorità assegnare alle diverse user story provenienti da diversi progetti e, costituendo il collo di bottiglia del processo, risultava “colpevole” in realtà vittima delle circostanze. Sappiamo dalla teoria dei vincoli che è inutile lavorare sui colli di bottiglia diversi da quello pessimo per migliorare le prestazioni del sistema e pertanto eravamo consapevoli che non avremmo dovuto concentrarci ulteriormente sul migliorare i lead time del mero sviluppo.

Tipico nello studio dei sistemi complessi, quelli costituiti da agenti molto omogenei e con grande fluidità organizzativa e gerachica rivelano grande capacità adattiva e così è stato anche in questo caso. Avere un team crossfunzionale e non tagliato sulle linee del singolo progetto ci ha consentito di dividere il team secondo una linea arbitraria, attuando la pratica chiamata shrinking teams nel contesto XP.

Il comportamento emergente successivo alla scelta

La prossima settimana svolgeremo la prima retrospettiva successiva alla nostra mitosi, e rimando a quella le valutazioni sulla nostra efficacia nel rispondere ai problemi di bilanciamento di carico cui intendevamo rispondere. Fin d’ora però voglio notare con te come i due team, partiti da una kanban board unica, con una struttura rivista e rimaneggiata lungo 14 mesi, abbiano in pochissime settimane lasciato evolvere il proprio modo di lavorare in modo indipendente, evoluzione che si riflette nella struttura diversa delle rispettive kanban board, entrambe ormai già diverse da quella unificata originaria.

In questo io sento davvero l’urgenza di fare alcune, poche considerazioni:

1. Sono convinto che questa evoluzione libera, fermi restando lo stretto contatto informale tra i due team e la lenta rotazione dei membri, facendo leva sul principio di diversità porterà grande vantaggio culturale all’interno dell’azienda. Sarà normale essere diversi, sarà normale confrontarsi e sarà normale copiare le soluzioni di maggior successo.
2. Le due kanban board mostrano chiaramente come i colli di bottiglia noti siano finalmente rilassati e questo non fa altro che spostarci verso l’individuazione del prossimo. Questa è l’essenza del kaizen, del miglioramento continuo.
3. Ancora una volta ho ottenuto conferma che la kanban board esprime il massimo della propria efficacia quando è fisica e cheap, quando buttarne la struttura al vento costa il passaggio di un cancellino e due nuovi tratti di pennarello. Scrivere software per simulare una kanban board per un team co-locato non sarà mai più razionale: il costo della modifica della kanban board sarebbe a quel punto un ostacolo al cambiamento libero.

Si pensi che l’idea di rivedere il layout dei due kanban board ideato non è provenuta dal coach o da qualcuno in fissa per l’agile. Chi può a questo punto dubitare che l’esigenza di una nuova kanban board non fosse realmente sentita dal team? Tu?

[...]

Ad occhio mi sembra che “ci siamo”; abbiamo fatto la retrospettiva di gennaio ed abbiamo identificato le cose da migliorare che verificheremo a fine febbraio.
In questi giorni sta cambiando tutto “in tempo reale” (entrano progetti che devono essere consegnati dopo 2 giorni) e, incredibilmente, le persone continuano ad avere il sorriso in viso!

Il cambiamento epocale è stato questo:

prima qualsiasi evento (il cliente è contento, il cliente rompe le palle, c’è una cosa da modificare, etc) era legata all’e-xer [membro del team e-xtrategy, n.d.r.] responsabile del progetto (neanche al team). oggi qualsiasi evento diventa una “cosa di e-xtrategy” a cui dare una priorità e tutti si sbatteranno per portarla avanti prendendosi oneri ed onori.

in passato la telefonata al cliente era una delle cose più critiche. oggi è diventato: “Non riesci a chiamare Tizio? ok, allora lo chiamo io per te!”.

A presto

Miki

Capisci che fare il coach agile e parlare di lean development con persone così coraggiose è il lavoro più bello del mondo?

Miki, ci vediamo presto!

A questi diluitori di significato, ricordo che da queste parti si predilige la collaborazione col cliente piuttosto che stare lì ad aspettare che i contratti vengano impugnati inesorabilmente da una delle parti contro l’altra e che invece sarebbe bene giocare allo stesso tavolo dall’inizio alla fine del progetto senza stare lì a sostituire la voglia di lavorare con deleghe e regolette, perché la prima serve comunque, le seconde non funzionano e le terze nessuno le ha ancora trovate.

La forma mentis è la stessa di chi dice che l’agile tutto sommato è solo buon senso riorganizzato rivelando a chi ascolta solo una grave superficialità nel parlare di una mentalità che offre parecchi punti di vista a volte persino controintuitivi.

Ecco, il buon senso: farebbe bene a farne uso un committente del genere e nel frattempo cercarsi un altro team, un’altra metodologia. Di sicuro un altro coach.

Sono di ritorno da una splendida due giorni passata lavorando con i ragazzi di e-xtrategy pensata per svolgere una retrospettiva su un progetto appena concluso, che ho avuto modo di seguire sin dall’inizio. Inutile dire che l’esperienza è stata formativa per me almeno quanto lo è stata per loro, che mi offrono sempre grande fiducia e libertà di svolgere le nostre analisi, senza sovrastrutture inutili, senza pregiudizi e senza la pretesa di dover nascere imparati, né io né loro.

I topic emersi e sviscerati sono stati diversi e purtroppo qui in questa sede posso solo riassumere i maggiori: kanban, value stream map, automatizzazione dei test e agile ux.

Kanban

Il problema immediatamente emerso dalla retrospettiva è stato quello di gestire le attività dell’azienda che non producono valore diretto per il cliente ma che vanno in ogni caso raccolte, valutate, inserite in una coda di priorità. Per tutti questi task la necessità di un punto di gestione concorrente e la possibilità per lo staff di e-xtrategy di lavorare in uno spazio di aperto e condiviso (elegantissimo peraltro n.d.r.) ha fatto emergere in pochi brevi passaggi l’adozione del kanban. Il kanban, lo scrivo brevemente a beneficio dei neofiti, è sostanzialmente una lavagna dove viene tracciato secondo poche ma ben determinate regole lo stato dei diversi task, abilitando il team ad una modalità di lavoro

1. concorrente, dove sono ridotti al minimo gli stati di attesa per svolgere il proprio lavoro
2. pull, dove si annulla la necessità di una figura responsabile dell’erogazione del lavoro da svolgere
3. trasparente, dove ognuno sa e può sapere cosa sta facendo l’azienda nel suo insieme in un dato momento.

Abbattimento della burocrazia, trasferimento del controllo verso il basso e tracciamento di tutte le attività sono il cuore di questa soluzione.

'Porta' può essere tradotto dal marchigiano in questo contesto come 'Done'

Value stream map

Sempre nell’ottica di individuare con precisione le attività che producono valore diretto per il cliente e distinguerle dalle attività accessorie abbiamo fatto ricorso alla mappatura del flusso del valore, che permette di individuare quali punti del processo ostruiscano la consegna del valore stesso al cliente. Come attività complementare abbiamo stabilito un ranking delle attività interne all’azienda secondo l’importanza percepita dal cliente rispetto al valore consegnato. Questo ranking è stato utile per capire in maniera più oggettiva quali siano le attività su cui cercare di tagliare i costi.

Interessante a dir poco, in un’azienda che passa la gran parte del tempo a scrivere codice PHP per consegnare siti web più o meno complessi, l’attività di scrivere PHP risulta essere fra le meno rilevanti per il cliente finale, quindi fra le meno dense dal punto di vista del valore consegnato. In sostanza una prova a posteriori di quanto sostengo da un bel po’: il codice è un mezzo, mai l’obiettivo.

Automatizzazione dei test

Per stabilire un punto di incontro oggettivo che stabilisca l’impalcatura di lavoro per il maggior numero di persone possibile all’interno dell’azienda si è stabilito di far attecchire i test funzionali una volta per tutte, incarnati da Selenium – nelle sue nuance Selenium RC per PHP e Selenium IDE. Il workflow per ora ipotizzato – perché solo dopo qualche settimana o mese di riscontri se ne potrà stabilire la bontà assoluta e relativa ad e-xtrategy – vede lo specialista XHTML/CSS produrre test funzionali di alto livello basati sui prototipi scritti in XHTML (vedi sotto) usando Selenium IDE – che permette di scrivere i test semplicemente usando il browser -  e poi una serie successiva di raffinamenti nelle fasi di sviluppo in cui i programmatori PHP con Selenium RC possono integrare gli stessi test in PHPUnit.

Interaction design (più) agile

Le intraprendenti decisioni prese dal team e-xtrategy in quei due giorni sono state argomento di discussione anche al di fuori delle mura e-xtrategy con commenti dei soliti noti ad un post di Alberto – Ilaria Mauric compresa, interaction designer di e-xtrategy. L’obiettivo che condivido con il team e-xtrategy in questo frangente è quello di mitigare, se non risolvere, il problema posto dall’integrazione di un team UX con un team di sviluppo. Dopo i primi esperimenti negli anni scorsi, infatti, i principali interaction designer con cui ho collaborato hanno rivisto al ribasso il loro entusiasmo per i metodi agili e si sono arroccati dietro un “per la progettazione il waterfall è inevitabile”, nonostante i pochi esperimenti fatti avessero lasciato soddisfatti tutti i team coinvolti – intesi nel loro senso più eterogeneo. Ovviamente, poi ho capito, per le aziende specializzate in interaction design il discorso ha senso: perché impelagarsi ad integrare il mio metodo con quello di chi sviluppa se il mio business è esclusivamente basato sulla progettazione?

E-xtrategy però presenta una situazione diversa in cui la multidisciplinarietà del team interno è elevata e in cui quindi una metodologia agile integrata ritorna immediatamente di altissimo interesse. Interaction designer, visual designer, sviluppatore XHTML/CSS e sviluppatori PHP, poiché a stretto contatto, possono condividere molto spesso i loro semilavorati e perfino lavorarli in pair cross-funzionali!

Il succo insomma sta nel ridurre al minimo l’approccio fornitore-cliente che vuole – per fare un mero esempio – che l’interaction designer sviluppi un wireframe che poi venga traformato in prototipo che poi venga passato al visual designer che poi passi il template al programmatore XHTML/CSS che poi passerà il lavoro finale alla gente del PHP, in una lunga serie di piccoli waterfall. Con alcuni accorgimenti è possibile circoscrivere molto la necessità di una progettazione upfront: sviluppato un prototipo XHTML molto simile al wireframe, si comincia a scrivere test funzionali per garantire che quel wireframe-ormai-prototipo sia la base di tutto il lavoro successivo per tutto il team. Si fa in modo insomma che il wireframe venga sugellato dai test automatici come il codice eseguibile, con un immenso guadagno sia in termini di formalismi e oggettività – il wireframe esaltato dai test nel suo giusto ruolo di contratto – sia in termini di organizzazione del lavoro – gli sviluppatori e i grafici possono in questo modo lavorare in parallelo sin dalle prime fasi dello sviluppo.

Non mi rimane che ringraziare e-xtrategy per la rinnovata esperienza di coaching e promettere a te di riportare qui la cronaca dei prossimi sviluppi più rilevanti relativamente a tutti questi temi .

Un piccolo gioiello di lavoro concorrente reso possibile da una altissima condivisione di valori, che ha a sua volta permesso – una volta tanto – di dedicarsi fin dal primo secondo alla creazione di valore invece che all’individuazione di un processo per crearlo. Un foglio elettronico online e via, a concentrarsi sugli aspetti linguistici della traduzione, sul core.

Non è stato semplice. Tradurre un documento come il Manifesto Agile, in cui ogni parola ha un peso preciso ed enorme, ti pone continuamente di fronte al compromesso tra fedeltà all’originale e bellezza della forma tradotta. Collaborare con persone tutte di grande consapevolezza, ma culturalmente miste, ha permesso di discutere ogni singola parola problematica e raggiungere sempre un compromesso linguisticamente denso: quella che si dice conoscenza implicita.

Il bello è stato far scorrere questa conoscenza implicita avanti e indietro tra le teste di persone distanti tra loro anche migliaia di chilometri e saper mettere su un processo pragmatico, umilmente efficace. A queste teste lontane ma compatte va il mio grazie.

Nella suite Google Docs infatti è stata recentemente aggiunta Drawing, l’applicazione per creare e modificare diagrammi. Con la consueta grammatica di interazione gli utenti possono condividere i loro diagrammi con altri utenti e collaborare interattivamente sugli stessi diagrammi esattamente come Google Spreadsheet ci aveva già abituato a fare con i fogli elettronici. In pratica abbiamo tutti noi finalmente a disposizione una whiteboard (quasi) gratuita da condividere con chiunque, ovunque ed in qualsiasi momento.

Per me questo rappresenta l’abbattimento di una barriera molto scomoda, vincolante buona parte della mia attività lavorativa. Ogni volta che mi sono trovato costretto a fare una riunione in remoto o a fare pair programming via Skype, è sempre mancata la possibilità di disegnare. Non so tu, ma io quando condivido e discuto concetti al di sopra di una complessità minima ho bisogno di fare schizzi ed esempi grafici. Negli ultimi anni avevo fatto grandi sforzi per ovviare a questa vera e propria amputazione mediatica, sforzandomi di raffinare la capacità di rimuovere le ambiguità dai discorsi e di comunicare in modo più verbale e meno visuale. Lo strumento di Google rende finalmente questa traduzione non necessaria e, soprattutto, non richiede grandi iniziative da parte dei miei clienti: un account Google. Punto. Niente plug-in, niente applicazioni, perfino niente Flash Player!

La conseguenza più importante per tutti di questo lancio è la nuova abilitazione ad un processo di design concorrente, tipicamente desiderato nel contesto lean, poiché concorrenza significa feedback più immediati. D’ora in avanti quindi niente più ostacoli per tracciare un po’ di UML durante un pair programming in remoto, più nessun problema per tracciare semplici grafici durante una conference call e, arrivo a pensare, d’ora in avanti avremo anche aperta la possibilità per i nostri interaction designer di prototipare (parti di) interfacce anche con collaboratori e clienti lontani!

Certo, questo non dovrà mai significare la rinuncia ad ogni tentativo possibile di incontrarsi de visu, e non tanto per un mio inguaribile romanticismo neo-luddista, quanto invece per l’oggettiva qualità della comunicazione fra le persone… di persona! Poi si sa, difficilmente resisterai al fascino di una partita a tris in remoto!

Nel frattempo però per fortuna c’è qualcun altro che scrive in tempi più rapidi. In questo post di Michael Marus sul blog dell’ICT-KM Program (CGIAR) trovi una sua retrospettiva e un mio piccolo intervento. Buona lettura e a prestissimo!

Allora, però, penso anche che Google Wave potrebbe essere un ottimo strumento per gestire progetti se quello che ci interessa è l’aderenza più alta possibile del nostro stile di gestione al Manifesto Agile. Modellare infatti le interazioni fra i componenti umani di un team in modo il più possibile destrutturato – purché aggregato, storicizzato e usabile – mantenendo intatta la possibilità di integrare queste interazioni con informazioni CPU-generated – come i log SVN – credo sia infatti la chiave per un processo sufficientemente asciutto – diremmo lean – per essere adattato ad ogni contesto in modo vincente. Il principio di umanità di cui ho parlato in passato verrebbe sicuramente onorato.

Non so ancora se assocerei una wave ad un intero progetto o una wave ad ogni singola user story. La seconda possibilità mi sembra più promettente; immagino wave che iniziano con la data user story in cui vengono man mano inclusi wireframe, screenshot, user story, commenti, chat e magari un planning game e un log svn con dei plug-in ad hoc… Le possibilità mi sembrano tante, manca qualche riscontro empirico.

Cercherò di fare presto degli esperimenti con i più arditi tra i miei clienti e collaboratori. Appena ne saprò di più ti aggiornerò su queste pagine. Tu nel frattempo non fare il tirchio eh! Se sai qualcosa batti un colpo e facci sapere anche qui!

Voglio condividere però il mio punto di vista, senza dubbio centrato sullo sviluppo agile, nel più ristretto ambito di soli due punti esposti da Nielsen.

Primo punto: risulta che il grado di soddisfazione dei partecipanti allo studio fosse leggermente più alto con metodi meramente iterativi piuttosto che anche agili. Trovo questo dato perfettamente in sintonia con quanto ho affermato più volte quest anno sul tema delle metodologie agili usate insieme allo user centred design. Gli interaction designer mancano ancora delle tecniche, degli strumenti – meno – e dei principi culturali – di più – per avere un approccio al proprio lavoro che li sostenga nell’abbandonare i propri semi-lavorati, i deliverable già creati. Quindi, pur percependo forte il valore dei processi agili, trovano ancora più confortevoli i metodi semplicemente iterativi, i quali, ovviamente, sono vissuti già come rivoluzionari da chi abituato a lavorare waterfall.

Secondo punto:

Developers rated the user experience impact on the deliverable’s quality at 4.3, whereas UX people rated it at 4.0 (again on a 1–5 scale, with 5 best). Developers said productivity increased somewhat with UX involvement (3.3), whereas UX rated this only slightly higher at 3.4.

La mia esperienza di progetti con un forte orientamento all’utente, con specialisti UX inseriti nel team, è stata altrettanto positiva. Io vedo l’attività degli interaction designer come un preziosissimo supporto alla scrittura delle user story e mi fa piacere vedere come questo valore sia percepito dagli sviluppatori in modo perfino più forte che dagli interaction designer stessi!

Ho imparato a ritenere la fase della scrittura delle user story una delle più cruciali – se non la più cruciale – per la buona riuscita di ogni progetto. Sei consapevole del valore di requisiti non solo ben espressi, ma anche già confezionati in un formato che supporti il team nella fase di sviluppo? Ti è chiaro come l’attività centrata sull’utente sia un grimaldello precisissimo per violare la serratura troppo spesso chiusa della riduzione razionale dello scope, del controllo del budget e, in ultima analisi, del successo del tuo progetto?