Il nostro ciclo di sviluppo è estremamente veloce e abbiamo costruito strumenti per mantenerlo così. E’ normale scrivere codice e averlo in produzione pochi giorni dopo. Questa è una piacevole sorpresa per gli ingegneri che hanno lavorato in altre aziende dove il codice ci mette mesi o anni a vedere la luce del giorno. Se lavori con noi, potrai avere un impatto immediato.(*)

Hai notato? “Pochi giorni dopo”, “piacevole sorpresa”, “impatto immediato“. Perché loro sì e tu no?

“Eh ma da noi è diverso!”.

Ne sono convinto: quella differenza la stai facendo anche tu.

Lo scorso ottobre sono stato invitato come speaker alla PHPNW 2011, dove ho tenuto il talk intitolato Many to many – No man is an island. Si parla di comunità, di nerd, di social skill e di incidenti aerei. La registrazione è buona; il talk spero.

Buona visione!

http://blip.tv/phpnw/phpnw11-jacopo-romei-many-to-many-no-man-is-an-island-5860230

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?

Il pensiero di assunto da Cravera nella sua critica è quello di Womack per cui

Per usare le parole dello stesso Womack, il lean thinking è “un modo per fare sempre di più consumando sempre di meno”.

e da questa considerazione Cravera fa conseguire una riflessione sui rischi che il lean thinking comporta quando eventuali ridondanze vengono eliminate in nome della riduzione degli sprechi. Riflessione, questa, legittima perché effettivamente la riduzione tout court di ogni ridondanza è effettivamente a rischio di subottimizzazione, quella condizione in cui un ottimo locale può inficiare la prestazione globale di un sistema. Effettivamente lo scenario dello sviluppo di prodotti può fare tesoro di alcune ridondanze – basti pensare alla creazione di più ipotesi di interfaccia utente,  per fare un esempio banalissimo.  Quello che della riflessione non va, se vogliamo legarla ad una critica sana del lean, è l’assunto che il lean thinking sia devoto e prono alla subottimizzazione quando è assolutamente il contrario!

Nel Lean Primer di Craig Larman e Bas Vodde, la cui lettura consiglio a tutti gli interessati al pensiero lean, gli autori liquidano il punto di vista di Cravera già nella prima pagina (!) con questa considerazione che io riporto,  tradotta da me:

L’immagine e la metafora con cui vorremmo porre l’accento su un errore – ed un’opportunità – chiave è la staffetta.

Considera i podisti di una staffetta in attesa del testimone da parte dei loro compagni di squadra. L’account manager, inorridito da questo spreco da sottoimpiego indicato in qualche report, probabilmente definirebbe una nuova policy con l’obiettivo “dell’impiego al 95% delle risorse” per assicurare che tutti gli staffettisti abbiano da fare e siano produttivi. Forse – suggerirebbe – gli staffettisti potrebbero correre tre staffette contemporaneamente per incrementare l’occupazione delle risorse. [...]

Divertente… ma questo tipo di ragionamento è più tipico del management e dei processi tradizionali nello sviluppo e in altri domini. Invece, per contrasto, ecco l’idea alla base del lean thinking:

Tieni d’occhio il testimone, non gli staffettisti

Già traspare quindi il grave vizio di sostanza dell’ emerso – non capisco se solo per citazione o per effettivo sposalizio – nell’articolo di Cravera: guarda all’approccio lean attraverso le lenti dei processi classici e ne analizza l’eventuale risultato, ormai però distorto. Non mi dilungo oltre: se ti interessa il pensiero lean leggi l’articolo di Cravera con attenzione. Poi leggi quello di Larman e Vodde per capirlo davvero.

1. Domani sarò al jsDay dove potremo apprezzare lo stato dell’arte del know-how Javascript e delle tecnologie a contorno. Trovo sia un bell’evento, considerato che è il primo in Italia nel suo genere e con un’ottima line up fin da questa prima edizione.
2. Da giovedì sarò al phpDay dove avrò l’onore ed il piacere di presentare il keynote venerdì, intitolato Many to many: no man is an island. Tratterò il tema particolarmente importante delle community e dello sviluppo della competenza.
3. Oggi mi trovo a Madrid, dove stasera si terrà il primo ALE Gathering al termine della prima giornata di XP 2011. Si tratta di un neonato network europeo centrato sulla diffusione dei valori agili e lean nello sviluppo del software. L’obiettivo di stasera sarà quello di settare la vision del network. Sarà divertente perché, mentre la delegazione italiana sarà ben rappresentata, io mi sono offerto per rappresentare la comunità bulgara, impossibilitata ad inviare dei propri delegati. Se non è networking questo…

Questo post è solo il pretesto per farti presente dell’esistenza del mio nuovo blog che, lungi dall’essere sostitutivo di questo in italiano, ne sarà invece la ormai dovuta integrazione, rivolta allo scenario internazionale dei metodi agili e dei processi lean. Se apprezzi questo blog di tanto in tanto ci sono buone probabilità che leggerai volentieri anche Thoughts of a strange loop. Ciao!

In economia esiste il concetto di isoquanto, ovvero

l’insieme delle combinazioni efficienti di input che forniscono lo stesso livello di produzione.

Questa arcana formula equivale a dire che più di una combinazione di ingredienti potrà darmi lo stesso risultato valido. Un esempio classico è quello del rapporto tra lavoro e capitale: fermo restando l’obiettivo di una start-up (il nostro output), se ho molto capitale e poco know-how potrò finanziarne una senza scrivere una riga di codice – il concetto di venture capital; se ho invece molto know-how e poco capitale potrò chiudermi in un garage tutte le notti e lanciarmi nell’impresa nerd.
Per opportune coppie capitale/know-how le chance di successo saranno le stesse e queste, in un diagramma cartesiano, saranno disposte lungo linee continue.

Isoquanti (fonte Wikipedia)

Un concetto simile esiste in fotografia: date certe condizioni di luce, sulla carta infinite coppie tempo di scatto/apertura diaframma mi garantiscono una corretta esposizione del fotogramma. Potrò chiudere il diaframma ed esporre per tempi più lunghi o potrò aprire il diaframma ed esporre per tempi più brevi.
Anche in un diagramma tempo-apertura perciò tutte le coppie accettabili saranno disposte lungo una linea continua. Ognuna di quelle linee corrisponderà ad un valore ISO della pellicola e sarà analoga all’isoquanto (hai notato qualcosa?) di cui sopra.

Cosa cambia di isoquanto in isoquanto? E di in ISO in ISO?

Banale ed intuitivo: se io posso disporre dello stesso know-how e di più capitale di un concorrente, avrò, ceteris paribus più chance di successo; se io posso disporre di un sensor… ehm di una pellicola caratterizzata da maggiori ISO, avrò, in condizioni per esempio di scarsa illuminazione, la possibilità di usare tempi di esposizione rapidi a parità di apertura diaframma, evitando un indesiderato effetto mosso.

Bene. E la competenza?

Si parla spesso di scegliere nel design del software fra una soluzione quick & dirty e soluzioni più “lente” ma più pulite. Se ne parla sempre. Se ne parla troppo. Il compromesso che si stabilisce è fra la massimizzazione del lavoro non svolto oggi e quello non svolto domani, tra 3 mesi o tra un anno. È possibile però ipotizzare l’esistenza di uno sviluppatore molto bravo che riesca a trovare una soluzione gagliarda oggi e facilmente estendibile in futuro, riuscendo quindi ad operare scelte win-win che trascendano il compromesso apparentemente inevitabile.

Un trade-off spinoso: semplicità a breve termine vs. a lungo termine.

Il diagramma qui sopra spero sia sufficientemente chiaro da farti afferrare che a parità di lavoro non svolto nel futuro – il nostro A, la competenza può farci saltare da una linea all’altra (le linee di isocompetenza? ) permettendoci di raggiungere i livelli crescenti B’, B” e B”’ di semplicità sul breve termine, salvando capra e cavoli.

Ipotizzare l’esistenza di uno sviluppatore molto bravo è utile ai fini di questo post. Diventarlo, una missione impossibile. La parola d’ordine è competenza, la sua espressione più diretta il refactoring.

[...]

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!

Non esiste alcuna prova che una persona in un team di sviluppo software sia più produttivo lavorando 70-80 ore la settimana invece che 40. Citando Kent Beck

Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.

E’ già molto facile rimuovere valore da un progetto su cui stiamo lavorando in condizioni normali – per esempio introducendo debito tecnico, ma se siamo stanchi allora il problema diventa accorgersi che stiamo rimuovendo valore. E allora diventa anche interesse del datore di lavoro quello di garantire la sostenibilità ad libitum del proprio processo di sviluppo. Perché

1. Suo interesse è poter pianificare e per pianificare c’è bisogno di affidabilità.
2. Suo interesse è consegnare valore una volta per tutte, user story dopo user story, senza doverci ritornare per qualche disattenzione.
3. Suo interesse è preservare l’integrità del team nel tempo, considerato il valore inestimabile che la seniority ha nel nostro mercato.

Certo, se poi il meccanismo in cui si incappa è banalmente quello di accettare stipendi di qualche punto percentuale sopra la media per lavorare il doppio 30% in più del tempo, allora siamo di fronte ad una raffinata truffa e l’interesse nel lavoro sostenibile diventa tutto dello sviluppatore. Ma a giudicare dalla salubrità del mondo IT in Italia e in Europa, sembra proprio che certe catene siano ancora invisibili agli occhi degli incatenati.

A mio avviso, l’autore del post commette la gravissima ingenuità di non tenere conto del concetto di project velocity o forse la concepisce – come spesso mi capita di ascoltare – solo in modo prospettivo:

Quanti punti facciamo la prossima settimana?

E basta.

In realtà almeno metà del senso della project velocity è retrospettivo:

Per garantire la qualità necessaria – test compresi, tutti: da unit test a test sugli utenti – la scorsa iterazione siamo stati capaci di “bruciare” 7 punti. Ne avevamo pianificati 18, ma evidentemente con tutti i test siamo riusciti a fare 7. Bene la prossima iterazione pianificheremo 7.

Ovviamente a prima vista questo significa rallentare. Perlomeno non meno che fare un’iterazione solo per fare test, come suggerisce l’autore. Tuttavia gli approcci sono ben lungi dall’essere equivalenti, perché in quello proposto nel post otteniamo feedback con minor frequenza, garantendoci solo una cosa: l’aumento delle chance di lavorare su un sistema che non rispecchia più la realtà dei fatti. Fatto che significa

1. non risolvere i problemi realmente emersi, ma problemi già vecchi.
2. spendere effort e quindi denaro su falsi problemi, pagando elevati costi opportunità.

Tutto sta nel tenere bassi i costi della contemporaneità, della coesistenza della fase di sviluppo e di test. Non per tutti i professionisti attorno allo sviluppo del software è, ad oggi, altrettanto facile. In ambiti come la progettazione UX per esempio i dibattiti sono ancora vivaci e dall’esito poco chiaro. Per gli sviluppatori però ormai ci sono tecniche e strumenti maturi. Basta solo la voglia.