Liian moni tiimi kiirehtii sprinttien pariin ennen kuin suunta on selvä ja se lopulta kostautuu isona hintalappuna ja turhana työnä. Discovery ja Sprint 0 auttavat pysähtymään hetkeksi ja rakentamaan yhteistä ymmärrystä ennen toteutusta. Kun nämä vaiheet tehdään oikein, kehitystyö alkaa vahvalta pohjalta ja tuloksena syntyy vähemmän hukkaa ja enemmän arvoa.
Kun tuotetiimi päättää lähteä toteuttamaan uusia toiminnallisuuksia tai rakentamaan uutta tuotetta, halutaan sprintit ja muut ketterät seremoniat yleensä aloittaa heti. Liian usein tiimit lähtevät liikkeelle vain muutamalla oletuksella, joiden alkuperä ei ole ihan kaikkien tiedossa, ja kompassina toimii puoliksi täytetty backlog pääasiassa teknisesti hienosti määriteltyjä tikettejä.
Tämän aloituksen tuloksena on toiminnallisuuksia, jotka ei ihan täysin vastaa käyttäjien tarpeisiin, ylimääräistä työtä ja varsinkin tunne, että paljon tehdään hurjalla vauhdilla, mutta opit jäävät vähäiseksi.
Jos tiimi malttaisi hetken, edes pari viikkoa ennen varsinaisten kehityssprinttien alkua, keskittyä yhteisen ymmärryksen lisäämiseen ja suunnan löytämiseen, olisivat seuraavat sprintit helpompia ja selkeämpiä toteuttaa. Tätä kriittistä hetkeä kutsutaan product tai service discoveryksi ja sprint nollaksi. Kyseisten vaiheiden tärkein lopputulos on sovittaa visio yhteen todellisuuden kanssa.
Product Discovery ja Sprint 0 eivät ainoastaan kirkasta suuntaa, vaan myös pienentävät riskiä investoida väärään ratkaisuun. Kun varmistamme jo varhaisessa vaiheessa, että ratkaistaan oikeaa ongelmaa ja tunnistetaan kriittiset epävarmuudet, johdolle ja projektipäälliköille syntyy parempi ennakoitavuus ja hallittavuus. Tämä vähentää kalliita yllätyksiä myöhemmissä vaiheissa.
Product Discovery – yhteisen suunnan kirkastaminen ennen rakentamista
Product discovery on prosessi, jonka tarkoitus on selkeyttää tiimin tavoitteita ennen kuin mitään rakennetaan. Se tarkoittaa käyttäjien tarpeiden, liiketoiminnan tavoitteiden ja teknisten reunaehtojen ja mahdollisuuksien tutkimista. Lopputuotoksena näiden kolmen tärkeän näkökulman yhteenliittymä. Tässä vaiheessa ei kannata keskittyä liikaa dokumentointiin vaan tiimin suunnan selkeyttämiseen.
Tämän vaiheen tärkeimmät kysymykset ovat
- Ratkaisemmeko oikeaa ongelmaa?
- Kenelle teemme tätä?
- Miten mittaamme onnistumista?
Tyyli on vapaa, voitte haastatella asiakkaita ja muita tärkeitä sidosryhmiä, tehdä prototyyppeja ja vaikka testata ideaa kadulla. Tärkeintä on kuitenkin vaiheen tavoite: selkeytetään suuntaa ja opitaan ennen kuin sitoudutaan.
Muotoilijan rooli on keskeinen, kun tavoitteena on saada loppuasiakkailta ymmärrystä. Muotoilijat pystyvät suunnittelemaan ja fasilitoimaan yhteiskehittämistä, joissa vastataan product discoveryn tärkeisiin kysymyksiin. Tyyli ymmärryksen lisäämiselle on vapaa: voitte haastatella asiakkaita ja muita tärkeitä sidosryhmiä, tehdä prototyyppeja ja vaikka testata ideaa kadulla. Tärkeintä on kuitenkin vaiheen tavoite: selkeytetään suuntaa ja opitaan ennen kuin sitoudutaan. Näin varmistetaan, että tiimi saa tarvittavat oivallukset ja pystyy tekemään tietoon perustuvia päätöksiä ennen toteutusta.
Sprint nolla – askel kohti konkretiaa
Monella voi mennä sekaisin product discovery ja sprint nolla tai ne nähdään toisistaan irrallisina. Todellisuudessa ne tukevat toisiaan vahvan alustuksen luomisessa.
Sprint nolla aiheuttaa monien mielissä ristiriitaisia asioita ja täysin ymmärrettävästi. Usein se mielletään aikaa vieväksi pullonkaulaksi tai minivesiputoukseksi ennen varsinaista kehitystyötä – ja tämä jos mikä taistelee ketteryyden ja leanin periaatteita vastaan.
Avain onnistumiseen on siinä, että koko tiimi keskittyy parin viikon aikana luomaan selkeän kuvan yhteisistä tavoitteista ja rakenteista, jotka tukevat tavoitteen saavuttamista. Tällöin kehitystyö alkaa vahvalta pohjalta.
Konkreettisia tuotoksia sprint nolla -vaiheesta:
- Tuotevision kirkastaminen ja selkeät mittarit onnistumiseen
- Ensimmäinen priorisoitu backlog
- Nopea validointi käyttäjillä kriittisistä toiminnallisuuksista
- Yhteiset pelisäännöt, roolit ja toimintamallit
- Teknisten reunaehtojen kuvaus ja valitut järjestelmät
- Riskien ja riippuvaisuuksien tunnistaminen
Jos tähän vaiheeseen käytetään liikaa aikaa ja se nähdään pakollisena aivan kaikkeen, se todella hidastaa kehitystä ja varsinaisen arvon tuottamista. Ratkaisu löytyy tasapainosta – milloin se nähdään tarpeellisena, milloin se voidaan ohittaa ja mennä suoraan kehitykseen. Kuitenkin parhaimmillaan sopivan pituinen sprint nolla nopeuttaa kehitystä.
Konkreettinen esimerkki oikeasta elämästä:
Eräässä tiimissä backlog oli täynnä erilaisia toiminnallisuuksia ja kiire painoi päälle. Kun uusi tiimin jäsen – muotoilija – liittyi mukaan liikkuvaan junaan, tiimi joutui pysähtymään hetkeksi arvioimaan suuntaansa. Yhdessä he huomasivat, että yksi suurista backlogissa olleista toiminnallisuuksista olisi vaatinut valtavasti kehitysaikaa ja uutta teknologiaa – ja perustui lopulta lähinnä johdon oletuksiin käyttäjien tarpeista.
Muotoilija ehdotti, että kysytään käyttäjiltä itseltään. Tiimi järjesti muutaman haastattelun, ja tulokset muuttivat kaiken: suunnitellun ominaisuuden laajuus supistui murto-osaan alkuperäisestä. Näin projekti säästi merkittävästi aikaa ja rahaa – ja pystyi keskittymään kehittämään juuri niitä toiminnallisuuksia, jotka loivat todellista arvoa käyttäjille.
Sprint nolla ja Product Discovery yhdessä – kompassi ja ensimmäiset askeleet
Product Discovery ja sprint nolla ovat yhdessä loistava pari, jonka lopputuloksena tiimi pystyy aloittamaan kehitystyön varmemmalla pohjalla ja saamme aikaan nopeammin aidosti arvoa tuottavia tuloksia pelkkien tuotosten sijaan.
Eron voi nähdä näin:
- Product Discovery toimii kompassina ja varmistaa suunnan
- Sprint nolla aloittaa matkan konkretisoimalla ensimmäisen vaiheen löydökset backlogiksi ja käytännöiksi
Tässä siirtymässä muotoilijan osaamisella on keskeinen rooli: muotoilijat konkretisoivat oivalluksia, visualisoivat käyttäjäpolkuja ja sparraavat PO:ta jalostamaan backlogia kohti testattavia ja merkityksellisiä kokonaisuuksia.
Jos discovery loppuu, loppuu oppiminenkin
Jatkuva discovery on tapa toimia, ei kertaluontoinen harjoitus. Tärkeää on ottaa koko tiimi mukaan varhaiseen tutkimiseen ja suunnan kirkastamiseen, mutta se tulee aloittaa pienesti: testataan kerrallaan yksi oletus, yksi käyttäjäpolku tai yksi prototyyppi. Kaikki keskustelut pyritään liittämään yhteiseen tuotevisioon, jotta päätökset pysyvät linjassa. Ja ennen kaikkea, epävarmuus on ok – kaikkea ei pidä suunnitella valmiiksi, jotta opit voivat ohjata seuraavia askeleita.
Maailmassa, jossa vauhti kiihtyy ja kasvutavoitteet ohjaavat tekemistä, saattaa tuntua haastavalta pysähtyä ja nähdä, että kehittäminen on luonteeltaan syklinen prosessi. Siksi sprint nollan jälkeen on tärkeää säilyttää tämä syklisyys sen sijaan, että projektista tulee vesiputous. Myös discovery-vaiheen löydöksiä tulee tarkastella ja kyseenalaistaa säännöllisesti. Ketterä palvelukehitys on vakiinnuttanut asemansa tehokkaana tapana tuottaa laadukkaita palveluja yrityksen tai organisaation koosta riippumatta.
Seuraavassa blogipostauksessamme sukellamme vision rakentamiseen, joka ohjaa koko tiimiä eteenpäin ja selkeyttää suuntaa.
Lue myös Rosa Vannisen blogi: Ajaako tiimisi käsijarru päällä? Ketterä muotoilu yhteistyön mahdollistajana
