Varo SAFe (Scaled Agile Framework for Enterprise), pimeyden epäpyhä inkarnaatio
… tai ehkä ei.
Jos haluat mieluummin SAFen puhuvan puolestasi, voit käyttää yllä olevaa linkkiä. Tarjolla on satoja sivuja dokumentaatiota, tunteja videoita, 15 erilaista kurssia ja paljon muuta. Jos se kuulostaa vähän paljon, teen parhaani selittääkseni SAFen toiminnan, kun käyn läpi jokaisen kohdan.
Korkeimmalla tasolla, nimeltään ”Portfolio”, SAFe kannattaa rahoittaminen toistaiseksi ”Arvovirrat” – jotka edustavat yleensä tuotetta, tuotelinjaa tai asiakastyyppiä. Lean Portfolio Management -toiminnolla (LPM), joka valvoo rahoitusta (todennäköisesti samat henkilöt, jotka ovat aikaisemmin vastanneet vesiputoustyylisistä projektibudjeteista), on kuitenkin yksinomainen toimivalta hyväksyä, mitkä Portfolio-eepokset (suuret aloitteet) siirtyvät kuhunkin virtaan. Eepokset eivät ole selityksiä ongelmasta, joka on ratkaistava. Ne ovat ennalta muotoiltuja ideoita siitä, miten nämä ongelmat voidaan parhaiten ratkaista.
Näemme heti merkkejä vanhan koulun ajattelutavasta, että joukkueet katsotaan ”toimitus” -toiminnoksi strategisen sijasta. tason ajattelijat keksivät ideoita, ja matalan tason tekijät toteuttavat nämä ideat. Ohitetaan mahdollisuus, että työn lähimpänä olevat henkilöt voivat parhaiten pystyä tekemään päätöksiä siitä. Karkean ajattelutavan välttäminen on ketterän ajattelun keskeinen tavoite, joka SAFe ei onnistu suorittamaan etänä.
Samanlainen ongelma nousee esiin uudelleen, kun tarkastelemme hieman alempaa tasoa.
SAFe kerää pienet tuotetiimit (usein Scrum-tiimit) ”Ketteriin julkaisujuniin” ”- tiimiryhmät, joissa on ylimääräinen hallintaroolien taso, joka ulottuu kutakin ryhmää kohtaan, jota kutsutaan” ohjelmatasoksi ”.
Yleensä nämä roolit haittaavat tiimien itsenäisyyttä. niiden tarjoaman arvon kanssa.
Näihin rooleihin kuuluu tuotepäällikkö (S) ystem Architect (SA) ja Release Train Engineer (RTE).
SA ja PM määrittelevät ja hajottavat suuremmat teokset (usein periytyneet yllä olevasta portfolioprosessista) ja siirtävät ne sitten joukkueet.
Tuotteen omistaja ja tiimi saattavat teoriassa pystyä priorisoimaan muut, pienemmät työt heille määrättyä työtä vastaan, mutta näillä ponnisteluilla on rajoitettu näkyvyys ja sisäänosto ylhäältä. Luonnollinen paine kohdella korkeimmasta pisteestä tulevaa työtä tärkeimpänä – vaikka jokainen tiimin jäsen uskoisikin, että muut esineet olisivat arvokkaampia. Tämän vuoksi tuotteen omistajan rooli supistuu tarinoiden kirjoittamiseen ja hyväksymiskriteerien tarkistamiseen sen sijaan, että se olisi ainoa vastuullisuus tuotejohtajuudelle, joka oli roolin alkuperäinen tarkoitus.
Järjestelmäarkkitehti ei ole lähellä todellista suunnittelutyötä, joten niiden toimittama arkkitehtisuunnitelma voidaan irrottaa työn todellisuudesta. Tämäntyyppiset roolit olivat tunnusmerkki suurille suunnitteluprojekteille, ja ne säilyivät hyvin SAFe: ssä.
Release Train Engineers määrittelee johdonmukaisen joukkueiden välisen prosessin ja poljinnopeuden sekä hoitaa monia operatiivisia tehtäviä. Viime kädessä tämä jättää vähemmän tilaa yksittäisille joukkueille muokata, parantaa tai kokeilla omia käytäntöjään millään tavalla, joka poikkeaa vakiintuneista standardeista.
Joskus kaikki nämä ongelmat toistuvat uudelleen lisäämällä ”Suuri” Ratkaisutaso ”- ryhmät ryhmäryhmistä, joilla on samanlaiset roolit kuin ohjelmatasolla, mutta jotka ulottuvat vapautusjuniin. Kun tämä tapahtuu, samat ongelmat todennäköisesti toistuvat, mutta ratkaisutaso näyttää olevan harvemmin paikallaan.
SAFe (usein) mukana Rally – LISÄÄ tiimin autonomian rajoittamista
SAFe on usein pakettisopimus projektinhallintaohjelmistoon Rally. Rally on sellainen ohjelmisto, jota voit odottaa yritys, joka käyttää SAFe-tekniikkaa – se on ylikuormitettu ominaisuuksilla, keskittymätön, hämmentävä, epävakaa ja sen vuoksi vaikea oppia ja käyttää.
Rallyn käyttöönoton arvoesitys johtajuudelle on, että he näkevät raportointi antaa heille yksinkertaisen, yhtenäisen kuvan th Edistyminen ja ongelmat koko yrityksessä.
Tämä tarkoittaa tietysti sitä, että kaikkien yrityksen jäsenten ei tarvitse vain käyttää Rallya, vaan heidän on käytettävä sitä johdonmukaisella tavalla. Jälleen tämä voidaan saavuttaa vain ylhäältä alas sanelemalla. Ralli ja työajattelu pakotetaan kaikille joukkueille heidän mieltymyksistään, kontekstistaan tai sisäänostostaan riippumatta. Koko tiedon kokoaminen vaatii uskomattomia ylimääräisiä arvioita ja seurantaa, mikä hidastaa kaikkea ja voi olla erittäin häiritsevää työn tosiasialliselle suorittamiselle.
Lisäksi ylätason raportointi ei ole edes erityisen hyödyllistä. Se keskittyy asioihin, joita Rally Track seuraa – mittareihin, kuten toimitettujen tarinapisteiden määrä (kirjaimellisesti muodostettu) tai korjattujen vikojen määrä (kauhea mitta ”tuotteen laadulle”).Jos johto jättää nämä tilastot huomiotta, niiden lisäämät yleiskustannukset ovat turhia. Jos he onnistuvat metriikkaan, tilastot hämärtyvät niin, että joukkueet näyttävät hyvältä ja jätetään yksin. Arviot ovat liian pehmustettuja, pieniä töitä liioiteltuja, ja tämä voi helposti johtaa luottamuksen hajoamiseen.
SAFe käyttää huonointa mahdollista tapaa hallita riippuvuuksia
A riippuvuus on tapaus, jossa tiimin on odotettava jotain tekemistä muualla, ennen kuin he voivat suorittaa oman työnsä loppuun. SAFe on rakennettu taaksepäin suuntautuvan asenteen ympärille, jonka mukaan riippuvuudet ovat muuttumaton tosiasia elämässä, joka tulisi hyväksyä ja hallita. Se jopa viittaa niihin joskus strategisena etuna. Todellisuudessa, kun ajattelet riippuvuuksia pahaksi – joka on minimoitava jokaisella mahdollisuudella – saatat huomata, että näitä mahdollisuuksia on runsaasti ja että niiden hyödyntäminen johtaa ensisijaisesti hyötyihin. Tässä on vain muutama ehdotus, joita SAFe korostaa liian vähän tai jättää kokonaan huomiotta:
- Kannusta sisäisten hankintojen kulttuuria, jossa yksi tiimi voi lähettää työn toisen tiimin koodikantaan tarvitsematta olla riippuvainen heistä pidemmälle sulautumisen hyväksyminen
- Tee tiimin jäsenille helppo väliaikaisesti tai pysyvästi vaihtaa tiimejä, kun se on järkevää tehdä
- Keskity ryhmien palkkaamiseen, jäsentämiseen ja kouluttamiseen omien tarpeidensa hoitamiseksi ilman ulkopuolista apua
Kuinka SAFe todella päättää hallita riippuvuuksia on keskittymällä enemmän suunnitteluun, prosessiin, hierarkiaan ja standardointiin. Ennakoitavasti tämä johtaa moniin kokouksiin, jotka häiritsevät kykyä saada työ tehtyä. Se asettaa tämän lähestymistavan yleisen käyttöönoton kautta, joka vaikuttaa koko organisaatioon kerralla. Ei huomioida, mitkä alueet olisivat voineet olla omavaraisia ilman ylimääräistä rasittavaa rakennetta.
SAFe on suunnattu liikaa suunnittelun ympärille
SAFe: n ydinominaisuus on ~ 10 viikon idea Ohjelman lisäykset (PI). Voit ajatella tällaisia valtavia sprinttejä, jotka sisältävät kaikki normaalit sprintisi.
Jokainen PI alkaa PI-suunnittelutapahtumalla, joka kestää noin kaksi päivää. PI-suunnittelu vaatii myös esisuunnittelua ja suunnittelun jälkeistä toimintaa ohjelmatasolla.
On varmasti arvokasta, että ihmiset kokoontuvat henkilökohtaisesti luomaan suhteita, jakamaan tietoa ja suuntautumaan tavoitteiden ympärille. Toisaalta tämän rajoitetun aikaikkunan käyttäminen 10 viikkosuunnitelman tekemiseen tietyistä käyttäjäkertomuksista ennalta määritettyjen ominaisuuksien perusteella ja sitoutumisen vaatiminen näihin suunnitelmiin on paljon vähemmän arvokasta.
Heti kun PI-suunnittelu päättyy, suunnitelmat, jotka on luotu rajoitetun ymmärtäminen ja lukuisat oletukset vanhentuvat heti kun jotain uutta opitaan. Joukkueita repeytyy jatkuvasti sen välillä, että pitäytyminen suunnitelmassa, jonka oppimisella ei ole järkeä, ja odotusten uudelleen suuntaaminen heidän yläpuolellaan olevista syistä ei välttämättä pysty ymmärtämään.
SAFe on suuntautunut äänenvoimakkuudelle, ei arvoa
Kaiken tämän keskittyen volyymimittareihin, arvioihin ja putkilinjan läpi tapahtuvaan työntekoon käsite siitä, mikä on todella arvokasta tai onnistunutta, menetetään helposti. Usein oletetaan, että enemmän ovelta lähetettyjä töitä on oltava ”arvo”, vaikka tuotteen kokemus todella kärsii ja käyttäjät eivät hyötyisi lisäominaisuuksista.
SAFe on tietoinen kritiikistä, jonka mukaan se ei ole arvokeskeinen ja on viime aikoina lisännyt dokumentaatioonsa ”suunnitteluajattelua”, ”asiakaslähtöisyyttä” ja muita käsitteitä kompensoidakseen. En ole vielä vakuuttunut siitä, että se tekee prosessissaan merkittäviä muutoksia, jotka todella antavat tilaa näille asioille ja se romahtaa edes ymmärtämällä heitä ensinnäkin.
Esimerkiksi SAFen määritelmä ”asiakkaille” jättää oven määrittelemään liike-elämän sidosryhmät tai ne, jotka rahoittavat arvovirtoja ”asiakkaina”. on hyvin erilainen kuin kaikkien (mukaan lukien rahoittajat) uudelleenohjaaminen keskittymään ohjelmiston tosiasiallisesti käyttävien loppukäyttäjien tarpeisiin, mikä on suunnitteluaikataulun ydin.
SAFe on tarpeettoman monimutkainen
SAFe: lla on luonnollinen etu, joka suojaa se kritiikiltä; Se on niin monimutkaista, että on vaikea ymmärtää täysin. Huolimatta ylimääräisestä ajasta, jonka olen viettänyt kehyksen tutkimiseen, luultavasti silti todennäköisesti menen väärin tai menetän joitain tärkeitä seikkoja. Monimutkaisuus on kuitenkin itsessään perusteltu huolenaihe. SAFe: lla on niin paljon kokouksia, tarkistuspisteitä, arvoja ja menetelmiä, että on periaatteessa mahdotonta saada kaikki yhdelle sivulle.
SAFe rajoittaa takautuvia näkymiä ja jatkuvaa parantamista
Roolit ohjelmatasolla ja yllä mainitut eivät voi osallistua kaikkiin joukkueen takautuviin näkymiin.Tämä tarkoittaa sitä, että ihmiset, jotka voivat todella muuttaa monia keskustelunaiheita, eivät kuule takautuvasti suoraan.
Tapa, jolla SAFe yrittää kompensoida tämän, ei ole riittävä.
PI-suunnittelu on ainoa kerta, jolloin jokaisella vapautusjunassa taataan olevan henkilökohtaisesti yhdessä. Valitettavasti se sisältää lyhyen retrospektiivin, joka liittyy vain itse suunnittelutapahtuman onnistumiseen.
SAFe sisältää ”Tarkasta ja mukauta” -tapahtuman jokaisen PI: n loppupuolella, mutta näyttää siltä, että se on melkein suunniteltu ohitettavaksi siitä, kuinka vaikeaa on koordinoida RTE: tä. Kun tapahtuma pidetään, tapahtuma pohjustetaan tarkistamalla – tietysti – viimeisen PI: n volyymitiedot. Lisäksi vain 30 minuuttia tapahtumasta varataan varsinaiseen retrospektiiviin, jossa asiat ovat esillä ja sovittu Jos tämä aika on jaettu tasaisesti kaikkien 100 hengen vapautusjunan jäsenten kesken, jokaisella osallistujalla on noin 18 sekuntia ~ 10 viikon välein tuoda esiin asioita tilanteessa, jossa niitä todella voidaan kuulla.
SAFe sisältää myös joitain muita elementtejä, kuten ”arviointitaulukot”, joissa joukkueita tutkitaan laajemmin, mutta ne osoittavat vahvasti, että SAFe-käytäntöjä noudatetaan, riippumatta siitä, ovatko ne tehokkaita vai eivät.
SAFe hajottaa käsitteitä, jotka se yhdistää
Avaimen osa SAFe-ohjelmaa, johon en ole vielä puuttunut, on olemassa olevien käsitteiden, kuten Scrum, Kanban, Lean Product, Lean UX ja DevOP, yhdistäminen.
Jos et tunne, suosittelen tutkimaan jokaista konseptia. ajan mittaan itsenäisesti pikemminkin kuin kaikki kerralla. Monet ovat itse arvokkaita, mutta SAFe ei tee hienoa työtä tosiasiallisesti niiden syntetisoinnissa ja voi joskus lisätä hämmennystä. Kohta:
SAFe kannattaa rutiininomaisesti sitä, miten sen käytännöt noudattavat Lean-Agile-periaatteita. Temppu on, että Lean-Agile ei itse asiassa viittaa Lean- tai Agile -periaatteisiin.
Sen sijaan ”Lean-Agile Principles” on SAFe: n oman suunnittelun luominen. Tämä uusi ”periaatteiden” sarja vääristää omaksuttavia käsitteitä. Esimerkiksi päätösten hajauttamista koskeva sivu (sijoittui kaikkien periaatteiden alimmalle sijalle) hajottaa itsensä hienovaraisesti korostaen päätöksenteon keskittämisen merkitystä monissa käyttötapauksissa. Muilla luetelluilla periaatteilla on samanlaisia ongelmia. Henkilölle, joka saa kaikki nämä tiedot kerralla, alkuperäisten käsitteiden todellinen merkitys voi kadota.
SAFe ei ole ketterä
Tähän mennessä monet SAFe-tavoista ovat ketterän ajattelutavan kanssa yhteensopimattoman pitäisi olla melko selvä. Se on suunnitelmakeskeinen, byrokraattinen, monimutkainen, sisältää paljon usein tarpeettomia prosesseja, antaa tiimille itsenäisyyden ja paljon muuta.
Mutta onko väliä onko SAFe ketterä, kun todella välitämme tehokkuudesta ?
Kyllä. Se tekee.
Ketterät periaatteet ovat vain ketteriä periaatteita, koska ne tunnustettiin yleisesti tehokkaiksi. Tämä ajattelu resonoi laajemman harjoittajien yhteisön kanssa, minkä vuoksi liike alun perin lähti liikkeelle. Jos ajattelet ketteryyden olevan tehokkuuden ennustaja (usko oletettavasti jonkin SAFe-kiinnostuksen takana), sillä on melko paljon merkitystä, jos SAFe on yhdenmukainen ketterän ajattelun kanssa. Ihmisten harhaanjohtaminen ostamiensa asioiden suhteen on huono asia, eikä ole väärin kutsua sitä esiin.
Entä kaikki tapaustutkimukset, joissa SAFe: n osoitetaan toimineen?
On olemassa noin 40 tapaustutkimusta onnistuneesta SAFe-käyttöönotosta osoitteessa scaledagileframework.com. Epäonnistumisia koskevat tapaustutkimukset puuttuvat selvästi. Toisin kuin lyhenne, SAFe sisältää samanaikaisia muutoksia valtavaan uuteen prosessiin valtavassa ekosysteemissä – valtava riski. Ellei kullakin näistä 40 menestyneestä yrityksestä kullakin ole 11 250 sertifioitua SAFe-ammattilaista, on olemassa useita yrityksiä, joista emme kuule.
En myöskään laita liikaa varastoa tapaustutkimuksiin, jotka tekevät olla olemassa. Vaikka volyymimittarit, joihin he keskittyvät, olivat todella arvokkaita, on helppo valita muutama tilasto, joiden perusteella näyttää siltä, että asiat menivät hyvin.
Jos haluat keskittyä tiettyyn esimerkkiin, katsotaanpa ote. FitFitin SAFe-toteutuksen tapaustutkimuksesta:
Vuonna 2016 kuluttajateknologiayritys Fitbit julkaisi markkinoille neljä uutta tuotetta, jotka ja lähetti yli 22 miljoonaa laitetta. Suurimman tuotemäärän toimittaminen vuodessa johtuu osittain yrityksen sitoutumisesta ja onnistumisesta ottaa käyttöön SAFe® (Scaled Agile Framework®) keinona skaalata tiimi tavoitepäiviin.
© Scaled Agile, Inc.
Tässä Fitbitin osakekurssi viimeisen viiden vuoden ajalta:
Jee… vuosi 2016 näyttää hyvältä vuodelta Fitbitille.
Emme todellakaan voi liittää Fitbitin kaatumista SAFe: een adoptio ja käytettävissä oleva tieto.Mutta jos yritys pystyy kamppailemaan niin paljon ja silti tervehtii SAFe-hyväksymistä tuotepäätösten reagoivuuden parantamiseksi, kapenen silmiäni muutama astetta enemmän tarkastellessani muita tapaustutkimuksia.
Siirtymävaihe on kuitenkin okei, eikö?
Jos olet joku, joka tekisi tämän argumentin, sinun on ajateltava, että SAFe on siirrettävä pois. Tältä osin olemme samaa mieltä!
Siirtymiseen pääsemiseksi meidän on tietysti vietettävä jonkin aikaa osoittamalla osia, jotka eivät toimi kunnolla.
Onko se jotain mitä olet olet viettänyt paljon aikaa?
Vaikka olisitkin, SAFe on perustettu tavalla, joka estää sinua todella siirtymästä. Auktoriteetti, jonka se antaa johdon käsiin, toimii ylhäältä alas ohjaavan mentaliteetin legitimoimana. Tämä yhdistää huonosti pariksi jo käsittelemämme prosessin parantamisen menetelmät. Valtuutta ”räätälöidä” SAFe sopivaan asiayhteyteen ei useimmiten ole käytettävissä varsinaisille tiimeille, jotka pystyvät parhaiten tunnistamaan, mikä ei toimi.
Se ei missään SAFe-etenemissuunnitelmassa viittaa mihinkään Jos se on siirtymäkehys, se tekee melko huonoa työtä tarjotessaan minkäänlaista siirtymäsuunnitelmaa.
Yli keskittyminen sertifikaatteihin vahingoittaa myös kehyksen joustavuutta . Jos vietät tuntikausia sertifikaatin saamiseksi, sertifioinnista tulee osa omaa arvoa. Siirtyminen johonkin, joka näyttää vähemmän SAFe: lta, saattaa tuntua siltä, että se uhkaa tätä arvoa. En voi syyttää ketään siitä, että hän on saanut sertifikaatin työmarkkinat missä sertifikaatit ovat tärkeitä. Mutta näillä henkilöillä on erityinen vastuu kiinnittää huomiota SAFe: n haittoihin ja mahdollisiin tapoihin parantaa tai poiketa siitä.
Nämä ongelmat kokevat laajasti
En ole yksin ilmaisemalla monia näistä kritiikoista – vaikka toivon, että olen mennyt hieman pidemmälle yhdistämässä niitä puitteiden erityisiin käytäntöihin. Jos etsit vahvistavia todistuksia, tässä on muutama:
Ken Schwaber, Scrum-kehittäjä, ilmaisi vakavan huolensa SAFe-ohjelmasta jo vuonna 2013.
Nicholas M. Chaillan , Yhdysvaltain ilmavoimien ohjelmistojohtaja, kannustaa ”käyttämään jäykkiä, ohjeellisia kehyksiä, kuten Scaled Agile Framework (SAFe).”
Forbesin avustaja Steve Denning kehottaa SAFea ”erityisen huolestuttavaksi” artikkelissaan kuinka havaita väärennetty ketterä.
Marty Cagan Piilaakson tuoteryhmästä kertoo, kuinka SAFe on vastakohtainen Piilaakson yritysten ajattelutavan suhteen.
Pysy turvassa siellä (ei SAFe)
Vaikka SAFe on varmasti saanut paljon kritiikkiä Henkilökohtainen käsitykseni on, että tämä kritiikki ei ehkä ole saavuttanut suurta yleisöä tiettyjen verkkopiirien ulkopuolella. Tämä on erityisen todennäköistä, kun otetaan huomioon kasvava määrä yrityksiä, jotka ottavat kehyksen käyttöön päivittäin.
Monille ihmisille ajatus siitä, että SAFe: ssä on jotain vikaa – tai että se on ristiriidassa ketterien periaatteiden kanssa – voi olla täysin uusi.
Lisääntynyt keskustelu laajemmalle yleisölle voi todennäköisesti auttaa. Toivon koskettavan tätä aihetta enemmän tulevaisuudessa ja yksityiskohtaisesti, mitä muita vaihtoehtoja siellä on.
Toistaiseksi, vaikka et työskentele SAFe-ympäristössä, se ei ole tekosyy tyytymättömyyteen. . Tässä esittämiäni huolenaiheita on pidettävä laajempana varoituksena – jopa järkevimmätkin ideat voidaan helposti valita, vioittua ja sekoittaa, jos et kiinnitä erityistä huomiota.