Kuvittele, että sinulla on 3 ketterää tiimiä, jotka työskentelevät Scrumin mukaan, ja nyt haluat skaalata – Scrum ei enää riitä. Mikä on seuraava askel? Tätä varten on olemassa erilaisia kehyksiä, kuten seuraavat. SAFeNexus ja monet muut. Tänään tarkastelemme LeSS:ää lähemmin.
LeSS on SCRUM (määritelmä)
The LeSS-kehys pyrkii soveltamaan Scrumin periaatteita ja ihanteita suuryrityksissä mahdollisimman yksinkertaisesti määriteltyjen sääntöjen ja ohjeiden avulla. Yksinkertaisuutensa vuoksi LeSS on saanut määritelmän tai leiman "tuskin riittävä" kehys –, mutta tämä ei tarkoita, että sitä pitäisi asettaa negatiiviseen valoon.
7 LeSS-kehyksen edut
LeSS:n peruslähtökohtana ei ole luoda uutta kehystä. Sen sijaan Scrumin periaatteita sovelletaan moniin tiimeihin.
Joitakin etuja, jotka liittyvät LeSS voidaan saavuttaa:
- Alhaisemmat täytäntöönpanokustannukset ottamalla käyttöön käytäntöjä, joita tiimit jo käyttävät Scrumissa.
- Tuotteen omistajajoka ymmärtää puitteet ja periaatteet ja toimii sillanrakentajana liiketoiminnan ja teknisten tiimien välillä.
- Sillä Tuotteen toimitus, vähemmän ihmisiä tarvitaan. LeSS ei lisää eksponentiaalisesti rooleja ja yleiskustannuksia.
- Se tarjoaa koko tuotteen näkymä painopistealueella
- The Ryhmät ovat suorassa yhteydessä asiakkaan ja muiden sidosryhmien kanssa
- Jatkuvat parannukset edistetään säännöllisillä verkkokokouksilla ja muilla tapaamisilla, jotka ovat Agilen-manifestin perusprosesseja.
- Monille organisaatioille LeSS-lähestymistapa Scrum-tiimien skaalaamiseen voi olla seuraava looginen askel matkalla kohti ketterää skaalautumista..
Ennen kuin menemme syvemmälle, lyhyt huomautus. Meillä oli hiljattain 11 kansainvälistä ketterien menetelmien asiantuntijaa vieraana webinaarissa –, jonka aiheena oli kysymys: Miten ketterät menetelmät skaalataan oikein?
Tuloksena on tämä upea videotallenne (englanniksi), jossa käsitellään muun muassa seuraavia kysymyksiä:
- Onko parempi aloittaa alhaalta ylöspäin vai ylhäältä alaspäin?
- Miten saat johtajat sopimaan yhteisestä visiosta?
- Miten valita oikea ketterä kehys – ja miksi se ei oikeastaan ole niin tärkeää?
Lämmin suositukseni: Käykää katsomassa! Siihen menee suhteellisen kauan aikaa, mutta se on jokaisen minuutin arvoinen.
Miten LeSS on jäsennelty? Määritelmä
Määritelmän mukaan Large Scale Scrum rakentuu periaatteille, kehyksille, ohjeille ja kokeiluille. Kuvitus (lähde: LeSS:n verkkosivusto) osoittaa sen. Selitetään tämä esimerkin avulla:
Periaatteet: Ryhmä X kehittää matkapuhelinta. Läpinäkyvyyden periaate on heille tärkeä. Siksi he työskentelevät avoimesti ja tekevät säännöllisesti päiväkirjoja. Toisaalta he haluavat selvittää, mistä matkapuhelimen valmistuksen kannalta tärkeät materiaalit tarkalleen ottaen tulevat, jotta he voivat myöhemmin kertoa tästä avoimesti asiakkailleen. Läpikotaisin läpinäkyvyyttä.
puitteet: Samaan aikaan he työskentelevät jatkuvasti luodakseen puitteet, jotka tekevät SCRUM-kehyksestä ihanteellisen yhdessä ketterät arvot määrittelee: Avoimuus, rohkeus, kunnioitus, keskittyminen ja sitoutuminen.
Ohjaavat periaatteet: Kehittämistä ohjaavia periaatteita ovat tuotevisio, tuotteen tekniset vaatimukset sekä tapa työskennellä yhdessä tiimissä.
Kokeet: Kun epävarmuustekijöitä ilmenee, olemme kokeilualueella, jossa on kyse testaamisesta ja kokeilemisesta. Esimerkiksi jos haluamme kehittää uuden ominaisuuden tai tavoitella täysin uutta kohderyhmää. (Lähde: Kokeilemme, miten voimme tehdä uusia kokeiluja, kunhan emme jouduta käyttämään niitä: LeSS:n verkkosivusto)
LeSS:n 10 periaatetta
LeSS määritelty 10 periaatteet. Ne auttavat –:tä, jos pysymme esimerkissämme – kehittää matkapuhelimen, joka vastaa parhaiten asiakkaan arvoja ja ajatuksia. Tässä on luettelo 10 periaatteesta yhdellä silmäyksellä:
- Suuren mittakaavan Scrum on Scrum: Matkapuhelinta ei voi kehittää vain yksi vaan useampi tiimi, jotta asiakas on tyytyväinen ja kehitysaika on kohtuullinen.
- Empiirinen prosessinohjaus: Matkapuhelimen yksittäisiä toimintoja mukautetaan ja tarkistetaan jatkuvasti lyhyen aikavälin kokemusten perusteella.
- Avoimuus: Tiimimme X päättää jakaa viikoittaiset tiimitavoitteet avoimesti ja läpinäkyvästi sisäisellä foorumillaan tästä lähtien. Tämä auttaa valtavasti ymmärtämään, minkä parissa kaikki todella työskentelevät.
- Enemmän vähemmällä: Periaatteessa pitäisi kokeilla uusia ideoita ja oppia niistä, ennen kuin laaditaan pysyviä sääntöjä ja lisätään näin "painolastia".
- Kokonaisvaltainen tuotekeskeisyys: Tiimeillä on vielä suurempi taipumus alioptimoida tavoitteensa kuin yksilöillä. Siksi tiimien suurin haaste on integroida työnsä tuotteeksi. Koko tuotteen "tarkoituksen" pitäisi siis olla mahdollisimman selkeä. Tiimeillä ja yksilöillä on näin ollen valtuudet määritellä itse tarpeen mukaan asianmukaiset osatavoitteet.
- Asiakaskeskeisyys: Vain suoraan asiakkaan kanssa työskentelevät tiimit voivat maksimoida tuotteen todellisen arvon. Valitettavasti organisaatioilla on taipumus irrottaa tiimit asiakkaasta heti, kun ne alkavat kasvaa. Tämän vastapainoksi asiakkaat kutsutaan säännöllisesti tiimikokouksiin esimerkiksi antamaan palautetta.
- Jatkuva parantaminen kohti täydellisyyttä: LeSS on syvällinen muutos monille organisaatioille. Huomaa, että se ei automaattisesti tarkoita parannusta. LeSS antaa organisaatiolle mahdollisuuden alkaa kehittyä paremmaksi –, ja siitä lähtien on optimoitava jatkuvasti. LeSS on prosessi!
- Lean-ajattelu: LeSS korostaa ennen kaikkea itse tapahtumapaikan (Gemba) näkemistä, kolmivaiheista oppimiskäsitystä. ShuHaRi (Shu = jäljitellä, Ha = vaihdella, Ri = määritellä omat säännöt) ja ihmisten kunnioittaminen.
- Systeemiajattelu: Kaikki toimet, muutokset ja parannukset olisi aina ajateltava järjestelmällisesti tai järjestelmän mukaisesti, jotta tavoitteet voidaan saavuttaa. Esimerkki: Jos tarjoan teoriassa taloudellisia bonuksia yhdessä tiimissä –, mitä se tarkoittaa muille tiimeille (eli muulle organisaatiojärjestelmälle)?
- Jonoteoria: Perusajatuksena on, että ohjelmistomaailmassa muodostuu paljon näkymättömiä jonoja (esim. vaatimusasiakirjat, testaamattomat ohjelmistot), emmekä juuri välitä näiden jonojen optimaalisesta käsittelystä. Tiesitkö esimerkiksi, että kun resurssin käyttöaste nousee 50%:stä 90%:hen, uusien tehtävien odotusaika ei karkeasti ottaen kaksinkertaistu vaan moninkertaistuu? Määrittele siis keskeneräisen työn (WIP) rajoitukset, vältä monitehtäväisyyttä ja suuria työpaketteja.
LeSS-kehykset
LeSS tarjoaa kaksi kokoonpanoa: Perus LeSS osoitteessa Kahdesta kahdeksaan joukkuetta (10-50 henkilöä) ja LeSS Valtava osoitteessa Yli kahdeksan joukkuetta (50-6000 ihmistä ja enemmän).
Lähde: Less.works
On suositeltavaa aloittaa Basic LeSS:llä kokeilemalla, hankkimalla kokemusta ja saamalla palautetta, ennen kuin siirryt suoraan LeSS Hugeen. LeSS Hugen käyttöönotossa on kaksi ehdotettua lähestymistapaa:
- Aloita yhdellä vaatimusalueella kerrallaan laajemman tuotteen sisällä ja keskity aluksi vain siihen.
- Tai laajenna vähitellen tiimin työmäärää, Määritelmä valmis ja Tuotteen määritelmä.
Tällä tavoin yritys voi kerätä tiimikokemusta LeSS:stä, laajentua yhdellä tuotealueella, saavuttaa alkuvaiheen –-menestyksen ja saada näin johdon tuen ennen LeSS:n laajentamista koko yritykseen.
Muuten, lyhyt huomautus ketterän muutoksen yhteydessä: Haluatko varmistaa, että olet tällä hetkellä oikeat prioriteetit ketterässä Muutos?
Tee sitten kypsyystarkastuksemme ketterää muutosta varten – kestää vain 3 minuuttia. Saat jopa vertailuluvun, joka perustuu yli kolmesataan muuhun osallistujaan. Katso painike
Roolit ja suunnittelu LeSS:ssä
Basic LeSS keskittyy tiimiin ja tärkeimpiin Scrum-rooleihin:
- Scrum Product Owner, joka vastaa tuotteen visiosta ja suunnasta.
- Scrum-kehitystiimit, jotka vastaavat tuotteiden luomisesta ja toimittamisesta.
- Scrum Master, joka tukee tiimiä jatkuvassa parantamisessa.
- Johtajan rooli ja se, miten hän tukee tiimiä jatkuvan parantamisen ja itsenäisyyden esteiden tai "esteiden" poistamisessa (SCRUMin laajennus).
Huge LeSS täydentää Basic LeSS:ää seuraavilla rooleilla:
- LeSS Huge Regional Product Owner tukee tuoteomistajia ja on ratkaisevan tärkeä tekijä liiketoimintavaatimusten (rahoitus jne.) ja kehitystiimien yhdistämisessä.
- Area Product Owner on erikoistunut asiakaslähtöisiin tehtäviin ja toimii tuoteomistajana tuotekeskeisissä ominaisuustiimeissä.
Useimmat Agile-valmentajat kulkevat ympyrää.....
...ja hoitaa pinnallisia oireita. On aika käyttää psykologiaa – kestävään ajattelutavan muutokseen.
"Miksi minulta kestää joskus tunteja valmistella yksinkertainen retrospektiivi?"
Kokoukset LeSS:ssä
The Tuotekannan tarkentaminen (PBR) Kokous
PBR-kokouksissa laajennetaan sprintin suunnittelua painopistealueiden välillä rinnakkaisten LeSS-sprinttien toteuttamisen avulla. Näiden kokousten jatkuva järjestys on tarpeen jokaisessa sprintissä, jotta voidaan ymmärtää, keskustella ja tarkentaa elementtejä ja valmistautua tuleviin sprintteihin. PBR-kokousten päätoiminnot ovat seuraavat:
- Epics –:n luominen eli suurten yhteensopivien aiheiden klusterointi; esimerkissämme tämä olisi suunnittelu- ja käytettävyysryhmän sprinttien yhdistäminen.
- Avoimien kysymysten selventäminen ja niihin vastaaminen: Kaikilla pitäisi olla sama käsitys tuotteesta ja asiakkaan ja kollegoiden ajatuksista.
- Käyttäjätarinan koon, riskien ja riippuvuuksien arviointi: Yksittäisten aiheiden johtaminen ja yksityiskohtainen suunnittelu.
The Sprintin arvostelu
Vastine Scrumille: Sprinttiarviointi on sprintin lopussa pidettävä kokous, jossa arvioidaan tehtyä työtä suhteessa sprintin tavoitteeseen. Kyse on itse tuotteesta. Edistyminen tehdään näkyväksi ja tunnistetaan uusia toiminta-alueita. Se tekee tuotteeseen ja tavoitteeseen liittyvästä edistymisestä läpinäkyvää.
The Takautuva
Samanlainen kuin Scrum: Retrospektiivi on kokous, jossa käsitellään tiimin yhteistyötä. Kyse on tiimin sisäisen yhteistyön parantamisesta ja siten prosessien ja sisällön parantamisesta. Kyse on myös yksittäisten kehittäjien välisestä vuorovaikutuksesta, Scrum Masterin työstä ja viestinnästä tuoteomistajan kanssa. Tämän vuoksi retrospektiivi on tärkeä osa jatkuvan parantamisen prosessia (CIP).
Laajamittaisessa Scrumissa suositellaan toisinaan "retron retrojen" toteuttamista, eli useiden tiimien kesken.
Suuren mittakaavan Scrum – Scrum Master Ratio
Kuinka monta tiimiä Scrum Masterilla pitäisi olla? Voidaan väittää, että yksi Scrum Master tiimiä kohti on paras –, vaikka tämäkin on –. Haitat on. Pääsääntöisesti suuressa mittakaavassa Scrum Master -suhde on 1:1-1:3 – Scrum Masterilla on yhdestä enintään kolmeen tiimiä.
Milloin Large Scale Scrum LeSS on oikea Agile-menetelmä?
Large Scale Scrumia voidaan käyttää, jos työskentelet jo SCRUMin kanssa ja haluat skaalata Scrumia. Mutta myös löytää tasapaino itseorganisoitumisen ja sääntöjen välillä.
Bas Vodde sanoi kerran, että hän ja Craig Larman katson, että LeSS on erittäin hyvä lähestymistapa, koska se osuu sopivaan pisteeseen, jossa ohjausta annetaan niin paljon kuin on tarpeen ja niin vähän kuin mahdollista.
Scrumin tavoin se on vain prosessikehys, jonka sitä käyttävät tiimit voivat edelleen suunnitella hyvin yksilöllisesti ja monipuolisesti. Tämä väite vaikuttaa uskottavalta ja erottaa Large Scale Scrumin (LeSS) itse asiassa joistakin muista skaalautuvista kehyksistä.
Kuvitus: Sweet Spot
Vertailu: Large Scale Scrum vs. Scrum
LeSS perustuu Scrumiin, jotta sen käyttöä voidaan tukea laajemmassa kontekstissa ja skaalata sitä suurempiin organisaatioihin ja yhden tiimin ulkopuolelle. Näin ollen ei ole kysymys joko tai -vaihtoehdosta. LeSS on SCRUMin laajennus. LeSS:n käyttöönottoon tarvitaan siis aina SCRUM. On järkevää ottaa ensin käyttöön SCRUM ja siirtyä sitten LeSS:ään.
Vertailu: Large Scale Scrum vs. Scaled Agile Framework SAFe®.
Vaikka LeSS on yhä suositumpi yrityksissä, joissa on suuria ohjelmistokehitystiimejä, myös muut skaalautuvat ketterät kehykset, kuten Scrum of Scrum tai Scrum @ Scale, ovat kasvattaneet merkitystään. Yksi johtavista kehyksistä on Scaled Agile Framework® (SAFe) (skaalattu Agile-kehys®).
Large Scale Scrumin ja Scaled Agile Framework SAFe®:n välillä on monia yhtäläisyyksiä. Molemmat lähtevät esimerkiksi liikkeelle Scrum-tiimin skaalaamisesta ja sellaisten periaatteiden sisällyttämisestä kuin lean-ajattelu, jatkuva parantaminen ja asiakaskeskeisyys.
3 Suuren mittakaavan Scrumin ja skaalautuvan Agile-kehyksen SAFe®:n keskeiset erot.
- Organisaatio: LeSS keskittyy organisaatiorakenteen yksinkertaistamiseen pysymällä joustavana ja mukautuvana.
- Roolit: SAFe-ohjelmassa on lisää rooleja (joidenkin mielestä tästä syystä enemmän "päällekkäisyyksiä"), kuten Release Train Engineer (RTE), Solution Train Engineer (STE) ja Epic Owners.
- Toteutus: Scaled Agile SAFe® -kehys sisältää prosesseja, artefakteja ja organisaatiomuutoksia, joita jotkin organisaatiot eivät ehkä pysty ottamaan käyttöön. On siis aina harkittava, mikä kehys sopii sinulle ja organisaatiollesi.
Suuren mittakaavan Scrumin onnistunut käyttöönotto
Suuren mittakaavan Scrumin menestyksekäs käyttöönotto edellyttää perinteisten olettamusten rikkomista ja yritysrakenteen muuttamista – kaikkine räjähdysalttiine mahdollisuuksineen "pomotasolla" ja "kasvojen menetyksineen", joita vastaava muutos tuo mukanaan.
Lähtökohtana on siis, että kaikki ilmoittavat olevansa valmiita tähän muutokseen – ks. myös kohta Muutoksenhallintamalli Kotterin mukaan tai artikkelimme aiheesta Agile-muutoksen etenemissuunnitelma.
Luo houkutteleva visio –:n saavuttamiseksi ja käynnistä useita muutosprojekteja kerralla kokeilun hengessä.
Kun alkuperäinen tavoite on saavutettu, muutos on tehty, ja organisaatio sopeutuu uuteen vallitsevaan tilanteeseen, kunnes seuraava muutos on edessä.
Tämä klassinen lähestymistapa on samankaltainen kuin peräkkäiset ja "Big Batch -lähestymistapa (ks. Kuva) ohjelmistokehityksessä, jossa muutokset ovat poikkeus, jota valvovat tiukasti valvontaelimet.
LeSS:n käyttöönotossa ei ole muutosaloitetta, joten muutosjohtajia ei ole. LeSS:ssä muutos on jatkuvaa kokeilujen ja parannusten kautta – muutos on status quo.
Mitkä ovat onnistuneen täytäntöönpanon vaiheet?
1. tiimikulttuurin muuttaminen, mukauttaminen tai muuttaminen.
Suosittelemme aloittamaan ensin Scrum-tiimillä, kunnes tiimi ja organisaatio ovat saaneet riittävästi kokemusta uudesta ketterästä kulttuurista ja vastuulliset päättäjät aloittavat seuraavan vaiheen. Tämä vähentää myös harhaanjohtavan kehityksen riskiä.
2. tiimien sisäisen yhteistyön parantaminen
Useiden tiimien skaalautuva työskentely yhden tuotteen parissa edellyttää ketterien käytäntöjen käyttöönottoa. Erityisen tärkeitä ovat käytännöt, jotka helpottavat tiimien keskinäistä koordinointia. Ensimmäisten tiimien on vielä kokeiltava paljon edelläkävijöinä muulle organisaatiolle.
Jos tiimit todella irrotetaan muusta organisaatiosta, ne voivat edetä siinä vastaavasti nopeasti. Tämä voidaan tehdä nopeammin ja pienemmällä riskillä hallittavissa olevissa puitteissa.
3. muutokset yritysrakenteessa
Ketterän organisaation kasvun jatkuminen edellyttää uudelleenjärjestelyjä kaikilla tasoilla. Viimeistään nyt muutoksen käynnistäjän on otettava mukaan johto. Kaikki tiimien ja ylimmän johdon väliset tasot haastetaan –, ja organisaatiorakenteesta tulee hyvin ohut. Tämä on luultavasti prosessin "kivuliain" osa, erityisesti johdolle.
4. muutos yrityskulttuurissa
Soveltamalla Scrum- ja LeSS-kehyksiä ja asianmukaisia ketteriä käytäntöjä yrityksen kaikilla osa-alueilla saavutetaan ketterän kulttuurin oppiminen koko organisaation tasolla. Prosessi ei koskaan pysähdy, sillä optimaalista ketterää organisaatiota ei ole olemassa.
Agile-siirtymä Scrumin, LeSS:n ja LeSS Hugen avulla edellyttää kaukonäköistä strategiaa. Siksi siihen olisi liitettävä asianmukaista neuvontaa ja koulutusta.
Jos olet vielä etsimässä sopivaa retrotaulua, artikkelimme voi auttaa sinua aiheen kanssa: Vertailun parhaat retrolevyt.
