Sprintin suunnittelu – helppoa kuin heinänteko?

Tämä kuuluisa sananlaskumme on ihan varmasti tuttu jokaiselle, mutta onko se heinänteko lopulta kovinkaan helppoa?

Asuin lapsena Tampereella, melkein Ylöjärven kunnan rajalla. Tuolloin alue oli vielä enemmän tai vähemmän maaseutua ja naapurillamme oli asiaan kuuluvasti vallan komea pelto, joka piti aina kesäisin niittää. Tietysti innokkaana miehenalkuna halusin kantaa kirjaimellisestikin korteni kekoon tässä urakassa. Muistan näistä urakoista kuumuuden, otsalla valuvan hien, kärpäset, pölyn ja varttuneempien niittomiesten rehkimisen, jota satunnaiset ärräpäät säestivät. Kuulostaako helpolta? Minusta ei. Eikä vertauskuva sovi Scrumin yhteen tärkeimmistä seremonioista, Sprintin suunnittelu kokoukseen (Sprint Planning), lainkaan. Huolimatta siitä, että se on näennäisesti kovin helpon kuuloinen homma.

Miksi Sprintin suunnittelu on usein haastavaa?

Scrum on menetelmänä äärimmäisen yksinkertainen tapa tehdä asioita.

Scrum on menetelmänä äärimmäisen yksinkertainen tapa tehdä asioita. Menetelmässä on vain muutamia asioita, joita meidän pitää seurata ja muutamia seremonioita joihin osallistua. Oppikirja Scrum ei kuitenkaan kerro meille, miten asioita kannattaa tehdä, vaan se on toteuttajien vastuulla. Menetelmä myös olettaa, että monet onnistuneelle tuotekehitykselle tärkeät asiat hoidetaan Scrumin virallisten seremonioiden ulkopuolella.

Sprintin suunnittelu ei nimestään huolimatta keskity tulevan Sprintin sisällön suunnitteluun, vaan jo laaditun sisältösuunnitelman lopulliseen viilaukseen. Tämä on yksi niistä täysin ymmärrettävistä väärinkäsityksistä, joita aloittelevilla ja usein edistyneemmilläkin tiimeillä on Scrumista ja sen seremonioista. Scrum menetelmänä antaa siis olettaa, että seuraavan inkrementin sisältö valmistellaan käynnissä olevan Sprintin aikana ”automaattisesti” asianomaisten taholta.

Nämä kokemukset ovat johtaneet Sprintin esisuunnittelukäytännön (Sprint Pre-planning) noudattamiseen, koska sitä noudattamalla meillä on selkeä kaikkien tiedossa oleva ajankohta, jolloin seuraavan tuoteinkrementin suunnittelua aletaan toteuttaa. Ottamalla Sprintin esisuunnittelukäytännön sekä kehitysjonon työstämisen (Backlog Grooming) omaan työkalupakkiinsa tiimi helpottaa usein omaa työtään ja tehostaa toimintaansa merkittävästi. Sprintin esisuunnittelusta ja kehitysjonon työstämisestä enemmän omissa kirjoituksissaan, keskittykäämme siis siihen, mitä onnistunut Sprintin suunnittelu vaatii.

Toimiva Sprintin suunnittelu: Takki kiinni ja katse palloon!

Kuten yllä jo tulikin ilmi, meillä on olemassa parikin hyvää käytäntöä, joita noudattamalla Sprintin suunnittelukokous saadaan vastaamaan tarkoitustaan: eli löytämään yhteisymmärrys sen suhteen, mitä tulemme seuraavan Sprintin aikana tekemään. Nämä yksistään eivät kuitenkaan riitä varmistamaan onnistunutta Sprintin suunnittelua ja sitä kautta onnistunutta iteraatiota.

Tarkastellaanpas hieman, millaisia erilaisia yleisiä haasteita Sprintin suunnitteluissa tulee vastaan.

Emme ole varmoja siitä, onko nyt keskusteltava sisältö se mitä tulemme lopulta Sprintin päätteeksi toteuttamaan

Ei ole mitenkään tavatonta, että Sprintin sisältö muuttuu jonkin verran sen aikana. Tämä johtuu siitä, että usein opimme jotain tärkeää mikä vaikuttaa Sprintin sisältöön. Muutosten suhteen on tarpeellista laatia selkeät säännöt sen suhteen millainen muutos täyttää ne kriteerit, joilla se otetaan mukaan Sprintiin. Tällöin täytyy muistaa myös se, että kun jotakin otetaan mukaan iteraatioon, jotakin pitää poistaa siitä.

Huomattavasti huolestuttavampi tilanne on se, että Sprintin sisältö muuttuu jatkuvasti, mikä tekee sen suunnittelusta oikeastaan hyödytöntä. Kyseessä on tällöin systeeminen ongelma, jota tiimin tuoteomistajineen on usein hyvin vaikea ratkaista. Ongelman juurisyyt löytyvät usein huonosti määritellystä tuotevisiosta, kilpailevista ja puuttellisista korkean tason prioriteeteista, ”Design by Committee” ajattelusta tai vastaavista syistä. Ongelman taustalla saattaa olla myös se, että tuoteomistaja ei itsekään tiedä mitä tuotteelta haluaa ja toimii enemmän reaktiivisesti ja intuitionsa varassa kuin systemaattisesti.

Sprintin tavoiteltu sisältö on epärealistinen

Realistinen Sprintin suunnittelu vaatii realistisen arvion siitä, kuinka paljon aikaa tiimillä on käytettävissään Sprintin aikaisen työn tekemiseen. Tämä ongelma on enemmän sateenvarjo-ongelma, joka koostuu monesti useista eri ongelmista. Työmääräarviot ovat usein epärealistisia. Me ihmiset olemme hyvin optimistisia olentoja. Olemme taipuvaisia yltiöoptimismiin, joka johtaa siihen, että arviomme vaikkapa asioiden koosta tai ajasta, joka niiden tekemiseen kuluu on hyvinkin ruusuinen. Olemme myös miellyttämishaluisia ja usein arkoja kertomaan asioiden todellista laitaa, erityisesti jos se saattaa aiheuttaa meille ongelmia.

Olen huomannut varsin usein myös sen, että tiimi ei kerää mitään metriikkaa sen suhteen, kuinka kauan asioiden tekemiseen kuluu tai kuinka isoja ne ovat. Nämä haasteet johtavat siihen, että kohtaamme, erästä sparraamani tiimin jäsentä siteeraten, ”ankean todellisuuden, kun joudutaan taas kerran huomaamaan se, että emme saaneet aikaiseksi sitä mitä aioimme”. Myös se, että Sprintiin otettavat asiat ovat liian isoja, johtaa tähän edellä mainittuun toteamukseen.

Tuoteomistajan valmistautumattomuus

Olenpa useampaankin kertaan ollut Sprintin suunnittelussa, johon tuoteomistaja saapuu ns. ”takki auki” mietiskelemään, mitä tiimi mahdollisesti tekisi seuraavan Sprintin aikana. Tämä ei ole Sprintin suunnittelun tarkoitus, vaan tuoteomistajalla tulee olla tässä vaiheessa hyvin tarkka visio siitä, mitä seuraavassa inkrementissä tehdään. Tämä haaste johtuu onneksi useimmin tuoteomistajan kokemuksesta ja silkasta väärinkäsityksestä sen suhteen, mikä Sprint suunnittelun tarkoitus on, kuten jo edellä huomasimme. Joskus tuoteomistaja saattaa tietysti olla välinpitämätön roolinsa vaatimusten suhteen, tai jopa väärä asiantuntija toimimaan tässä tehtävässä.

Tiimin läsnäolon puute

Tämä on myös yksi Sprintin suunnittelua riivaavista haasteista. Tiimin jäsenet eivät ole Scrumissa sivussa katsojan ja toteutuskoneen roolissa, vaan aktiivisia ja proaktiivisia toimijoita, joiden näkemyksellä, kokemuksella ja asiantuntemuksella on erittäin tärkeä rooli. Tiimiläiset ovat tuoteomistajan kanssa yhdenvertaisia Sprintin sisällön määrittelyn suhteen. Tiimin on erittäin tärkeä ymmärtää oma osuutensa ja roolinsa prosessissa, ja omaksua aktiivinen ote ja omistajuus tekemiensä asioiden suhteen.

Käytännössä läsnäolon puute näkyy tiimin passiivisuutena, siinä että tiimiläisistä suurin osa tekee jotakin muuta kuin keskittyy käsiteltäviin asioihin tai tiimi on yksinkertaisesti puhtaan välinpitämätön asioista. Vaikka ketterien tiimien tulisi olla kokoonpanoltaan ylitoiminnallisia (cross-functional), käytännössä tiimeissä on aina henkilöitä, jotka osaavat joko tietyn osa-alueen parhaiten tai jopa ovat tietämykseltään ylivertaisia toteutettavan ratkaisun suhteen.

Erityisesti jälkimmäisessä tapauksessa keskustelua saatetaan käydä tämän henkilön ja tuoteomistajan välillä muiden tiimiläisten puuhaillessa omiaan ja luottaessaan siihen, että näiden kahden tahon välinen keskustelu on riittävästi. Mutta kun se ei ole. Totuus on se, että mitä useammasta näkökulmasta asioita katsotaan, sitä rikkaamman kuvan saamme niistä. Ketterä tekeminen on joukkuelaji, joten kaikkien tiimiläisten täytyy pitää katseensa pallossa.

Näin Sprintin suunnittelu onnistuu!

Ottakaa Sprintin esisuunnittelu ja kehitysjonon työstö -seremoniat käyttöönne. Nämä seremoniat pyrkivät varmistamaan sen, että olemme tekemässä oikeita asioita ja voimme keskittyä varsinaisessa Sprintin suunnittelussa niihin asioihin, jotka ovat tärkeitä. Myös Definition of Ready -käytäntö kannattaa aivan ehdottomasti sisällyttää työkalupakkiin.

Harjoitus tekee mestarin tässäkin asiassa!

Liian suuria vaatimuksia täytyy ehdottomasti pilkkoa pienempiin kokonaisuuksiin. Ideaalisesti jokaisen Sprintiin tulevan asian täytyy olla kooltaan sellainen, että sen voi toteuttaa yhden Sprintin aikana. Asioiden pilkkominen pienempiin kokonaisuuksiin on aina hyödyllistä, sillä se auttaa meitä hahmottamaan sitä paremmin ja myös helpottaa merkittävästi sen estimointia. Oman kokemukseni perusteella asioiden pilkkomisen opettelu ei ole mitenkään suoraviivaista, vaan vaatii harjoitusta. Onneksi harjoitus tekee mestarin tässäkin asiassa! Pilkkomista kannattaa aloittaa käyttämällä vaikkapa SPIDR – menetelmää, joka tarjoaa selkeitä ohjeita kokonaisuuden pilkkomiseen.

Työmääräarvioiden suhteen kannattaa käyttää parasta estimointitekniikkaa, eli datapohjaista ennakointia. Modernit tuotekehitystyökalut, kuten Jira, keräävät valtavan määrän tietoa tuotekehityksestä. Tätä tietoa mm. tehtyjen asioiden toteutuneesta koosta ja kestosta kannattaa ehdottomasti hyödyntää työmääräarvioinneissa.

Muihin kuvattuihin haasteisiin ei ole olemassa suoraviivaista tapaa ratkaista niitä. Nämä saattavat olla luonteeltaan hyvinkin kompleksisia ja vaativat aina koulutusta ja valmennusta. Ne ovat kuitenkin investointeja, joita jokaisen tuotekehitysorganisaation kannattaa ehdottomasti tehdä!