Scrum
Scrum on ketterä viitekehys, joka auttaa tiimejä käsittelemään monimutkaista työtä lyhyissä, iteratiivisissa sykleissä kiinteiden roolien, tapahtumien ja artefaktien avulla.
Scrum on ketterä viitekehys monimutkaisten tuotteiden kehittämiseen ja hallintaan, joka muotoutui alun perin ohjelmistokehityksessä ja on nykyään käytössä lukuisilla toimialoilla. Se perustuu empiirisen prosessinhallinnan ajatukseen: sen sijaan, että tehtävä suunniteltaisiin alusta loppuun etukäteen, tiimi työskentelee lyhyissä, kiinteissä aikalaatikoissa, joita kutsutaan sprinteiksi ja jotka kestävät tyypillisesti yhdestä neljään viikkoa. Jokainen sprintti päättyy käyttökelpoiseen työtulokseen, mikä luo tilaa palautteelle ja antaa tiimin säätää seuraavia askeleitaan. Tämä avoimuuden, tarkastelun ja mukautumisen yhdistelmä tekee Scrumista hyvän valinnan työhön, jossa vaatimukset ovat epävarmoja tai todennäköisesti muuttuvat.
Scrum määrittää kolme kiinteää roolia. Tuoteomistaja vastaa tuotteen arvosta ja ylläpitää tuotteen backlogia, priorisoitua listaa kaikesta tehtävästä työstä. Scrum master pitää tiimin työskentelyn viitekehyksen puitteissa, poistaa esteitä ja fasilitoi yhteistyötä ilman, että hän antaa tehtäviä suoraan. Kehitystiimi suunnittelee ja toteuttaa työn itsenäisesti. Neljä toistuvaa tapahtumaa antaa jokaiselle sprintille rakenteen: sprintin suunnittelu alussa, daily scrum nopeaan synkronointiin, sprintin katselmus rakennetun näyttämiseksi ja sprintin retrospektiivi tiimin yhteistyön parantamiseksi.
Scrum toimii parhaiten tehtävissä, joissa laajuus tai ratkaisu ei ole täysin selvä alussa, kuten tuotekehityksessä tai monimutkaisissa, monia sidosryhmiä sisältävissä projekteissa. Se eroaa Kanbanista kiinteiden aikalaatikoidensa ja määriteltyjen roolien osalta, kun taas Kanban nojaa enemmän jatkuvaan virtaukseen ilman kiinteitä iteraatioita. Verrattuna perinteiseen vesiputousmalliseen suunnitteluun sen etu on säännöllinen tarkastelu: virhearviot tulevat esiin varhain sen sijaan, että ne paljastuisivat vasta projektin lopussa. Käytännössä Scrum epäonnistuu harvoin itse viitekehyksen takia, vaan puolinaisen toteutuksen takia, esimerkiksi kun retrospektiivejä jätetään väliin tai backlog jää ylläpitämättä.
Käytännön esimerkki
Keskisuuri koneenrakennusyritys kehittää uutta ohjelmistoa tuotantolaitteidensa valvontaan. Viisihenkinen tiimi työskentelee kahden viikon sprinteissä: jokaisen sprintin alussa se valitsee kymmenen tärkeintä kohdetta noin 40 avoimesta backlog-merkinnästä ja synkronoi päivittäin 15 minuutin daily scrumissa. Kymmenen sprintin jälkeen, viiden kuukauden kohdalla, ensimmäinen käyttökelpoinen versio on valmis, sen sijaan että kehitys olisi kestänyt yhdeksän kuukautta ilman väliaikatuloksia, kuten tiimi oli alun perin suunnitellut. Retrospektiivit paljastavat, että epäselvät vaatimukset veivät tiimin kapasiteetista noin 20 prosenttia kolmen ensimmäisen sprintin aikana, joten tuoteomistaja alkaa siitä lähtien kirjoittaa täsmällisempiä backlog-kuvauksia.
Miten Leanshift auttaa
Ytimeltään sprintin retrospektiivi on vain toistuva Kaizen-sykli: tiimi pysähtyy, katsoo rehellisesti juuri valmistunutta työtä ja tekee tietoisen parannuksen työtapaansa ennen jatkamista. Tämä sopii Leanshiftin näkemykseen siitä, että parantaminen ei ole kertaluonteinen projekti vaan säännöllinen, arkityöhön rakennettu tapa. Tiimit, jotka elävät tällä tavalla, eivät paranna vain tuotetta, vaan kasvattavat lisää ihmisiä, jotka osaavat parantaa asioita itse.
Usein kysytyt kysymykset
Sopiiko Scrum vain ohjelmistokehitykseen?
Ei. Scrum sai alkunsa ohjelmistokehityksestä, mutta sitä käytetään nykyään markkinoinnissa, tuotekehityksessä, koulutuksessa ja muilla aloilla, aina siellä missä työ on monimutkaista ja vaatimukset voivat muuttua matkan varrella.
Miten Scrum eroaa Kanbanista?
Scrum etenee kiinteissä aikalaatikoissa, joita kutsutaan sprinteiksi ja joilla on määritellyt roolit ja tapahtumat, kun taas Kanban visualisoi jatkuvan työn virtauksen ilman kiinteitä iteraatioita ja keskittyy rajoittamaan, kuinka paljon työtä on kerrallaan kesken.
Tarvitseeko pieni tiimi oikeasti oman scrum masterin?
Ei välttämättä täysipäiväisenä roolina. Pienissä tiimeissä joku usein ottaa sen hoidettavakseen oman työnsä ohella; tärkeintä on, että fasilitointi ja itse viitekehys todella pidetään yllä.