---

Superare scarso impegno, gestione del cambiamento e lavoro di squadra! Potrebbe sorprenderti!

La maggiore debolezza dei framework di miglioramento dei processi precedenti a Scrum era questa: Si concentravano principalmente sulle esigenze organizzative della leadership, al servizio di se stessa.

Tra queste figuravano monitoraggio, conformità e prevedibilità. Non c'era alcuna attenzione al buon servizio ai clienti o al morale dei dipendenti.

I gruppi di gestione software e gli altri stakeholder interni ed esterni cercavano quindi una scadenza fissa per le consegne e un monitoraggio semplice delle fasi ingegneristiche.

Penalizzavano le persone se qualcosa usciva dal percorso pianificato e speravano di correggere i problemi emergenti prima della data prevista di completamento.

Inoltre, silos indipendenti realizzavano fasi software interamente separate. Per esempio, lo sviluppo era completamente indipendente dal team di test (verifica). Molte persone che avrebbero dovuto lavorare alla stessa missione non si conoscevano nemmeno per nome.

Sai perché nelle organizzazioni prevalesse questa mentalità a silos anziché l'attenzione alla missione e alla maturità professionale (aziendale) delle persone?

La ragione è semplicemente la gestione a matrice . È una struttura organizzativa e del personale presente nelle aziende dagli anni 1970. A prima vista, l'idea distintiva di un'organizzazione o gestione a matrice sembra intelligente.

La leadership crea la struttura riunendo persone con competenze funzionali e tecniche simili nello stesso silo o, al massimo, in silos vicini.

Il modello Waterfall di consegna dei progetti in un'organizzazione a matrice

Allora era comune trovare in azienda i cosiddetti «centri di competenza», ognuno un silo indipendente e autonomo.

Un silo per sviluppatori C++, uno per amministratori di database e un altro completamente separato per la garanzia della qualità oltreoceano, e così via. Prova a capirci qualcosa!

La maggiore difficoltà della matrice era questa: per consegnare un progetto software senza framework Scrum e Scrum Master, i Project Manager dovevano prendere temporaneamente persone in prestito dai silos.

Queste persone non si trovavano neppure fisicamente con i team di progetto, ma restavano nelle stanze dei rispettivi centri di competenza.

Al termine dei progetti, i team temporanei si scioglievano e i partecipanti passavano agli incarichi successivi.

Il valore aziendale perseguito dai progetti in corso non era quindi mai la priorità assoluta di questi silos indipendenti.

Tendevano a vedere il lavoro come caselle da spuntare per un progetto qui e un altro là.

Leadership e modello a matrice non insegnavano come impegnarsi professionalmente nell'attività per migliorare risultati economici, vendite, ricavi e profitti.

Anche un articolo di McKinsey & Company su McKinsey Quarterly ha illustrato chiaramente questa illusione di ottimizzazione dei costi oltre l'organizzazione a matrice .

Gartner stimava che le organizzazioni nel mondo stessero annualmente spendendo 600 miliardi di USD per ripristinare i sistemi IT a causa di manutenzione non programmata e difetti.

Fermiamoci un momento a immaginare come si svolgessero gestione del cambiamento e trattamento degli impedimenti nei progetti software. Come funzionavano con modello Waterfall, organizzazione a matrice e senza processo Scrum.

Sì, hai ragione.

Dirigenti e dipendenti trattavano cambiamenti, impedimenti ed errori come eccezioni sgradite che non avrebbero dovuto verificarsi.

I cambiamenti diventavano così sinonimo di ritardi e producevano generalmente un effetto domino di ritardi a cascata. I team cercavano qualcuno da incolpare per difetti e impedimenti.

Infine, poiché i silos non avevano meccanismi per elaborare, correggere e imparare dagli errori, continuavano a ripeterli.

Inoltre, continuavano ad aumentare il debito tecnico mentre affrontavano passivamente i problemi.