Da qualche mese in Finanz rilasciamo una build a settimana.

Prima ne uscivano una ogni 30-60 giorni. Il percorso da un numero all'altro è cominciato quando eravamo in tre e gli utenti erano 40.000, e non l'ho raccontato mentre succedeva.

Ne scrivo adesso, e la distanza è il punto.

A caldo ogni processo appena introdotto sembra funzionare: c'è l'entusiasmo della novità, c'è chi lo segue perché è nuovo, e non hai ancora incontrato la settimana storta che lo mette alla prova. Un metodo raccontato il giorno dopo l'introduzione non è un risultato. È un annuncio.

Nel frattempo gli utenti sono diventati 200.000. Quel numero non l'ha portato il team dev — l'hanno portato acquisition e prodotto, con un lavoro che sta a monte del codice. Il team dev ha fatto una cosa diversa: ha retto senza rompersi mentre il carico si moltiplicava per cinque.

Ed è questa la ragione per cui lo metto per iscritto proprio ora. Stiamo crescendo, e la fase che viene chiederà al team di reggere un altro salto. Un metodo lo guardi prima che serva, non dopo che si è rotto.

Guardando indietro, il collo di bottiglia non è mai stato il codice. Era che nessuno sapeva cosa stesse facendo l'altro.

Qui sotto ci sono gli strati che hanno prodotto quella build settimanale, nell'ordine in cui sono arrivati, e il conto che ho pagato per ognuno. L'ordine sembrava improvvisazione mentre lo vivevo. Solo da fermo si legge per quello che era.

Tre persone e nessun protocollo

Lo stato zero, senza sconti.

Nessun metodo di sviluppo. Nessuna gestione delle feature: si prendeva quello che urgeva di più quel giorno. Nessuna stima, quindi nessuna tempistica da dare a nessuno. Nessuna definizione di finito.

E sopra tutto, il problema che li generava tutti: nessuna comunicazione. Non fra prodotto e dev. Nemmeno fra dev e dev.

Tre persone che aprivano tre branch senza sapere che quei tre branch toccavano gli stessi file.

Va detta una cosa scomoda: a 40.000 utenti funzionava.

Con quel volume le segnalazioni sono poche, le feature richieste sono poche, la superficie da tenere in piedi è piccola. Tre persone che si parlano per caso bastano. Il caos non si vede perché non ha abbastanza carico addosso per manifestarsi.

È esattamente per questo che il processo arriva sempre tardi. Nessuno lo introduce mentre funziona.

Cosa rompono 160.000 utenti in più

Con 5x utenti la superficie cresce lineare: 5x segnalazioni, più feature richieste, più casi limite, più device su cui il bug esiste solo lì.

Il costo di coordinamento no. Quello cresce sul numero di persone che devono sapere una cosa, moltiplicato per il numero di cose da sapere.

Tre dev con dieci feature in volo non sono tre dev con due feature in volo moltiplicati per cinque. Sono un'altra cosa.

Il primo sintomo non è un bug. È il riallineamento: mezza giornata a fare merge di roba che qualcun altro ha toccato nel frattempo, per arrivare a un branch che ieri era già a posto.

La soluzione perfetta esiste ed è scritta in ogni manuale. Assumi. Definisci i ruoli. Installi Scrum per intero: backlog groomato, definition of done, planning, retrospettiva, velocity.

In una startup, a quel punto, costa tre cose che non hai:

  • il tempo di scrivere il processo mentre stai già spedendo
  • persone nuove da onboardare su un metodo che ancora non esiste
  • l'adesione di un team che non ha mai lavorato così

Il conto vero è il terzo. Un processo calato tutto insieme su tre persone non viene adottato: viene subito. E un processo subito lo aggiri il primo giorno che hai fretta.

Il mandato me l'ha dato Lorenzo Perotta, e la consegna era una riga: cambia il team dev. Non "installa Scrum".

Roma non si costruisce in un giorno. Nemmeno un metodo.

Il vincolo che ha deciso tutto: nessuno ha un orario

Finanz è una startup e non ha mai avuto orari rigidi. Non li ha nemmeno oggi. Ognuno lavora quando rende.

Questa non è una nota di colore. È il vincolo di progetto, e ha deciso la forma di ogni strato successivo.

Se le persone non sono online nelle stesse ore, ogni processo sincrono che aggiungi è un dazio: qualcuno smette di fare quello che stava facendo per essere presente a un orario che non è il suo.

Quindi il primo strato non poteva essere una riunione. Doveva essere asincrono per forza.

E il problema da attaccare per primo non era la stima, non era il backlog, non era la velocity.

Era che nessuno sapeva cosa stesse facendo l'altro.

Strato uno: il Loom quotidiano

Ogni giorno un Loom. Due cose dentro: cosa ho fatto, cosa farò.

Niente slide, niente formato, niente durata minima. Un video registrato quando ti pare, guardato quando ti pare.

È il processo più piccolo che risolve il problema più grosso: rende visibile lo stato del lavoro senza chiedere a nessuno di essere in un posto a un'ora.

Non fingo che sia stato rispettato al 100%. C'è chi lo ha mandato ogni giorno e chi no, e ci sono state settimane vuote. Discuterne serve poco, perché il punto non era la compliance.

Il punto era che dopo il Loom "non lo sapevo" ha smesso di essere una risposta accettabile.

Trade-off, dichiarato: il Loom comunica, non coordina.

Ti dice cosa sta facendo l'altro. Non ti dice se è la cosa giusta da fare, non ordina le priorità, non produce una data. Sapere che tre persone stanno lavorando su tre cose scollegate è meglio che non saperlo. Non è ancora un metodo.

Strato due: sprint di due settimane

Sopra la visibilità ho messo il contenitore: sprint di due settimane.

Scrum nella forma minima. Attività assegnate allo sprint, obiettivi dichiarati all'inizio — esce la feature X, esce la feature Y — e una finestra chiusa dentro cui stanno.

Non il manuale. Niente retrospettive formali all'inizio, niente ruoli certificati, nessuna cerimonia che non risolvesse un problema che avevamo davvero in quel momento.

Graduale, di nuovo. Un pezzo per volta è l'unica cosa che ha funzionato in tutta questa storia.

Cosa ha risolto: la domanda "quando esce" ha smesso di avere come risposta un'alzata di spalle. Prodotto ha avuto una finestra a cui appoggiarsi, e quella finestra ha reso discutibile la priorità — se la feature X è dentro, qualcos'altro è fuori, e adesso è una decisione, non un caso.

Cosa ha rotto: lo sprint ha reso evidente che non avevamo modo di dire se fosse pieno o vuoto.

Mettevamo dentro cinque attività. A volte finivano in tre giorni. A volte non finivano in due settimane. Senza un'unità di misura, uno sprint è un contenitore di cui non conosci la capienza, e la pianificazione resta una scommessa fatta con più cerimonia di prima.

Ci torno più avanti, perché è il pezzo che apre l'articolo successivo.

Strato tre: dal daily Loom al daily meet

A un certo punto il Loom asincrono ha smesso di bastare, e l'ho tolto.

Non perché fosse sbagliato. Perché il problema era cambiato sotto.

Con gli sprint attivi nessuno aveva più bisogno di un video per sapere cosa faceva l'altro: quello sta nello sprint, è scritto, si legge. Il bisogno era diventato un altro — sbloccarsi. Una decisione che aspetta, un dubbio su un contratto API, chi tocca per primo quel file.

Quella roba, in asincrono, costa un giro di ping-pong da 24 ore. Con sprint di due settimane, due giri sono il 15% dello sprint bruciato ad aspettare.

Quindi un punto di incontro al giorno. Corto. E non un reporting: ci si va con i problemi, non con l'elenco di quello che si è fatto.

Ho pagato il dazio del sincrono in un'azienda senza orari, e l'ho pagato sapendo cosa compravo. Lo sblocco vale un'ora scelta da qualcun altro. Il reporting no: quello resta asincrono per sempre.

La metrica che contava davvero era la build

Tutto quello che sta sopra ha migliorato la vita del team. Non aveva ancora toccato l'utente.

L'utente non vede il tuo sprint. Non vede il tuo daily. Non vede la tua board.

Vede la build.

Prima: una build al mese, a volte una ogni due. Un utente che segnalava un problema poteva aspettare 60 giorni per vedere il fix, con il fix mergiato da 55.

Il valore restava fermo in un branch. Scritto, revisionato, testato, e invisibile.

Con gli sprint attivi l'obiettivo è diventato esplicito: almeno una build al mese. Poi, subito dopo, la regola vera — una build per sprint.

Una a sprint, con sprint di due settimane, fa una ogni 14 giorni. Da 60 a 14 è già 4x, ed è arrivato senza toccare la pipeline.

Ma sotto i 14 non si scendeva. E il motivo non era il rilascio.

Sprint a una settimana: la mossa contro-intuitiva

Il consenso dice che accorciare lo sprint aumenta l'overhead. Più planning, più chiusure, più cerimonia distribuita sullo stesso lavoro.

Ho fatto il contrario. Sprint dimezzato a una settimana.

Il costo che pagavamo non era la cerimonia. Era la vita media di un branch.

Con sprint di due settimane un branch resta aperto fino a due settimane. Nel frattempo altri branch toccano gli stessi file. Al momento di chiudere, il lavoro di riallineamento non è proporzionale al numero di branch aperti: è proporzionale a quanto a lungo sono rimasti divergenti. Due settimane di divergenza si pagano tutte insieme, il giorno in cui devi far uscire la build.

Dimezzare lo sprint dimezza la finestra di divergenza. E fa una seconda cosa, che conta di più: costringe a tagliare le feature più piccole, perché in una settimana una feature grossa non ci sta.

Feature più piccole, branch più corti, merge più frequenti e più leggeri, meno riallineamenti fatti tutti insieme sotto scadenza.

La regola di prima è rimasta la stessa — una build per sprint. Siccome adesso lo sprint è una settimana, rilasciamo una build a settimana.

Da una ogni 30-60 giorni a una ogni 7. Senza assumere nessuno: il team è quello.

Non è gratis. Una settimana è una finestra rigida, e una feature che non ci sta va spezzata a mano in pezzi che abbiano senso da soli, rilasciabili senza rompere niente. Non tutte si lasciano spezzare bene, e quella parte è ancora lavoro di testa ogni volta.

Quello che qui resta aperto: story point e KPI

Manca il pezzo che ho lasciato indietro due volte, ed è voluto.

Abbassare lo sprint a una settimana ha funzionato perché nel frattempo era arrivata la parte numerica: story point sulle attività, metriche sullo sprint, KPI sul team dev. Senza quella non avrei potuto dire se una settimana fosse una finestra sostenibile o soltanto una finestra più corta.

Non lo chiudo qui, perché è un articolo intero e non un paragrafo: quali metriche traccio davvero, quali ho provato e buttato, e perché la velocity da sola dice molto meno di quanto sembri.

Prossimo pezzo.

Il principio

Nessuno di questi strati era nel piano iniziale. Non c'era un piano iniziale.

Il Loom è nato perché mancava la comunicazione. Gli sprint sono nati perché il Loom non coordinava. Il daily meet è nato perché gli sprint avevano reso il Loom ridondante. Lo sprint a una settimana è nato perché la build restava ferma.

Ogni strato esiste per risolvere il problema che ha creato quello prima. È l'unico ordine in cui potevano arrivare, ed è leggibile solo guardando indietro.

Il metodo non si progetta. Si stratifica.

Se stai per installare un processo intero in un team che non ne ha mai avuto uno, la domanda giusta non è quale framework. È quale singolo problema fa più male oggi, e qual è la cosa più piccola che lo toglie.

Poi aspetti. Perché un metodo lo giudichi dai mesi che sopravvive, non dalla settimana in cui lo introduci — e questi mesi ormai ci sono.

La domanda aperta è un'altra, ed è il motivo per cui ho rimesso tutto in fila: questi strati reggono il prossimo 5x, o il primo a cedere sarà la finestra da una settimana?