Crescere da 8 a 33 persone senza perdere il modo di lavorare

EFGC era una startup (ora è una scaleup) che sviluppa una piattaforma per videogame MMORTS online. È nata a febbraio 2019 con una cultura fortemente XP e DevOps, e io sono entrato a settembre 2019 come consulente DevOps. L’obiettivo iniziale era creare pipeline di CI/CD per il deploy in ambienti di staging e demo — all’epoca non c’era ancora nulla in produzione — e aiutare il team a costruire una mentalità portata al feedback continuo.

Da dove partivamo

Il team originale era di 8 persone, oltre a Vitalij — il CTO, una persona con esperienza sul campo — e a me. Era un team giovane, con una forte attenzione alla qualità e al modo di lavorare, ma ancora senza i processi e l’infrastruttura che sostenessero quella cultura. Durante l’autunno è entrato Max, un coach Lean, per affiancarci sulla parte di processo e product management.

Ho stabilmente assunto il ruolo di coach tecnico. Da quel momento il lavoro di governance è stato curato da un gruppo in cui Vitalij portava la visione tecnica e il contesto di prodotto, Max portava il processo e il lean, io portavo le pratiche tecniche, DevOps e qualità del codice. Sono rimasto in EFGC fino al 31 gennaio 2022.

Cosa non funzionava

La sfida non era solo tecnica. Crescevamo velocemente — da 8 a 33 persone in 8 mesi — e l’organizzazione era distribuita su 15 fusi orari, con solo 19 persone co-locate. Avevamo paura di perdere ciò che ci aveva portato fin lì: i valori e i principi Lean, XP e DevOps.

A un certo punto abbiamo provato a scalare Scrum con SAFe. È stata una lezione costosa: il carico di coordinamento è esploso, la visione d’insieme si è persa, i feedback si sono allungati e i difetti o i ritardi di un team bloccavano gli sprint dei team dipendenti. Il problema vero non era lo scaling in sé: era la rigidità delle strutture che stavamo costruendo.

In più, buona parte del mio lavoro era sulle relazioni e sulla comunicazione tra le persone. Non bastava organizzare i team: dovevamo far sì che la crescita non spezzasse il modo in cui quelle persone collaboravano.

Cosa abbiamo fatto

1. Costruire l’infrastruttura del feedback

Sono partito dalle pipeline CI/CD. Il deploy in produzione non esisteva ancora, ma in staging e demo serviva un flusso rapido e affidabile. L’obiettivo non era solo automatizzare: era far sì che il team vedesse il valore del feedback continuo e imparasse a lavorare in quel modo.

In parallelo ho iniziato a fare coaching più ampio su pratiche XP, DevOps e qualità del codice. Non corsi in aula: pair e mob programming, review insieme, problemi reali.

2. Un gruppo di governance aperto

Con Vitalij e Max abbiamo formato il nucleo della governance, ma il gruppo non si è mai limitato a noi tre. Chiunque volesse poteva farne parte: in pratica eravamo in 6 persone. Era un modo per evitare che le decisioni strategiche restassero in una stanza chiusa e per far sentire il team parte del governo dell’azienda, non solo dell’esecuzione.

Vitalij portava la visione tecnica e il contesto di prodotto, Max portava il processo e il lean, io portavo le pratiche tecniche, DevOps e developer experience. Non eravamo consulenti separati: eravamo persone che si assicuravano che modo di lavorare e prodotto crescessero insieme, senza che uno trascinasse l’altro.

La comunicazione verso il resto dell’azienda era trasparente e sincera. Non tutti volevano la responsabilità di far parte della governance, ma apprezzavano che quella porta fosse aperta.

3. Deputy CxO per continuità e cultura

Nel marzo 2020, in piena pandemia, l’azienda ha deciso di rendere i ruoli decisionali resilienti. C’era l’incertezza del COVID-19 e il rischio concreto che figure chiave come il CTO o il CPO fossero temporaneamente fuori gioco. Da lì sono nati i ruoli di Deputy CTO e Deputy CPO: io e Max siamo diventati i fallback rispettivamente di Vitalij e del CPO, formalmente, ma nella pratica i loro pair.

Non era solo una questione di continuità operativa. Diventare Deputy CxO era coerente con la cultura che stavamo costruendo: niente silos, niente persone che detengono informazioni da sole, niente lavoro solitario se poteva essere evitato. Preferivamo pair e mob programming a qualcuno che lavorasse da solo con la responsabilità addosso.

Per me il ruolo è stato anche un’occasione di apprendimento. Vitalij aveva esperienza come CTO e io ho imparato molto facendo pair con lui sulle scelte strategiche, portando il mio punto di vista su pratiche tecniche e DevOps e ricevendone altrettanto sul governo di una startup in crescita.

4. Sperimentare, fallire, riprovare

La prova con SAFe è stata un fallimento utile. Ci ha mostrato che copiare un framework non bastava. Abbiamo deciso di tornare ai principi: XP, Lean, Agile. L’approccio che ne è uscito lo abbiamo chiamato “anarchico” — nel senso di meno governance centrale, non di caos.

Non abbiamo adottato un altro framework al posto di SAFe. Abbiamo costruito il nostro modo di lavorare prendendo spunto da Kanban, Planning Extreme Programming, Software in 30 giorni e The DevOps Handbook, applicando soprattutto i principi sottesi a questi libri e metodologie. Il risultato era un processo su misura, non un’implementazione prefabbricata.

I team non erano più permanenti e in silos: si formavano on-the-fly attorno alle singole attività, si scioglievano quando il lavoro era finito. Avevamo un’unica Kanban board condivisa per bilanciare flussi diversi (Business, Tech, ecc.), stime per taglie (XS-XL), backlog refinement distribuito a tutti, comunicazione prevalentemente asincrona. Il processo era standardizzato ma fluido.

5. Proteggere i valori mentre si cresceva

Il lavoro più difficile è stato sulle persone. Fare in modo che 33 persone distribuite su 15 fusi orari continuassero a sentirsi parte di un unico flusso, senza che la crescita generasse silos o gerarchie rigide. Vitalij, Max e io passavamo molto tempo a osservare come comunicavano, dove si creavano attriti, dove la conoscenza restava intrappolata.

Non ho lavorato molto sul prodotto in prima persona: quando l’ho fatto, è stato in mob. Il mio contributo è stato principalmente sul modo di lavorare e sull’infrastruttura che lo abilitava, in pratica sulla development experience.

6. Tecnologia al servizio del modo di lavorare

Le scelte tecniche seguivano lo stesso principio del resto: niente dogmi, tecnologia adatta al dominio. Abbiamo costruito CI/CD su Jenkins e Spinnaker, sviluppato multi-cloud — poi AWS-centrico — e usato TypeScript e Kotlin come linguaggi principali. Il dominio era diviso in bounded context, ognuno con il proprio micro-servizio, e l’architettura variava da un contesto all’altro in base alle necessità.

L’obiettivo non era avere lo stack più elegante, ma uno stack che il team riuscisse a evolvere senza perdere il controllo. Per questo puntavamo su semplicità, basso carico cognitivo e observability: sapevamo che senza vedere bene cosa succedeva in produzione non avremmo mai potuto fidarci dei rilasci continui.

I dettagli architetturali — come abbiamo organizzato i bounded context, perché in EFGC micro-servizi e in altri contesti monolite modulare, cosa significa davvero “tecnologia adatta al dominio” — li racconto in un articolo a parte, mettendo a confronto EFGC e viteSicure.

7. Test in produzione come feedback, non come sostituto dei test

La piramide dei test era sbilanciata: tanti unit e component test, pochi integration tra micro-servizi e ancor meno E2E, e molta affidabilità data al monitoraggio post-rilascio. Il sistema era complesso: i test E2E non potevano essere affidabili e rappresentativi della reale complessità. Quando una nuova versione andava in produzione, il carico veniva aumentato gradualmente; se le metriche peggioravano, il rollback era automatico. Non era un modo per evitare di testare, ma un modo per apprendere dal sistema reale senza esporre gli utenti a rischi ingiustificati.

Cosa è cambiato

• Crescita gestita: il team è passato da 8 a 33 persone in 8 mesi senza perdere i principi fondanti.
• Abbandono di SAFe: abbiamo sostituito un framework rigido con un approccio basato sui principi, adattato alla realtà dell’azienda.
• Team flessibili: formazione on-the-fly dei team attorno alle attività, invece di silos permanenti.
• Flusso condiviso: un’unica Kanban board per bilanciare stream diversi e mantenere la visione d’insieme.
• Comunicazione asincrona: un modo di lavorare che reggeva la distribuzione su 15 fusi orari.
• Rilasci continui: frequenza di rilascio praticamente continua, con rollback automatico guidato dalle metriche quando le performance o gli errori peggioravano.
• Lead time: in media 4 giorni lavorativi per una nuova funzionalità, con rilasci intermedi; sotto i 2 giorni lavorativi per i bugfix.
• Team soddisfatto: il team apprezzava la flessibilità nell’organizzare il lavoro, la rotazione costante (pair rotation ogni giorno o mezza giornata, cambio completo del team mediamente ogni settimana), la possibilità di toccare tutto il dominio senza silos, il tempo e il budget per studio e formazione.
• Governance aperta: il gruppo decisionale strategico era aperto a chiunque volesse partecipare. Non tutti volevano quella responsabilità, ma apprezzavano che la porta fosse aperta e che la comunicazione fosse trasparente.

Cosa dicono

Gianni evolved from the DevOps expert we called in for pipelines into the guardian of our internal culture, helping us build collaborative governance and communication channels that worked across 15 time zones. He paired with me on strategic decisions and showed us that protecting our way of working required open participation, not rigid frameworks.

Cosa mi ha insegnato

Questa è stata un’esperienza più lunga e diversa dalla partnership di 6 mesi che propongo oggi, ma contiene alcuni principi che poi ho portato nelle collaborazioni successive: la governance condivisa, il pair anche ai ruoli più esperti, la diffidenza verso i framework prefabbricati, l’attenzione alla cultura come prima variabile da curare.

Ho imparato che anche un CTO con esperienza ha bisogno di qualcuno con cui fare pair sulle scelte. E che una cultura XP e DevOps si perde in fretta se non la proteggi mentre l’organizzazione cresce.

Approfondimenti

Sul modo di organizzare il codice intorno al dominio: due storie a confronto.