Attenti a SAFe (Scaled Agile Framework for Enterprise), una empia incarnazione delloscurità

… o forse no.

Se preferisci che SAFe parli da solo puoi usare il collegamento sopra. Ci sono centinaia di pagine di documentazione, ore di video, 15 diversi corsi di formazione e altro ancora. Se questo suona un po troppo, farò del mio meglio per fornire qualche spiegazione di come funziona SAFe mentre passo attraverso ogni punto.

Al livello più alto, chiamato “Portfolio”, SAFe sostiene finanziamento indefinito “Value Streams”, che di solito rappresenta un prodotto, una linea di prodotti o un tipo di cliente. Tuttavia, la funzione Lean Portfolio Management (LPM) che controlla i finanziamenti (probabilmente le stesse persone precedentemente responsabili dei budget dei progetti a cascata), hanno lautorità esclusiva per approvare quali Portfolio Epics (grandi iniziative) si spostano in ogni flusso. Le epiche non sono spiegazioni su un problema che deve essere risolto. Sono idee preformate su come risolvere al meglio questi problemi.

Immediatamente possiamo vedere i segni della mentalità vecchia scuola di vedere i team come una funzione di “consegna” invece che strategica. pensatori di livello escogitano idee e coloro che agiscono di basso livello mettono in pratica quelle idee. Ignorata è la possibilità che coloro che sono più vicini al lavoro possano essere meglio attrezzati per prendere decisioni al riguardo. Fuggire da questa mentalità fuorviante è un obiettivo fondamentale del pensiero Agile che SAFe non riesce a realizzare in remoto.

Un problema simile si ripresenta quando guardiamo a un livello leggermente inferiore.

SAFe raccoglie piccoli team di prodotto (spesso team Scrum) in “Agile Release Trains “- gruppi di team con un livello aggiuntivo di ruoli di gestione che coprono ogni gruppo a quello che viene chiamato il” livello di programma “.

Generalmente questi ruoli ostacolano lautonomia dei team. Aggiungono un overhead di processo e comunicazione sproporzionato con il valore che forniscono.

Questi ruoli includono un Product Manager (PM), un S ystem Architect (SA) e un Release Train Engineer (RTE).

Il SA e il PM definiscono e suddividono pezzi di lavoro più grandi (spesso ereditati dal processo di portfolio di cui sopra) e quindi passano i pezzi nel team.

Il Product Owner e il team potrebbero teoricamente essere in grado di dare la priorità ad altri lavori più piccoli rispetto al lavoro loro imposto, ma questi sforzi hanno visibilità limitata e buy-in dallalto. Ci sarà una pressione naturale per considerare il lavoro proveniente dal punto più alto come più importante, anche se ogni singolo membro del team ritiene che altri elementi sarebbero più preziosi. Per questo motivo, il ruolo del Product Owner si riduce alla scrittura di storie e al controllo dei criteri di accettazione, invece di essere lunico punto di responsabilità per la leadership del prodotto che era lintenzione originale del ruolo.

The System Architect non è in grado di essere vicino al lavoro di ingegneria reale, quindi il progetto architettonico che trasmettono può essere scollegato dalla realtà dellopera. Questi tipi di ruoli erano un segno distintivo dei progetti a cascata di grande design e sono ben conservati in SAFe.

I tecnici del treno di rilascio definiscono il processo e la cadenza tra team coerenti e gestiscono molte attività operative. In definitiva, questo lascia meno spazio ai singoli team per modificare, migliorare o sperimentare le proprie pratiche in qualsiasi modo che si discosti dagli standard stabiliti.

A volte tutti questi problemi vengono ripetuti di nuovo con laggiunta di un “Large Solution Level “- gruppi di gruppi di team con ruoli analoghi a quelli a livello di programma, ma che coprono i Release Trains. Quando ciò si verifica è probabile che si ripetano gli stessi problemi, ma il Solution Level sembra essere meno comunemente messo in atto.

SAFe (spesso) viene fornito in bundle con Rally – ULTERIORE limitazione dellautonomia del team

SAFe è spesso un pacchetto con il software di gestione dei progetti Rally. Rally è il tipo di software che ti aspetteresti unazienda che utilizza SAFe per creare: è sovraccarica di funzionalità, sfocata, confusa, instabile e di conseguenza difficile da apprendere e utilizzare.

La proposta di valore delladozione di Rally per la leadership è che saranno in grado di vedere reportistica che fornisce loro unimmagine semplice e unificata di th I progressi e i problemi in tutta lazienda.

Ovviamente, questo significa che tutti nellazienda non solo devono utilizzare Rally, ma devono usarlo in modo coerente. Ancora una volta, questo può essere ottenuto solo tramite dettatura dallalto verso il basso. Il rally e il modo in cui pensa al lavoro sono obbligati a tutti i team indipendentemente dalle loro preferenze, contesto o buy-in. Per avere effettivamente tutte le informazioni raggruppate richiede un incredibile sovraccarico di stima e monitoraggio che rallenta tutto e può essere estremamente distruttivo per portare a termine il lavoro.

Inoltre, i rapporti di livello superiore non sono nemmeno particolarmente utili. Si concentra sulle cose che Rally tiene traccia: metriche come il volume di story point consegnati (letteralmente inventati) o la quantità di bug risolti (una misura terribile per la “qualità del prodotto”).Se la direzione ignora queste statistiche, il sovraccarico che aggiungono sarà inutile. Se riescono a raggiungere le metriche, le statistiche verranno confuse in modo che le squadre abbiano un bellaspetto e vengano lasciate sole. Le stime saranno troppo riempite, i piccoli pezzi di lavoro saranno esagerati e questo può facilmente portare a un crollo della fiducia.

SAFe adotta lapproccio peggiore possibile per la gestione delle dipendenze

A la dipendenza è un caso in cui un team deve aspettare che qualcosa venga fatto altrove prima di poter completare il proprio lavoro. SAFe è strutturato attorno a un atteggiamento allindietro secondo cui le dipendenze sono un fatto immutabile della vita che dovrebbe essere accettato e gestito. A volte si riferisce anche a loro come un vantaggio strategico. In realtà, quando pensi alle dipendenze come a una cosa negativa – da ridurre al minimo in ogni occasione – potresti scoprire che quelle opportunità sono abbondanti e che sfruttarle si traduce principalmente in benefici. Di seguito sono riportati solo alcuni suggerimenti che SAFe sotto-enfatizza o ignora completamente:

1. Incoraggia una cultura di internal-sourcing in cui un team può inviare il lavoro alla base di codice di un altro team senza dover dipendere da loro oltre accettare la fusione
2. Rendi più facile per i membri del team scambiare team temporaneamente o permanentemente quando ha senso farlo
3. Concentrati sullassunzione, la strutturazione e la formazione dei team per gestire le proprie esigenze senza aiuto esterno

Il modo in cui SAFe sceglie effettivamente di gestire le dipendenze è concentrandosi maggiormente su pianificazione, processo, gerarchia e standardizzazione. Comera prevedibile, questo si traduce in molte riunioni che interferiscono con la capacità di portare a termine il lavoro. Impone questo approccio attraverso un roll-out universale che interessa lintera organizzazione in una volta. Non viene data alcuna considerazione a quali aree avrebbero potuto essere autosufficienti senza la struttura onerosa aggiuntiva.

SAFe è eccessivamente orientato alla pianificazione

Una caratteristica fondamentale di SAFe è lidea di ~ 10 settimane Incrementi di programma (PI). Puoi pensare a questo tipo di sprint enormi che contengono tutti i tuoi sprint normali.

Ogni PI inizia con un evento di pianificazione PI che dura circa due giorni. La pianificazione PI richiede anche attività di pre-pianificazione e post-pianificazione a livello di programma.

È sicuramente un valore avere persone che si incontrano di persona per costruire relazioni, condividere informazioni e orientarsi intorno agli obiettivi. Daltra parte, lutilizzo di quella finestra di tempo limitata per creare piani di 10 settimane di storie utente specifiche basate su funzionalità predefinite e quindi richiedere limpegno a tali piani è molto meno prezioso.

Non appena termina la pianificazione PI, quei piani creati sulla base di la comprensione e numerosi presupposti diventeranno obsoleti non appena si apprenderà qualcosa di nuovo. I team saranno continuamente combattuti tra laderenza al piano che hanno imparato non ha senso e il riorientamento delle aspettative per motivi che quelli sopra di loro potrebbero non essere in grado di capire.

SAFe è orientata al volume, non valore

In tutta questa attenzione alle metriche del volume, alla stima e al lavoro di abbandono lungo la pipeline, il concetto di ciò che è effettivamente prezioso o di successo viene facilmente perso. Si presume spesso che più lavoro spedito fuori dalla porta debba essere “valore”, anche se lesperienza del prodotto è effettivamente sofferente e gli utenti non stanno beneficiando delle funzionalità aggiuntive.

SAFe è consapevole delle critiche che non è incentrato sul valore e ha recentemente aggiunto “design thinking”, “customer centricity” e altri concetti alla sua documentazione per compensare. Finora non sono convinto che apporti cambiamenti significativi nel suo processo che effettivamente lasciano spazio a queste cose e riesce persino a capirli in primo luogo.

Ad esempio, la definizione di “clienti” di SAFe lascia la porta aperta alla definizione di stakeholder aziendali o di coloro che finanziano i flussi di valore come “clienti”. Questo è molto diverso dal riorientare tutti (compresi coloro che forniscono i fondi) per concentrarsi sulle esigenze degli utenti finali che utilizzano effettivamente il software, un elemento centrale del pensiero progettuale.

SAFe è inutilmente complesso

SAFe ha un vantaggio naturale che protegge dalla critica; È così complicato che è difficile da comprendere appieno. Nonostante il tempo aggiuntivo che ho dedicato alla ricerca del framework, è probabile che sbagli ancora alcune cose o perda alcuni punti importanti. Tuttavia, labbondanza di complessità è di per sé una preoccupazione legittima. SAFe ha così tanti incontri, punti di controllo, valori e metodi che è praticamente impossibile mettere tutti sulla stessa pagina.

SAFe limita le retrospettive e il miglioramento continuo

Ruoli a livello di programma e non è possibile partecipare a tutte le retrospettive del team.Ciò significa che le retrospettive non saranno ascoltate direttamente dalle persone che possono effettivamente cambiare molte delle cose discusse.

Il modo in cui SAFe cerca di compensare questo non è sufficiente.

Pianificazione PI è lunico momento in cui tutti i partecipanti a un treno di rilascio possono stare insieme di persona. Sfortunatamente contiene una breve retrospettiva relativa solo al successo dellevento di pianificazione stesso.

SAFe include un evento “Inspect and Adapt” verso la fine di ogni PI, ma sembra quasi progettato per essere ignorato in base su quanto sia difficile coordinarsi per lRTE. Quando si tiene, levento viene preparato rivedendo – ovviamente – le metriche del volume dallultimo PI. Inoltre, solo 30 minuti dellevento sono assegnati per una retrospettiva effettiva in cui le questioni vengono emerse e concordate su. Se questo tempo è diviso equamente tra tutti i membri di un treno di rilascio di 100 persone, ogni partecipante avrà circa 18 secondi ogni ~ 10 settimane per sollevare problemi in un contesto in cui potrebbero essere effettivamente ascoltati.

SAFe ha anche alcuni altri elementi come “grafici di valutazione” in cui i team vengono intervistati in modo più ampio, ma questi tendono fortemente a confermare che le pratiche SAFe vengono seguite, non se siano efficaci o meno.

SAFe degrada i concetti che aggrega

Una chiave parte di SAFe che non ho ancora toccato è laggregazione di concetti esistenti come Scrum, Kanban, Lean Product, Lean UX e DevOPs.

Se non hai familiarità, suggerirei di esplorare ogni concetto indipendentemente nel tempo piuttosto che tutto in una volta. Molti sono preziosi essi stessi, ma SAFe non fa un ottimo lavoro nel sintetizzarli effettivamente e a volte può aggiungere confusione. Caso in questione:

SAFe sostiene abitualmente il modo in cui le sue pratiche seguono i principi “Lean-Agile”. Il trucco è che “Lean-Agile” in realtà non si riferisce ai principi “Lean” o “Agile”.

Invece i “principi Lean-Agile” sono una creazione del design di SAFe. Questa nuova serie di “principi” altera i concetti che assimila. Ad esempio, la pagina sulla decentralizzazione delle decisioni (classificata come il più basso di tutti i principi) si sovverte sottilmente sottolineando limportanza di centralizzare il processo decisionale per molti casi duso. Altri principi elencati hanno problemi simili. Per una persona che viene introdotta a tutte queste informazioni contemporaneamente, il significato effettivo dei concetti originali potrebbe andare perso.

SAFe non è Agile

Ormai molti dei modi in cui SAFe è incoerente con una mentalità Agile dovrebbe essere abbastanza chiaro. È focalizzato sul piano, burocratico, complicato, include un sacco di processi spesso non necessari, svaluta lautonomia del team e altro ancora.

Ma importa se SAFe è Agile o meno quando ciò che ci interessa davvero è lefficacia ?

Sì. Sì.

I principi Agile sono solo principi Agile perché sono stati generalmente riconosciuti e concordati come efficaci. Quel pensiero ha risuonato con una più ampia comunità di praticanti, motivo per cui il movimento originariamente è decollato. Se pensi che lagilità sia un predittore di efficacia, (una convinzione presumibilmente alla base di parte dellinteresse per SAFe), allora è molto importante se SAFe è coerente con il pensiero Agile. Ingannare le persone su ciò che stanno acquistando è una cosa negativa e non è sbagliato dirlo fuori.

E tutti i casi di studio in cui SAFe ha dimostrato di aver funzionato?

Ci sono circa 40 casi di studio sulladozione di SAFe di successo su scaledagileframework.com. I casi di studio per i fallimenti sono vistosamente assenti. Contrariamente allacronimo, SAFe implica modifiche simultanee a un enorme nuovo processo in un enorme ecosistema: un rischio enorme. A meno che ognuna di queste 40 aziende di successo non avesse ciascuna 11.250 professionisti SAFe certificati, ci sono alcune aziende da cui non abbiamo notizie.

Inoltre, non metto troppe azioni nei casi di studio che lo fanno esistere. Anche se le metriche del volume su cui si concentrano fossero davvero preziose, è facile scegliere alcune statistiche che facciano sembrare che le cose siano andate bene.

Per concentrarsi su un esempio specifico, diamo unocchiata a un estratto dal case study sullimplementazione di SAFe presso Fitbit:

Nel 2016, la società di tecnologia consumer, Fitbit, ha rilasciato sul mercato quattro nuovi prodotti che sono stati accolti positivamente da consumatori e ha spedito oltre 22 milioni di dispositivi. La fornitura del maggior numero di prodotti in un anno è dovuta in parte allimpegno dellazienda e al successo nelladozione di SAFe® (Scaled Agile Framework®) come un modo per scalare il team per soddisfare le date target.

© Scaled Agile, Inc.

Ecco il prezzo delle azioni Fitbit negli ultimi cinque anni:

Sì … il 2016 sembra un anno fantastico per Fitbit.

Ora, non possiamo davvero attribuire la caduta di Fitbit a SAFe adozione con la quantità di informazioni che abbiamo.Ma se unazienda può lottare così tanto e ancora salutare ladozione di SAFe come un miglioramento della reattività delle proprie decisioni sui prodotti, stringerò gli occhi di qualche grado in più quando esaminerò il resto dei casi di studio.

Va bene come passaggio di transizione, giusto?

Se sei qualcuno che vorrebbe sostenere questo argomento, allora devi pensare che SAFe debba essere allontanato da. Su questo punto siamo daccordo!

Per effettuare questa transizione dovremo ovviamente dedicare un po di tempo a sottolineare le parti che non funzionano bene.

È qualcosa che hai hai passato molto tempo su?

Anche se lo sei, SAFe è configurato in un modo che ti impedisce di effettuare effettivamente la transizione. Lautorità che pone nelle mani del management funge da legittimazione della mentalità del controllo dallalto verso il basso. Ciò si accoppia male con i metodi mancanti per il miglioramento del processo che abbiamo già trattato. Lautorità di “personalizzare” SAFe nel contesto appropriato non è per lo più disponibile per i team effettivi nella posizione migliore per riconoscere ciò che non funziona.

In nessun punto della road map di SAFe si riferisce effettivamente a nessuno dei suoi pratiche di base come transitorie. Se si tratta di un framework di transizione, non fornisce alcun tipo di piano di transizione.

Leccessiva attenzione alle certificazioni danneggia anche la flessibilità del framework . Se passi ore e ore a lavorare per ottenere la certificazione, la certificazione diventa parte del tuo valore. Una transizione a qualcosa che assomiglia meno a SAFe può sembrare che minacci quel valore. Non posso biasimare nessuno per aver ottenuto la certificazione in un mercato del lavoro dove le certificazioni contano. Ma questi individui hanno la responsabilità particolare di prestare attenzione agli aspetti negativi di SAFe e ai possibili modi per migliorarlo o deviarlo.

Questi problemi sono ampiamente sperimentati

Non sono solo in esprimendo molte di queste critiche, anche se spero di essere andato un po oltre collegandole alle pratiche specifiche nel framework. Se stai cercando testimonianze corroboranti, eccone alcune:

Ken Schwaber, co-sviluppatore di Scrum, ha espresso serie preoccupazioni su SAFe già nel 2013.

Nicholas M. Chaillan , Chief Software Officer dellaeronautica degli Stati Uniti, scoraggia “luso di framework rigidi e prescrittivi come lo Scaled Agile Framework (SAFe)”.

Il collaboratore di Forbes Steve Denning chiama SAFe per essere “particolarmente preoccupante” nel suo articolo su come individuare i falsi Agile.

Marty Cagan del Silicon Valley Product Group spiega come SAFe sia antitetico alla mentalità delle aziende della Silicon Valley.

Resta al sicuro là fuori (non SAFe)

Anche se SAFe ha sicuramente ricevuto molte critiche , la mia sensazione personale è che questa critica potrebbe non aver raggiunto un vasto pubblico al di là di alcuni circoli online. Ciò è particolarmente probabile se considerato insieme al crescente numero di aziende che adottano il framework ogni giorno.

Per molte persone, lidea che ci sia qualcosa di sbagliato in SAFe – o che sia in conflitto con i principi Agile – può essere completamente nuovo.

Una discussione più intensa rivolta a un pubblico più ampio può probabilmente aiutare. Spero di toccare di più questo argomento in futuro e di dettagliare quali altre alternative sono disponibili.

Per ora, anche se non stai lavorando in un ambiente SAFe, non è una scusa per essere compiacenti . Le preoccupazioni che ho esposto qui dovrebbero essere prese come un avvertimento più ampio: anche le idee più sensate possono essere facilmente cooptate, corrotte e confuse se non si presta molta attenzione.