Ketterä kehittäminen ja julkishallinto tuntuivat aluksi epäsopivalta yhdistelmältä. Ketterässä menetelmässä vältetään nimittäin kaikenlaista pikkutarkkaa toimintojen hiomista, jossa julkishallinnoissa ollaan yleensä melko lahjakkaita.

DriveTurun hankeväki valitsi uuden verkkopalvelun kehittämisen ketteräksi menetelmäksi Scrumin, jossa jokaisen ajallisesti rajatun prosessin jälkeen (sprint) käydään läpi tehdyt asiat ja tehdään palautekierros (retrospective). Ketterässä menetelmässä on ollut puolensa: toteutukset ovat olleet tehokkaita viikon tai kahden rykäisyjä, joiden päätteeksi tarkastellaan tehtyjä toiminnallisuuksia.

TFO:n sivut ovat upea esimerkki siitä, miten julkishallinnossakin venytään ketteriin mittoihin. Tarvittiin vain osaavat kumppanit ja taitava työryhmä. Ketterä malli ei kuitenkaan ole sateentekijä. Näin neljännen sprintin kynnyksellä uskallan arvioida tämän kehittämisen menetelmän mielestäni neljää tärkeää askelta:

1. Aikataulu

Haastavaa ketterässä on, että vaikka sprinttiin on määritelty tietty määrä tehtäviä ja niitä seurataan päivittäisissä pikapalavereissa (daily scrum) pitkin viikkoa, niin mitä jos tehtävä ei valmistukaan? Ei, se ei automaattisesti siirry seuraavaan sprinttiin. Milloin sitä sitten jatketaan? Ei välttämättä koskaan, koska seuraava askel riippuu priorisoinnista.

2. Priorisointi

Yksityiskohtaisen vaatimusmäärittelyn sijasta olemme laatineet käyttäjätarinoita, joissa kerrotaan miksi joku toiminnallisuus halutaan tehdä, miksi se on tärkeä ja miten käyttäjä toimii, esimerkiksi ”sisällöntuottaja lisää uutisen etusivulle”. Jokaisen toiminnallisuuden kohdalla on pitänyt pystyä päättämään, mitkä kaikki tehdään ja missä järjestyksessä. Sprintillä voi olla ylemmän tason tavoite esimerkiksi ”some-toiminnallisuudet ovat valmiita ja uutisia voi nostaa etusivulle”.

3. Kyseenalaistaminen

Joka sprintin päätteeksi järjestetään katselmus ja retrospektiivi. Tässä epämuodollisessa palaverissa katsotaan, mitkä asiat menivät hyvin ja mihin jäi puutteita. Päästiinkö tavoitteeseen ja jos ei päästy, niin miksi ei? Olivatko tehtävät (items) riittävän tarkkarajaisesti mietittyjä? Tehtiinkö päätöksiä ajoissa? Kommunikoitiinko riittävästi sprintin aikana?

Lisäksi  saman pöydän ääressä keskustellaan siitä, mitä kehitetään seuraavaksi. Jos toteutettu toiminnallisuus ei palvelekaan niin kuin on ajateltu, niin sitä jatkokehitetään uusin käyttäjätarinoin. Itseään on hyvä muistuttaa, että ketterässä ostetaan työtä, ei tiettyä lopputulosta.

4. Valmiin määritelmä

Sprinttien paras puoli on se, että aina syntyy jotain valmista. Vaikka valmiiksi olisi saatu vain pieni osa suunnitellusta, niin se oikeasti valmista, testattua ja toimivaa. Laatua varmistetaan ja mitataan koko ajan, joten kun viikko päättyy, niin on helppo todeta valmiit ja keskeneräiset.

Ketterän kehityksen heikkoutena on, ettei se ota kantaa miten hoidetaan muut hankkeen osaset kuten resurssointi. Siinä astuvat kuvaan inhimilliset tekijät kuten esimies ja alainen. Heidän pitää pystyä yhdessä päättämään, mikä on tärkeintä juuri nyt. Haluammeko innovatiivisen verkkopalvelun vai jotain muuta. Voimme ihastua joka viikko uusiin ideoihin, päivittää kehityssuunnitelmaa ja kyseenalaistaa omaa tekemistämme, mutta päätöksiä pitää tehdä ja elää niiden kanssa.

Jossei maailma tullut valmiiksi tässä, niin ehkä sitten siinä seuraavassa sprintissä.

Lähde: Karoliina Luoto ”Ketterä kehittäminen julkishallinnossa”
Kuva: ”ST vs Gloucester – Match – 23″ by PierreSelim – Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons

Lisää aiheesta:

• Rakkaudesta Rugbyyn