Potresti sentirti così perché l'agile fa schifo per lo sviluppo del software.
Ecco perché...
Parliamo del processo per fare un grande lavoro. Fare un grande lavoro richiede due cose (fondamentalmente).
- Presentarsi ogni giorno per migliorare il prodotto.
- Presentarsi ogni giorno per migliorare se stessi.
Quando le persone fanno queste due semplici cose ogni singolo giorno, fanno un grande lavoro. E questo funziona in quasi tutti i campi a cui si può pensare.
E questa è l'antesi di come la maggior parte delle persone e delle aziende usano effettivamente l'agile. L'obiettivo di agile non è un grande lavoro. È qualcos'altro.
Quello su cui la maggior parte delle persone si concentra nel mondo dello sviluppo agile del software sono storie, stime e sprint. Fondamentalmente, la maggior parte delle persone crede che se prendono un pezzo di lavoro, lo suddividono in piccoli pezzi e li sputano fuori con una cadenza da fabbrica, magicamente rispetteranno le scadenze, avranno stime accurate e spediranno DI PIÙ!
Il problema con questo è che il vero obiettivo della gestione è la parola PIÙ. Vedete, spedire PIÙ li fa sembrare migliori. Rispettare più scadenze, spedire più funzioni, per ottenere più soldi e più promozioni. È solo un grande gioco di PIÙ.
Così ogni volta che arriva uno sprint o un epico, vogliono PIÙ funzioni, con una scadenza più aggressiva, per vendere PIÙ clienti su PIÙ promesse che hanno fatto.
Ma enigma questo Batman...
Se hai una quantità fissa di risorse e continui a spingere per PIÙ, cosa succede? Succede la merda.
Come diceva la vecchia canzone blues (e la cover di Zepplin), "If it keeps on raining, the levee's going to break"
Così in ogni scenario agile in cui sono stato, tutti sembrano andare lentamente verso il disastro perché c'è un desiderio infinito di PIÙ da parte di molte delle persone coinvolte.
Questo di solito assomiglia ad un cocktail di un grosso contratto, una scadenza impossibile, e squadre di sviluppatori che si arrabattano in un vero e proprio INCENDIO di lavoro fino a tardi e di essere miserabili nella speranza di sopravvivere al lancio. Succede il burnout (di solito ai top performer) e dopo due o tre turni di questo le persone migliori si stufano e se ne vanno.
Non c'è modo di aggirare questo perché gli incentivi in atto spingono tutti per fare DI PIÙ e questo è l'opposto di fare MEGLIO.
Vedi, in ogni sistema o attività c'è una distribuzione 80/20 di efficacia. Il lavoro più efficace è fatto nel primo 20% dello sforzo, dopo di che i rendimenti decrescenti entrano in gioco.
La costante spinta per fare DI PIÙ è in realtà una costante spinta verso rendimenti decrescenti. Ogni ora in più spesa vale meno della precedente. Alla fine ogni ora spesa produce un valore negativo e si sta peggio che se ci si fosse fermati prima.
Per esempio, il lavoro di programmazione più produttivo è fatto in circa 2-3 ore al giorno. Dopo diciamo due ore di codifica effettiva, i rendimenti decrescenti entrano in gioco e i programmatori iniziano a girare le ruote.
Lo scenario ideale sarebbe per i programmatori di presentarsi al lavoro, fare 2-3 ore di lavoro di qualità, e andare a casa. Raccogliete il lavoro più prezioso che potete, fate qualche buon progresso, e fermatevi.
Questo è il modo per massimizzare la produzione dei programmatori. Non richiede affatto l'agilità. Non richiede storie, sprint, stime o scadenze. Gli scrum master non sono necessari. Non sono necessari stand up giornalieri. Praticamente tutta la pompa e le circostanze non sono necessarie.
Ma... quello che ho descritto non è come funziona l'agile. Non è come sono progettati gli ambienti di lavoro moderni. Le persone devono stare sedute su una sedia per 40 ore alla settimana per incassare un assegno. I programmatori devono andare a tonnellate di riunioni senza senso per "collaborare" invece di scrivere effettivamente solo codice. Ore e ore sono passate in inutili negoziazioni su "questa caratteristica entrerà in questo sprint" invece di codificare la suddetta caratteristica e andare avanti.
Così, i programmatori (che amano essere pagati), giocano con le assurdità dell'agile perché parte del lavoro è giocare con l'agile. Era lo stesso con il waterfall prima di esso. Nessuno di questi metodi funziona particolarmente bene perché in realtà si riduce a questo:
La programmazione è un'attività solitaria che dovrebbe assomigliare di più ad un fabbro che martella su un'incudine. Giorno dopo giorno, affinando il loro mestiere, plasmando le idee in manifestazioni fisiche.
Invece, abbiamo preso questa attività solitaria e l'abbiamo trasformata in una fabbrica di software piena di cubicoli o uffici aperti che sono così ridicoli da essere facilmente sbeffeggiati da Dilbert, The Office e Office Space (che sono tutti spaventosamente accurati). È probabilmente il modo meno efficiente di organizzare il nostro lavoro, ma ottimizzare l'efficacia o la qualità dei programmatori non ha niente a che fare con tutti i proprietari, i manager, i PM, i coach agili, ecc. che stanno inseguendo il PIÙ.
La risposta sarebbe inseguire il MENO, ma chi è abbastanza pazzo da farlo? Nessuno nella terra agile, questo è sicuro.
-Brian