La domanda piu importante sulla scalabilita Agile
Sentiamo da quasi tutte le grandi aziende con cui lavoriamo: “Abbiamo bisogno di un framework di scalabilità agile.” Quando 50 o più sviluppatori devono collaborare, usare un framework di scalabilità è effettivamente vantaggioso. Ma una domanda rimane senza risposta. Un'assunzione non detta e non messa in discussione aleggia come uno spettro su qualsiasi approccio di scalabilità. Ma prima di porre questa domanda, diamo un'occhiata alle ragioni per cui questa domanda deve avere una risposta.
Sviluppare un prodotto complesso
I sistemi complessi sono complessi – se non altro per definizione. Un'assunzione comune è che Divide+Conquer (D+C) sia un buon approccio per risolvere problemi complessi: dividiamo un grande problema in tanti piccoli, li distribuiamo e riassembliamo le soluzioni. Anche questo suona promettente.
Un framework di scalabilità può quindi essere usato per massimizzare l'efficacia del D+C.
Partiamo dalle domande periferiche per avvicinarci alla domanda centrale:
Come definire il problema?
Quando inizi a sviluppare un grande prodotto, hai prima un bisogno – e vuoi costruire un prodotto che soddisfi quel bisogno. La natura dello sviluppo prodotto è che la soluzione basata sul bisogno non esiste ancora.
Il problema è descritto correttamente? È già sufficientemente chiaro dove va lo sforzo? Il dominio della sfida è già così chiaro che il D+C può essere applicato in modo sensato?
Qual è il vero problema?
Quando organizzi lo sviluppo prodotto, assumi semplicemente che il bisogno sia chiaramente definito e il resto sia “solo lavoro”.
Ma cosa succede se anche la domanda sulla base della quale è stata fatta la pianificazione era già sbagliata? Cosa succede se il piano fallisce e persegui la risposta sbagliata? Aiuta se più persone lavorano sulle cose sbagliate?
Dove si trova il vero problema?
L'assunzione di base della scalabilità agile: “Il problema principale è che c'è più lavoro di quello che poche persone possono fare.” Come descritto anche in un altro articolo, il problema principale con molto lavoro è che molto lavoro causa molto lavoro! Questo riguarda il lavoro non a valore aggiunto come coordinamento, cambio di attività, riunioni e simili.
Hai mai pensato a quanto sia grande la quota di lavoro a valore aggiunto sul prodotto rispetto alla quota di lavoro non a valore aggiunto sui processi nella tua organizzazione? Quanto tempo hanno bisogno i tuoi sviluppatori per il coordinamento a causa della complessità delle tue strutture? Il tuo focus è sulla consegna di prodotti o sul seguire i processi? Cosa succede all'overhead quando estendi i tuoi processi? Cosa succede al tempo di sviluppo a valore aggiunto?
Il problema è davvero così grande?
Con la scalabilità agile, si assume semplicemente che servano molte persone per costruire il prodotto che si sta pianificando. La domanda successiva è poi come organizzare queste persone nel modo migliore.
Sapevi che Google è stato sviluppato da due persone nei suoi primi anni? E Facebook da una?
Il tuo prodotto è davvero così grande da eclissare Google e Facebook? Guadagnerai davvero miliardi? La tua comprensione e il tuo approccio sono davvero ottimali?
Il numero aiuta davvero?
Il libro “The Mythical Man-Month”, scritto circa 40 anni fa da Frederick P. Brooks, ha da tempo confutato l'idea che “più persone lavorano su un prodotto, più velocemente viene completato”. Ma ancora oggi, molte aziende credono che la “scalabilità agile” sia la soluzione del “mitico mese-uomo”. Come accennato prima, grandi prodotti sono stati sviluppati da poche persone – e più persone creano più lavoro, ma non più valore!
Non si potrebbe trovare una soluzione migliore con meno sviluppatori e meno lavoro? Sarebbe davvero più lento se meno persone fossero coinvolte?
Dopo tante domande arriviamo alla domanda centrale critica:
La “scalabilità agile” è davvero necessaria?
Considera i seguenti punti:
Gli sviluppatori hanno il 100% delle migliori conoscenze per fornire una soluzione?
Hanno il 100% della migliore tecnologia possibile per risolvere i problemi?
Gli sviluppatori sono al 100% concentrati sulla consegna del massimo valore?
Ogni attività è al 100% a valore aggiunto?
Il lavoro svolto è efficace al 100%?
Se vengono aggiunte più persone, queste percentuali tendono a non salire. Diminuiscono.
Quando queste percentuali vengono sommate, i risultati sono spesso spaventosi. Forse hai dieci persone che possono usare solo il 20% del loro potenziale – cosicché tre persone che possono usare l'80% del loro potenziale progredirebbero più velocemente!
Se 100 sviluppatori sono limitati al 5% del loro potenziale, forse un singolo team sarebbe più efficace di tutti loro!
Hai esplorato tutte le possibilità per fare di più con meno?
Solo se a tutte queste domande è già stata data la risposta “Sì” – allora anche la risposta alla domanda centrale è “Sì”. Prima di ciò, scalerai i tuoi problemi – e non la soluzione ai tuoi problemi!
