Feriți-vă de SAFe (Cadrul Agil Scalat pentru Întreprindere), o Încarnare Unholy a Întunericului

… sau poate nu.

Dacă preferați că SAFe vorbește de la sine, puteți utiliza linkul de mai sus. Există sute de pagini de documentație, ore de videoclipuri, 15 cursuri de formare diferite și multe altele. Dacă sună puțin, voi face tot posibilul pentru a oferi o explicație a modului în care funcționează SAFe pe măsură ce trec prin fiecare punct.

La cel mai înalt nivel, numit „Portofoliu”, SAFe susține finanțarea „fluxurilor de valori” nedeterminate – care reprezintă de obicei un produs, o linie de produse sau un tip de client. Cu toate acestea, funcția de gestionare a portofoliului Lean (LPM) care controlează finanțarea (probabil aceleași persoane responsabile anterior pentru bugetele proiectului în formă de cascadă), are singura autoritate de a aproba care Epopeii Portofoliului (inițiative mari) se mută în fiecare flux. Epopeile nu sunt explicații despre o problemă care trebuie rezolvată. Sunt idei pre-formate despre cum să rezolvi cel mai bine acele probleme.

Imediat putem vedea semne ale mentalității vechii școli de a vedea echipele ca o funcție de „livrare” în loc de una strategică. gânditorii de nivel vin cu idei, iar cei care îndeplinesc nivelul scăzut execută aceste idei. Ignorată este posibilitatea ca cei mai apropiați de lucrare să fie cei mai bine echipați pentru a lua decizii cu privire la aceasta. Evadarea din această mentalitate greșită este un obiectiv de bază al gândirii agile care SAFe nu reușește să realizeze de la distanță.

O problemă similară apare din nou când ne uităm la un nivel ușor mai mic.

SAFe colectează echipe mici de produse (adesea echipe Scrum) în „Trenuri de lansare Agile” ”- grupuri de echipe cu un strat suplimentar de roluri de management care acoperă fiecare grup la ceea ce se numește„ nivel de program ”.

În general, aceste roluri împiedică autonomia echipelor. cu valoarea pe care o oferă.

Aceste roluri includ un Manager de produs (PM), un S. ystem Architect (SA) și un inginer de tren de lansare (RTE).

SA și PM definesc și separă lucrări mai mari (adesea moștenite din procesul de portofoliu de mai sus) și apoi trec piesele în echipe.

Proprietarul de echipă și echipa ar putea teoretic să fie capabili să acorde prioritate altor lucrări mai mici față de munca impusă acestora, dar aceste eforturi au vizibilitate limitată și participare de sus. Va exista o presiune naturală pentru a trata munca care vine din cel mai înalt punct ca fiind cea mai importantă – chiar dacă fiecare membru al echipei crede că alte elemente ar fi mai valoroase. Din această cauză, rolul proprietarului produsului se reduce la scrierea de articole și verificarea criteriilor de acceptare, în loc să fie singurul punct de responsabilitate pentru conducerea produsului, care a fost intenția inițială pentru rol.

Arhitectul de sistem nu este în măsură să fie aproape de lucrarea de inginerie efectivă, astfel încât planul arhitectural pe care îl transmit poate fi deconectat de realitatea lucrării. Aceste tipuri de roluri au fost un semn distinctiv al proiectelor de cascadă cu design mare și sunt bine păstrate în SAFe.

Inginerii de trenuri de lansare definesc procesul și cadența coerente și se ocupă de multe sarcini operaționale. În cele din urmă, acest lucru lasă mai puțin spațiu echipelor individuale pentru a modifica, îmbunătăți sau experimenta cu propriile practici în orice mod care se abate de la standardele stabilite.

Uneori, toate aceste probleme se repetă din nou cu adăugarea unui Solution Level ”- grupuri de grupuri de echipe cu roluri similare cu cele de la nivel de program, dar care se întind pe Release Trains. Când se întâmplă acest lucru, probabil că se repetă aceleași probleme, dar nivelul Solution pare să fie mai puțin pus în aplicare.

SAFe (de multe ori) vine la pachet cu Rally – limitarea în plus a autonomiei echipei

SAFe este adesea un pachet cu software-ul de management al proiectului Rally. Rally este genul de software la care te-ai aștepta o companie care folosește SAFe pentru a crea – este supraîncărcată cu caracteristici, nefocalizată, confuză, instabilă și, în consecință, dificil de învățat și de folosit.

Propunerea de valoare a adoptării Raliului pentru conducere este că vor putea vedea raportare care le oferă o imagine simplă, unificată a th Progrese și probleme în întreaga întreprindere.

Desigur, aceasta înseamnă că toată lumea din întreprindere nu numai că trebuie să folosească Rally, ci trebuie să-l folosească într-un mod consecvent. Din nou, acest lucru poate fi realizat numai prin dictare de sus în jos. Raliul și modul în care se gândește la muncă sunt forțate asupra tuturor echipelor, indiferent de preferință, context sau buy-in. Pentru ca toate informațiile să fie acumulate necesită o cheltuială extraordinară în estimarea și urmărirea, care încetinește totul și poate fi extrem de perturbatoare pentru realizarea efectivă a muncii.

În plus, raportarea la nivel superior nu este chiar deosebit de utilă. Se concentrează pe lucrurile pe care le urmărește Raliul – valori precum volumul punctelor de poveste livrate (literalmente alcătuite) sau cantitatea de bug-uri abordate (o măsură teribilă pentru „calitatea produsului”).Dacă conducerea ignoră aceste statistici, cheltuielile pe care le adaugă vor fi degeaba. Dacă reușesc să respecte valorile, statisticile vor fi modificate, astfel încât echipele să arate bine și să rămână singure. Estimările vor fi supra-umplute, lucrările mici vor fi exagerate și acest lucru poate duce cu ușurință la o descompunere a încrederii.

SAFe adoptă cea mai proastă abordare posibilă pentru gestionarea dependențelor

A dependența este un caz în care o echipă trebuie să aștepte să se facă ceva în altă parte înainte de a-și putea finaliza propria muncă. SAFe este structurat în jurul unei atitudini înapoi, conform căreia dependențele sunt un fapt imuabil al vieții care ar trebui acceptat și gestionat în jur. Chiar uneori se referă la ele ca la un avantaj strategic. În realitate, atunci când te gândești la dependențe ca la un lucru rău – care trebuie reduse la minimum cu fiecare ocazie – poți constata că acele oportunități sunt abundente și că a profita de ele duce în primul rând la beneficii. Iată doar câteva sugestii pe care SAFe le subliniază sau le ignoră în totalitate:

1. Încurajați o cultură de aprovizionare interioară în care o echipă poate trimite lucrări la baza de cod a altei echipe fără a fi nevoie să depindă de ele dincolo de ele acceptarea îmbinării
2. Faceți mai ușor pentru membrii echipei schimbul temporar sau permanent de echipe atunci când este logic să faceți acest lucru
3. Concentrați-vă pe angajarea, structurarea și instruirea echipelor pentru a face față propriilor nevoi fără ajutor extern

Modul în care SAFe alege de fapt să gestioneze dependențele este concentrându-se pe planificare, proces, ierarhie și standardizare. În mod previzibil, acest lucru are ca rezultat o mulțime de întâlniri care interferează cu capacitatea de a face treabă. Impune această abordare printr-o lansare universală care afectează întreaga organizație simultan. Nu se ia în considerare ce zone ar fi putut fi autonome fără o structură împovărătoare suplimentară.

SAFe este orientat excesiv în jurul planificării

O caracteristică de bază a SAFe este ideea de ~ 10 săptămâni Incrementări ale programului (PI). Vă puteți gândi la astfel de sprinturi uriașe care conțin toate sprinturile dvs. normale.

Fiecare PI începe cu un eveniment de planificare PI care se desfășoară timp de aproximativ două zile. Planificarea PI necesită, de asemenea, activități de planificare prealabilă și post-planificare la nivel de program.

Există cu siguranță o anumită valoare în faptul că oamenii se reunesc personal pentru a construi relații, a împărtăși informații și a se orienta în jurul obiectivelor. Pe de altă parte, utilizarea acelei ferestre de timp limitate pentru a face planuri de 10 săptămâni pentru anumite povești ale utilizatorilor pe baza caracteristicilor predefinite și apoi necesitatea angajării față de aceste planuri este mult mai puțin valoroasă.

De îndată ce planificarea PI se încheie, acele planuri create pe baza înțelegerea și numeroasele ipoteze vor deveni învechite de îndată ce se va afla ceva nou. Echipele vor fi împărțite în mod continuu între respectarea planului pe care l-au învățat nu are sens și reorientarea așteptărilor din motive pe care cei de deasupra lor nu ar putea să le înțeleagă.

SAFe este orientat în jurul volumului, not value

În tot acest accent pe măsurarea volumului, estimarea și transformarea lucrărilor prin conductă, conceptul de ceea ce este de fapt valoros sau de succes se pierde cu ușurință. Se presupune adesea că mai multe lucrări livrate pe ușă trebuie să fie „valoare”, chiar dacă experiența produsului suferă de fapt și utilizatorii nu beneficiază de caracteristicile suplimentare.

SAFe este conștient de criticile nu este axat pe valoare și a adăugat recent „gândire de proiectare”, „centrare pe client” și alte concepte în documentația sa pentru a compensa. Până în prezent nu sunt convins că face modificări semnificative în procesul său care să facă loc pentru aceste lucruri. , și înțelege chiar înțelegându-le în primul rând.

De exemplu, definiția SAFe a „clienților” lasă ușa deschisă definirii părților interesate din afaceri sau a celor care finanțează fluxurile de valoare ca fiind „clienți”. este foarte diferit de reorientarea tuturor (inclusiv a celor care oferă finanțare) pentru a se concentra asupra nevoilor utilizatorilor finali care utilizează efectiv software-ul, un element de bază al gândirii de proiectare.

SAFe este inutil de complex

SAFe are un avantaj natural care protejează din critici; Este atât de complicat încât este dificil de înțeles pe deplin. În ciuda timpului suplimentar pe care l-am petrecut cercetând cadrul, probabil că sunt în continuare susceptibil să greșesc unele lucruri sau să ratez câteva puncte importante. Cu toate acestea, abundența complexității este ea însăși o preocupare legitimă. SAFe are atât de multe întâlniri, puncte de control, valori și metode încât este practic imposibil să atragi pe toată lumea pe aceeași pagină.

SAFe limitează retrospectivele și îmbunătățirea continuă

Rolurile la nivel de program și de mai sus nu poate participa la toate retrospectivele echipei.Acest lucru înseamnă că retrospectivele nu vor fi auzite direct de oamenii care pot schimba de fapt multe dintre lucrurile discutate.

Modul în care SAFe încearcă să compenseze acest lucru nu este suficient.

Planificarea PI este singurul moment în care toată lumea dintr-un tren de eliberare este garantat să fie împreună în persoană. Din păcate, conține o scurtă retrospectivă legată doar de succesul evenimentului de planificare în sine.

SAFe include un eveniment „Inspectează și adaptează” spre sfârșitul fiecărui PI, dar pare aproape conceput pentru a fi omis pe baza despre cât de greu este să te coordonezi pentru RTE. Când este organizat, evenimentul este pregătit prin revizuirea – desigur – a valorilor volumului din ultimul PI. În plus, doar 30 de minute ale evenimentului sunt alocate pentru o retrospectivă reală în care problemele sunt afișate și convenite. Dacă acest timp este împărțit în mod egal între toți membrii unui tren de eliberare de 100 de persoane, atunci fiecare participant va primi aproximativ 18 secunde la fiecare ~ 10 săptămâni pentru a aduce probleme într-un context în care ar putea fi auziți de fapt.

SAFe are și alte elemente, cum ar fi „diagrame de evaluare”, în care echipele sunt analizate mai larg, dar acestea se orientează puternic spre confirmarea faptului că practicile SAFe sunt urmate, indiferent dacă sunt sau nu eficiente.

SAFe degradează conceptele pe care le agregă

O cheie o parte din SAFe pe care nu am atins-o încă este agregarea conceptelor existente precum Scrum, Kanban, Lean Product, Lean UX și DevOPs.

Dacă nu sunteți familiarizați, aș sugera explorarea fiecărui concept independent în timp, mai degrabă decât dintr-o dată. Mulți sunt valoroși ei înșiși, dar SAFe nu face o treabă excelentă la sintetizarea lor și uneori poate adăuga confuzie. Exemplu:

SAFe susține în mod obișnuit modul în care practicile sale respectă principiile „Lean-Agile”. Trucul este că „Lean-Agile” nu se referă de fapt la principiile „Lean” sau „Agile”.

În schimb, „Principiile Lean-Agile” sunt o creație a designului propriu al SAFe. Acest nou set de „principii” deformează conceptele pe care le asimilează. De exemplu, pagina despre deciziile de descentralizare (clasată pe cea mai mică dintre toate principiile) se subvertizează subtil, subliniind importanța centralizării luării deciziilor pentru multe cazuri de utilizare. Alte principii enumerate au probleme similare. Pentru o persoană care este introdusă la toate aceste informații simultan, sensul real al conceptelor originale poate fi pierdut.

SAFe is not Agile

Până acum, multe dintre modurile în care SAFe este neconform cu o mentalitate Agile ar trebui să fie destul de clară. Este axat pe plan, birocratic, complicat, include o mulțime de procese deseori inutile, elimină autonomia echipei și multe altele.

Dar contează dacă SAFe este Agil sau nu, atunci când ceea ce ne interesează cu adevărat este eficiența ?

Da. Da.

Principiile Agile sunt doar principii Agile, deoarece au fost în general recunoscute și convenite ca fiind eficiente. Această gândire a rezonat cu o comunitate mai largă de practicanți, motiv pentru care mișcarea a început inițial. Dacă credeți că agilitatea este un predictor al eficacității (o credință probabil în spatele unora dintre interesele pentru SAFe), atunci contează destul de mult dacă SAFe este în concordanță cu gândirea agilă. Înșelarea oamenilor cu privire la ceea ce cumpără este un lucru rău și nu este greșit să anunți asta.

Ce se întâmplă cu toate studiile de caz în care se arată că a funcționat SAFe?

Există aproximativ 40 de studii de caz privind adoptarea cu succes a SAFe pe scaledagileframework.com. Studiile de caz pentru eșecuri sunt în mod evident absente. Contrar acronimului, SAFe implică schimbări simultane ale unui nou proces uriaș într-un ecosistem enorm – un risc masiv. Cu excepția cazului în care fiecare dintre aceste 40 de companii de succes a avut 11.250 de practicanți SAFe certificate, există destul de multe companii de care nu auzim.

De asemenea, nu pun prea mult stoc în studiile de caz care fac exista. Chiar dacă valorile de volum pe care se concentrează au fost cu adevărat valoroase, este ușor să alegeți câteva statistici care fac să pară că lucrurile au mers bine.

Pentru a ne concentra asupra unui exemplu specific, să aruncăm o privire la un extras din studiul de caz despre implementarea SAFe la Fitbit:

În 2016, compania de tehnologie pentru consumatori, Fitbit, a lansat pe piață patru noi produse care au fost primite pozitiv de consumatori și a livrat peste 22 de milioane de dispozitive. Livrarea celui mai mare număr de produse într-un an se datorează în parte angajamentului companiei și succesului în adoptarea SAFe® (Scaled Agile Framework®) ca modalitate de a scala echipa pentru a îndeplini datele-țintă.

© Scaled Agile, Inc.

Iată prețul acțiunilor Fitbit din ultimii cinci ani:

Da … 2016 pare un an excelent pentru Fitbit.

Acum, nu putem atribui cu adevărat căderea Fitbit SAFe adoptarea cu cantitatea de informații pe care o avem.Dar dacă o companie se poate lupta atât de mult și totuși salută adoptarea SAFe ca îmbunătățind capacitatea de reacție a deciziilor sale de produs, voi restrânge ochii cu câteva grade mai mult atunci când verific restul studiilor de caz.

Totuși, este OK ca un pas de tranziție, nu-i așa?

Dacă sunteți cineva care ar face acest argument, atunci trebuie să credeți că SAFe trebuie să fie tranziționat. Cu privire la acest punct suntem de acord!

Pentru a face această tranziție, va trebui, desigur, să petrecem ceva timp indicând părțile care nu funcționează bine.

Este ceva ce ai ați petrecut mult timp?

Chiar dacă sunteți, SAFe este configurat într-un mod care vă împiedică să efectuați tranziția. Autoritatea pe care o pune în mâinile managementului acționează ca o legitimare a mentalității de control de sus în jos. Acest lucru se asociază slab cu metodele lipsite de îmbunătățire a proceselor pe care le-am acoperit deja. Autoritatea de a „personaliza” SAFe în contextul adecvat nu este disponibilă în cea mai mare parte echipelor reale cele mai bine poziționate pentru a recunoaște ceea ce nu funcționează.

Nicăieri în foaia de parcurs SAFe nu se referă de fapt la practici de bază ca tranzitorii. Dacă este un cadru de tranziție, atunci face o treabă destul de slabă de a furniza orice tip de plan de tranziție.

div . . Dacă petreceți ore și ore lucrând pentru a deveni certificat, certificarea devine o parte din propria dvs. valoare. O tranziție către ceva care seamănă mai puțin cu SAFe poate părea că amenință acea valoare. Nu pot da vina pe nimeni pentru obținerea certificării într-un piața locurilor de muncă unde contează certificările. Dar acei indivizi au o responsabilitate deosebită să acorde atenție dezavantajelor SAFe și posibilelor modalități de îmbunătățire sau de a se abate de la acesta.

Aceste probleme sunt în general experimentate

Nu sunt singur în exprimând multe dintre aceste critici – deși sper că am mers puțin mai departe în conectarea lor la practicile specifice din cadrul. Dacă sunteți în căutarea unor mărturii coroborate, iată câteva:

Ken Schwaber, co-dezvoltator al Scrum și-a exprimat îngrijorări serioase cu privire la SAFe încă din 2013.

Nicholas M. Chaillan , Ofițerul șef al forțelor aeriene din SUA, descurajează „utilizarea cadrelor rigide și prescriptive, cum ar fi Scaled Agile Framework (SAFe)”. cum să identifici falsul Agile.

Marty Cagan de la Silicon Valley Product Group explică modul în care SAFe este antitetic cu mentalitatea companiilor din Silicon Valley.

Rămâneți în siguranță acolo (nu SAFe)

În timp ce SAFe a primit cu siguranță o mulțime de critici , simțul meu personal este că este posibil ca această critică să nu fi ajuns la un public numeros dincolo de anumite cercuri online. Acest lucru este probabil mai ales atunci când este luat în considerare alături de numărul tot mai mare de companii care adoptă cadrul în fiecare zi.

Pentru mulți oameni, ideea că există ceva în neregulă cu SAFe – sau că este în conflict cu principiile Agile – poate fi complet nou.

O discuție sporită care vizează un public mai larg poate ajuta. Sper să abordez mai mult acest subiect în viitor și să detaliați ce alte alternative există.

Deocamdată, chiar dacă nu lucrați într-un mediu SAFe, nu este o scuză pentru a vă mulțumi . Preocupările pe care le-am prezentat aici ar trebui luate ca un avertisment mai larg – chiar și cele mai sensibile dintre idei pot fi ușor cooptate, corupte și confuze dacă nu acordați o atenție deosebită.