Scrum pähkinänkuoressa

Scrum on vain työkalu. Tässä esiteltävä vakiomuotoinen Scrum on lähtökohta, josta on hyvä lähteä liikkeelle, kun aloitetaan ihan alusta. Pidempään yhdessä toiminut ketterä tiimi voi muokata Scrumia loputtomiin, tai vaihtaa toiseen työkaluun kuten Kanbaniin, tai Scrumbaniin. Prosessisuunnittelussa kannattaa ajatella ”Love the problem, not the solution” – rakasta ongelmaa, älä ratkaisua. Tällöin asiakkaan tarpeet pysyvät päällimmäisenä – eivät omat hienot ideat tai idealismit, joihin on aina niin helppo rakastua. Samaa tarkoituksenmukaisuutta ja jatkuvaa kehittämistä peräänkuulutettiin aiemmassa blogissani.

Määrämuotoinen Scrum prosessi on turvallinen ensimmäinen askel ketterään kehitystyöhön, missä isomman tiimin kesken rakennetaan pidemmän aikaa jotain uutta. Scrum ohjaa lyhyen ja keskipitkän aikavälin suunnitteluun, sekä säännölliseen palauteluuppiin niin sisällön, kuin työtapojen suhteen. Jos tehdään nopeampirytmistä ja reaktiivisempaa työtä, niin virtaustehokkuuteen ohjaava Kanban on parempi organisoitumismalli. Jos taas tehdään jotain pitkälle etukäteen määriteltyä, niin voidaan palautesykliä harventaa ja edetä enemmän vesiputousmallin kaltaisella prosessilla.

Scrum itsessään on paradoksi; samalla kun ketterät periaatteet vaativat yksinkertaisuutta, Scrum määrittelee melko mutkikkaan prosessin, jonka käytöstä, hienosäädöstä ja kehittämisestä on kirjoitettu lukemattomia kirjoja. Schwaberin prujussa vuodelta 1997 Scrum kuvattiin alkujaan ytimekkäästi:

  1. Ennen peliä analysoidaan tilanne ja tehdään projektisuunnitelma; mitä, kuka, milloin, mitä maksaa
  2. Pelin aikana pyöritetään Scrum sykliä
  3. Pelin lopuksi julkaistaan, dokumentoidaan ja vedetään yhteen miten projekti meni.

Ja nyt kaksikymmentä vuotta myöhemmin Cockburn taas pyrkii omalla The Heart of Agile kampanjallaan palauttamaan mieliin, että Scrumin ketterät periaatteet ovat yksinkertaisia:

  1. Kunhan tiimi tuottaa jatkuvasti lisäarvoa, niin prosessilla ei ole niin väliä
  2. Tiimi päättää miten toimitaan
  3. Arvioidaan aktiivisesti mitä ja miten toimitaan, sekä pyritään parantamaan
  4. On olemassa vastuuhenkilö, jonka vastulla on reagoida ilmeneviin esteisiin (Scrum Master)
  5. On olemassa vastuuhenkilö, joka päättää liiketoimintatavoitteet (Tuoteomistaja).

Ketterät periaatteet

Scrum perustuu ketteriin periaatteisiin, jotka ovat tiivistettynä:

  • Tiimin tuottama lisäarvo muodostuu usein ja säännöllisesti asiakkaalle toimitettavasta, toimivasta ohjelmistosta.
  • Asiakkaan prioriteetit saavat muuttua. Projektin edetessä opitaan lisää ohjelmistosta, käyttäjistä, sidosryhmistä ja toimintaympäristöstä. Tämän myötä on täysin ymmärrettävää, että lyhyen aikavälin tavoitteet muuttuvat. Toisinaan myös pitkän aikavälin tuotevisio muuttuu.
  • Kaikki projektiin osallistuvat ovat motivoituneita, innostuneita ja tasa-arvoisia. Vaikka projektissa seurataan tiettyä prosessia ja rooleja, niin aktiivinen kommunikaatio on tärkeämpää, kuin itse prosessit.
  • Ihminen on sosiaalinen eläin, joka kommunikoi tehokkaimmin kasvotusten. Tämän vuoksi olisi hyvä ajoittain tavata kasvotusten.
  • Työssä seurataan jatkuvan parantamisen sykliä, jolla pyritään parantamaan toimintaa, niin ohjelmiston, arkkitehtuurin, prosessien, yhteistyön, kuin motivaation ja innostuksenkin kannalta.
  • Pyri kaikissa edellä mainituissa yksinkertaisiin ratkaisuihin.

Suuresta pieneen

Sen sijaan, että iso joukko ihmisiä toteuttaa isoa asiaa pitkän aikaa, Scrumissa pieni joukko ihmisiä toteuttaa pientä asiaa lyhyen aikaa, mutta säännöllisesti integroiden kokonaiskuvan kirkastamiseksi.

KUVA: Pilko ihmiset 7 +/-2 hengen tiimeiksi

KUVA: Pilko asia niin pieniin osiin, että ne on mahdollista toteuttaa yhden iteraation aikana, yhden tiimin toimesta. Järjestä osat tärkeysjärjestykseen siten, että eniten lisäarvoa tuottavat ja vähiten työtä vaativat asiat tehdään ensin (weighted shortest job first)

 

KUVA: Pilko aika lyhyisiin 1-4 viikon iteraatioihin, joista jokaisen päättyessä demonstroit sidosryhmille koodin toiminnallisuutta aidossa ympäristössä

Scrum roolit

Scrum tunnistaa 3+1 roolia

  1. Tuoteomistaja vastaa tuotteen työjonon hallinnasta. Tuoteomistajan vastuulla on huolehtia, että tiimi tuottaa mahdollisimman paljon lisäarvoa sidosryhmille.
  2. Scrum Master auttaa tuoteomistajaa ja kehitystiimiä Scrum prosessin optimoinnissa, sekä poistaa esteet.
  3. Kehitystiimi on joukko aktiivisia ja yhteistyökykyisiä kehittäjiä, jotka rakentavat toimivan ohjelmiston ja rakentamista tukevan kehitysympäristön.
  4. Sidosryhmät ovat ulkoisia toimijoita, kuten loppukäyttäjät, hankehallinto tai muut Scrum tiimit.

Scrum prosessi

Scrum prosessissa on 4+1 vaihetta. Vaiheet ovat aikarajattuja, eivätkä koskaan mene yli ajan.

  1. Sprintin suunnittelu: Kehitystiimi valitsee tuotteen työjonon yläpäästä sen verran käyttötapauksia, kuin uskovat sprintin aikana saavansa toteutettua. He asettavat yhdessä sprintille sanallisen yhden lauseen mittaisen vision. Tämä tavoitevisio yhdessä valittujen käyttötapausten kanssa muodostavat sprintin projektisuunnitelman. Kesto 1h per viikko, eli jos 2vk sprintit, niin 2h suunnittelupalaveri.
  2. Daily Scrum: Tiimiläiset kertovat vuorollaan
    1) mitä saavuttanut edellisen dailyn jälkeen,
    2) mitä aikoo saavuttaa ennen seuraavaa dailya,
    3) mitä esteitä tavoitteelle on.
    max 15 minuuttia, teknisiä keskusteluita voi jatkaa dailyn jälkeen, mutta dailya ei venytetä.
  3. Tuotteen työjonon kirkastaminen: Tuoteomistaja, tiimi ja tarvittaessa paikalle kutsuttavat sidosryhmät pilkkovat ja tarkentavat tuotteen työjonolla seuraaville sprinteille priorisoituja käyttötapauksia. Tuoteomistajan tavoitteena on kirkastaa seuraavien 2-3 sprintin suunta. Tiimin tavoitteena on auttaa tuoteomistajaa tässä ja ymmärtää tuoteomistajan seuraavien sprinttien visiota. Tämä on luonnollista aikatauluttaa puoliväliin sprinttiä, eli 2 viikon sprintissä joka toinen viikko on sprintin suunnittelu ja joka toinen viikko työjonon kirkastaminen. Kesto 1h per viikko, eli jos 2vk sprintit, niin 2h kirkastuspalaveri.
  4. Sprinttikatselmointi: Demotaan ylätasolla projektin ulkopuolisille sidosryhmille, kuten loppukäyttäjille ja bisnesihmisille, mitä on saatu valmistuvassa sprintissä aikaan.
  5. Retrospektiivi: Scrum Master vetää tiimin avustuksella yhteen miten edellinen sprintti sujui. Saavutettiinko sprintin visio, valmistuivatko valitut käyttötapaukset, onnistuiko demo, mikä meni hyvin, missä on parannettavaa. Näistä valitaan muutama parannusehdotus seuraavaan sprinttiin kokeiltavaksi. Kesto 45min per viikko, eli jos 2vk sprintit, niin 1:30h retro.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *