Siamo fatti così

Molto probabilmente ricorderai dai tempi della scuola il concetto di mitosi, quello per cui la cellula, raggiunto un certo stadio del suo ciclo di vita e un certo accrescimento, si divide in due cellule figlie duplicando perfettamente il proprio patrimonio genetico e assegnando ad entrambe grosso modo lo stesso numero di risorse.
Se non ricordi la lezione di scienze a scuola forse ricorderai il fatidico momento ricorrente nella serie animata Siamo fatti così in cui i globuli bianchi rispondevano ad un’infezione duplicando rapidamente l’organico di truppe disponibili. Nelle ultime retrospettive in ideato si è pensato di ricorrere allo stesso meccanismo per rispondere agli inconvenienti della crescita: comunicazione più complessa, gestione lenta della conoscenza e colli di bottiglia nel processo a monte del team di programmatori. E così ora ideato si ritrova con due team grandi la metà di quello originale.

Siamo fatti così

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?

September 23 2011 05:26 pm | Dalle trincee

8 Responses to “Siamo fatti così”

  1. Davide 'Folletto' Casali on 23 Sep 2011 at 18:53 #

    Ok, ma c’è una unità minima di kanban che è “fissa” in una certa misura: i cartellini e uno spazio bidimensionale, no? La prima app che ti fornirà quello credo che sarà molto più vicina alla flessibilità che cerchi… ma distribuita.

    Io credo che in realtà il problema non sia nel digitale in quanto constraint, ma nel digitale in quanto screen estate: una whiteboard vincerà fino a quando non potrò avere uno schermo equivalente, in cui abbia la stessa visibilità degli elementi e la stessa possibilità di zoom in / out.

    Che ne pensi? :)

  2. Jacopo Romei on 26 Sep 2011 at 02:22 #

    Dico già da anni, in accordo con te, che un bel touch screen da 70″ sarebbe una manna, ma…

    ma tutta questa attenzione sullo strumento è sbagliata.

  3. Giorgio Sironi on 26 Sep 2011 at 14:45 #

    Parlando di teoria dei vincoli, cosa vi ha spinto a dividere i team invece di mettere due persone a fare il Service Owner (essendo lì il collo di bottiglia)?

  4. Jacopo Romei on 26 Sep 2011 at 15:27 #

    Alcune considerazioni che seguono qui in ordine sparso e senza pretesa di completezza:

    - Il service owner per me è un’aberrazione. Se posso avere un team che riesce a rimanere in contatto diretto con i clienti senza diaframmi lo preferisco.

    - La pianificazione richiede know-how e serve a costruire know how: in un team piccolo la conoscenza di progetto aumenta più rapidamente e la pianificazione può coinvolgere tutto il team senza a) fermare tutta l’azienda b) creare problemi di gestione delle sessioni di pianificazione.

    - Un nuovo service owner avrebbe richiesto o una nuova assunzione o il “prelievo coatto” di uno degli sviluppatori. Adesso abbiamo uno sviluppatore con un sacco di consapevolezza del rapporto con i clienti.

  5. Alessandro Nadalin on 26 Sep 2011 at 15:40 #

    Contento che il service owner, come figura, sia quasi sparito. Sai bene come la penso.

    Una considerazione spicciola: avere 2 team, invece che uno, aumenta la competizione sana (dato che ci si conosce tutti benissimo :) ) tra i team, per cui immagino anche gli stimoli delle persone accrescano.

  6. Fabio Armani on 26 Sep 2011 at 22:36 #

    Caro Jacopo, quella da te descritta (devo dire in modo esemplare, anche se poco
    sintetico) e’ semplicemente una delle più note tecniche di diffusione dell’Agile nelle aziende.

    Come dite voi in Ideato? Io dico ‘mitopoiesi’ ;) e dato che questa sta alla base della duplicazione delle cellule e quindi della crescita, auguro a te e a tutta Ideato di continuare a crescere e a farlo duplicando il vostro DNA.

    Ciao Fa

  7. Fabio Tarantino on 11 Oct 2011 at 10:52 #

    Ciao Jacopo,
    da quello che ho capito avete messo in piedi una struttura organizzativa matriciale.

    Che ne pensi invece delle strutture organizzative reticolari (ad esempio la spaghetti organization), in cui non esistono organigrammi o gerarchie strette mentre i progetti e gli individui che ne fanno parte sono al centro di tutto?

    ben si adatta allo sviluppo agile?

    grazie,
    Fabio

  8. Jacopo Romei on 11 Oct 2011 at 11:12 #

    A beneficio dei lettori:
    http://it.wikipedia.org/wiki/Organizzazione_aziendale#Macrostruttura_a_matrice

    Un impianto matriciale implica almeno la separazione tra uno strato manageriale e uno esecutivo. Ideato non vive questa separazione. La suddivisione che ho descritto riguarda l’intero processo; ogni team incorpora capacità di pianificazione e di autogestione. A dimostrazione ulteriore della forte adesione ad un modello non gerarchico (quale invece la struttura a matrice è) è il fatto che ognuno dei team sarà presto messo alla luce di tutte le informazioni sui budget per consentire il massimo trasferimento possibile delle decisioni verso i singoli. Ma questo è tema per un post prossimo futuro. ;-)

Trackback URI | Comments RSS

Leave a Reply