Scaling Agile: che cosa si intende, e quali sono gli impedimenti

18 Febbraio 2020 - 4 minuti di lettura

La crescita veloce è uno degli aspetti più rilevanti dell’economia negli ultimi anni.
Le aziende “pre native digitali” stanno guardando a startup, scaleup e unicorni come a potenziali (o reali) competitor e si stanno organizzando per scalare.
Brevemente:

scaleup: Una startup ad alto valore innovativo che attraversa una fase di crescita in termini di dimensioni, fatturato e investimenti e che si sta espandendo all’estero tramite partnership strategiche con grandi aziende.
Unicorno: azienda non ancora quotata in borsa che ha raggiunto in un breve periodo una valutazione di mercato di almeno un miliardo di dollari.

Un conto però è avere una struttura di business nata per scalare, un conto è scalare con un business avviato da almeno 20/30 anni.
Cultura aziendale, sistemi IT e tecnologie si sono stratificati nel tempo e possono essere un ostacolo a questa corsa verso l’alto.

Questo articolo è un riassunto dell’intervento di Giulio Roggero durante la conferenza Agile Venture Milano.

Tre dimensioni di scaling

Cloud native

Nel tempo il numero di clienti cresce e insorge la necessità di scalare il servizio. Si va quindi nel cloud.
Che caratteristiche ha un servizio?

Può evolvere nel tempo.
Potrebbe essere poliglotta, tecnologicamente parlando.
Evolve con l’evoluzione del business.

Pensare ad una architettura a microservizi potrebbe essere una buona soluzione, perché è aperta all’evoluzione.
Questi nuovi sistemi composti da tanti piccoli servizi vanno governati, qualora non lo si facesse sarebbe un bel problema. Ecco dunque che il binomio Agile + devOps è da considerare in quanto porterebbe come dote dei principi base e regole da seguire.

Data mesh

Sempre più utenti utilizzano i prodotti o meglio i servizi. E inevitabilmente vengono generati ed accumulati molti dati. Bisogna pensare ad una strategia per questi dati.
Sarebbe utile avere tutti i dati in un unico posto, sempre verificabili e veri.
Sulla carta sembrerebbe una buona idea, ma come gestiamo la variabile tempo? Con il tempo i dati potrebbero perdere di valore. Si avrebbero dunque dei monoliti di dati, come i già noti monoliti software. Più che centralizzare il dato, occorrerebbe centralizzare la struttura.

Agile scaling

Con l’evoluzione delle tecnologie evolvono i servizi, che sono sempre più complessi.
Per un team quindi cresce inevitabilmente il numero di User Story.

Come si potrebbe scalare un team? Si potesse evitare sarebbe meglio, ma oggigiorno esistono framework, come LeSS o SAFe, che se ben applicati (e non il classico copia-e-incolla, noto anti-pattern) non possono che portare benefici.

Cosa impedisce lo scaling?

Che succede nel caso in cui ho un software architetturalmente organizzato a microservizi ma gestito da una struttura aziendale monolitica? O viceversa.
Lo scaling non avrebbe senso.

Giulio suggerisce di trasformarsi in modo continuo. Non fermarsi mai, pena il rischio di ricadere nel legacy. Sia a livello strutturale che software.

Il monolite software è ciò che blocca lo scaling a livello cloud native, perché:

Farlo scalare richiede potenza computazionale.
E’ vincolato tecnologicamente. Magari si ha un software ben progettato ed implementato, ma legato a tecnologie obsolete.
Comporterebbe rilasci complessi nonché lenti.

I silos invece impediscono l’Agile scaling.
Per silos si intende quelle persone in azienda che sì hanno la conoscenza, ma dal momento che hanno faticato anni per ottenerla, se la tengono ben stretta.
Ad esempio, gli sviluppatori che per anni hanno lavorato sempre sullo stessa applicazione, quindi solo loro sanno dove e come mettere mano al codice.
Una sorta di conoscenza tacita: pochi lo sanno, e se lo tengono stretto. I guardiani del castello, per intenderci.
Persone che si barricano nel loro castello di conoscenza, e non permettono a nessuno di entrare.

Come scalare il legacy?

Per ognuna delle tre dimensioni, Giulio suggerisce come poter scalare:

Cloud native: da monolite ad architetture che evolvono, come ad esempio architetture a microservizi. Abbracciare la cultura devOps.
Agile scaling: demolire i silos. Abbandonare la cultura del “Noi e loro” che rallenta le decisioni. Riorganizzarsi ed allinearsi con le esigenze del cliente finale.
Data mesh: da tanti dati magari storicizzati in più posti, inconsistenti e poco chiari, a data stream. Si pensi ad un fiume, i dati si trovano in un unico posto e fluiscono. Organizzare una struttura che usi il dato che è più utile al momento, quindi non storicizzare tutto.

Come esempio Giulio ha portato il percorso che MIA-platform sta attuando per scalare al meglio in modo Agile.

Qui potete consultare le slide dell’intervento.