Todennäköisesti moni alan ekspertti on ainakin kuullut Design Sprintistä, joten tässä blogisarjassa en lähde esittelemään sitä tarkemmin. Jos et vielä tunne kyseistä työskentelytapaa, voit aloittaa esimerkiksi Design Sprintin luojan Jake Knappin kirjasta The Sprint.
Helpon lähestymistavan aiheeseen tarjoaa saksalaisen designtoimiston AJ&Smartin sisältö muun muassa YouTubessa. He ovat todella voimakkaasti profiloituneet Design Sprint -toimistona eikä syyttä: heillä tuntuu olevan homma hanskassa ja he ovat Knappin kanssa ja myötävaikutuksella jatkokehittäneet työskentelytapaa. Alun perin Design Sprint oli viisipäiväinen, mikä on sekin aika tiukka rutistus, mutta he ovat niistäneet siitä pois vielä yhden päivän.
Laitoin designtiimin kollegoilleni kyselyä Slack-kanavalle siitä, mikä voisi olla kiinnostava näkökulma Design Sprintiin vertaisille. Tässä blogisarjan ensimmäisessä osassa kerron muutamista yleisistä huomioitavista Design Sprintin ominaispiirteistä kokemusteni kautta. Toisissa osissa lähestyn aihetta sprintin hyötyjen kautta eli miten sitä voisi myydä sisäisesti omalle organisaatiolleen sekä mitä kannattaa ottaa huomioon sprinttiä fasilitoidessa.
Intensiivinen työtapa ei sovi jatkuvaan käyttöön
Olen itse ollut mukana ja fasilitoimassa hiukan päälle kourallisessa sprinttejä viimeisen kolmen vuoden aikana ja kaikki ovat olleet todella erilaisia. Ensimmäisen teimme, kun olimme lukeneet kirjasta, että näin tämä menee ja käyttäkää siihen viisi päivää. Mehän tietysti päätimme, että tämä tehdään kolmessa päivässä. En voi suositella, se oli tosi tiukka setti, vaikka siitä huolimatta onnistunut kokonaisuus, sillä saimme siitä validia kamaa ulos.
Sprinttiin menee aikaa ja energiaa, joten en suosittelisi myöskään ottamaan niitä kuukauteen kuin yhden. Kaksi saattaisi pystyä kuukaudessa vetämään, mutta työtapa on niin intensiivinen, että sitten olisi takki ihan tyhjä. Työtapana se ei siis ole jatkuva, vaan ennemmin käyttäisin sitä alkusysäyksen saamiseen. Sprintillä pistetään homma rullaamaan, jos asiakkaalla on esimerkiksi vaikeuksia saada kiinni siitä, mistä kannattaa lähteä liikkeelle tai mitä se oikeastaan on, mitä kannattaa tehdä.
Tietenkin pitemmällä aikajänteellä voisi toimia systeemi, jossa otetaan yksi sprintti kuukauteen ja työstetään jatkosprinttinä loppuun sen tuottama konsepti, minkä jälkeen otetaan seuraava pala työn alle. Jatkosprinttihän on kevyempi. Siihen riittää pari kolme päivää, riippuen hiukan siitä, millä tasolla prototyyppi on tai ollaanko jo MVP-työstövaiheessa. Jatkosprintillä iteroidaan suoraan prototyyppiä ja testataan, tai jopa koodataan tuotetta eteenpäin, missä muodossa se nyt sitten onkaan.
Prototyypin rakentamisesta ja testaamisesta jatkokehitykseen
Yhden sprintin teimme sisäisessä tuotekehityshankkeessa vähän monimutkaisemman ominaisuuden suunnitteluun. Se oli erittäin positiivinen kokemus, ja työtapa toimi yllättävän hyvin osana laajempaa kokonaisuutta ja agile scrum -rutiinia. Siinä sprintissä lopputuotos tehtiin ihan oikeasti koodaten. Tyypillisesti lopputulos on jokin tiksuteltava interaktiivinen prototyyppi, joka tehdään Figmalla tai vastaavalla köykäisemmällä työkalulla.
Filosofia on se, että prototyypin luomiseen käytetään juttuja, jotka ovat saatavilla. Mitä vaativampi ja monimutkaisempi konseptin prototyyppi on, sitä valmiimman aihion se vaatii. Mitään robottia ei rakenneta päivässä tyhjästä. Silloin on otettava prototyyppivaiheessa timeout, minkä aikana rakennetaan oikeasti robotti tai sitten on oltava luovia prototyypin rakentamisessa ja testaamisessa eri tavalla.
Yksi kysymys on, mitä tapahtuu sprintin jälkeen, kun idea ja prototyyppi on testattu. Lähes jokaisella sprintillä, jossa olen ollut, on sen päätyttyä tullut pohdintahetki asiakkaalle; pitää hakea lisärahoitusta tai keskustella sisäisesti siitä, mitä tapahtuu seuraavaksi. Kun teimme sisäisesti tuotteen ominaisuuteen liittyvän sprintin, meidän oli paljon helpompaa ja suoraviivaisempaa jatkaa seuraaviin toimenpiteisiin, jotta saimme featuren toteutettua loppuun vaadittavalle tasolle.
Yksi meidän lupauksistamme asiakkaalle on ollut, että kun konsepti on pihalla, he voivat tehdä sillä mitä haluavat. Eräässä sprintissä asiakas oli supertyytyväinen menetelmään ja tuotettuun prototyyppiin, ja he käyttävät tuota käyttöliittymäkonseptia edelleen. He olivat tilanneet kaksi konseptointia rinnakkain, ja meidän huomattavasti laajempi tekninen konseptointi ei ollut heidän mieleensä, ja he päätyivät jatkamaan sen kanssa, joka oli lähempänä heidän mieltymystään. Saimme tästä hyvää oppia itselle, miten voimme jatkossa ehdottaa teknistä roadmapiä.
Joskus asiakkaalla ei ole budjettia lähteä työstämään hanketta oikeasti. Sprinttihän toimii mainiosti proof of concept -työhön, mutta onhan se harmi, jos sen pohjalta ei sitten tehdä mitään toimenpiteitä. Asiakkaan sitouttaminen jatkotoimenpiteisiin on siis oma haasteensa.
Keitä mukaan asiakkaalta ja järjestäjältä?
Yksi isoimmista haasteista on saada oikeat ihmiset paikalle, eritysesti se, että sprintissä olisi mukana oikeasti asioista päättävä taho. On aina epäoptimaalista, että sprintin lopputulos pitää viedä esiteltäväksi jollekin toiselle konklaaville, koska jatkon torppaus voi tulla sieltä.
Toisaalta sprintin tulokset auttavat kuitenkin aina sitä, joka lähtee esittelemän konseptia muille. Sprintissä kuitenkin validoidaan ongelmaa monesta näkökulmasta ja tätä kautta minimoidaan riskejä, joita yhden ihmisen visioima ja hioma konsepti voi tuoda. Joskus tällainenkin visionäärinen designtyö toimii, mutta jos konseptia lähdetään viemään pidemmälle ilman kunnollista validointia, on suurempi riski, ettei se toimikaan.
Sprinttitiimiin tuodaan tyypillisesti mukaan businessnäkökulmaa, designosaamista ja teknologista osaamista. Joskus tarvitaan paikalle budjettiekspertti, joka osaa ottaa kantaa, mikä on liiketoiminnallisesti järkevää. Lisäksi osallistujina voi olla vaikkapa markkinoinnin osaajia tai mitä ikinä tarvitaankin kyseisessä tapauksessa. Osa tiedosta voidaan myös kerätä asiantuntijahaastatteluina.
Sprintin järjestäjäpuolelta tuleva porukka voi myös vaihdella. Jos asiakkaalla on vahva talon sisäinen designporukka, keitä he voivat hyödyntää, sekä softaporukka, voimme järjestää omasta puolestamme vain fasilitoidun Design Sprintin. Tällä tavalla emme ole tosin vielä kertaakaan sprinttiä järjestäneet. Sitten on täysin Insta Digital -miehitetty vaihtoehto, jossa meiltä tulee fasilitaattori, designeri, ja arkkitehti tai tekninen ekspertti, ja sitten on tietysti kaikki välimallit riippuen siitä, miten asiakkaalla on aikaa ja ihmisiä käytettävissään.
Validointiin liittyy lupaus, että tuotamme sprintin tuloksista vähintään korkean tason roadmapin ja teknisiä vaihtoehtoja, miten konseptia voisi lähteä toteuttamaan. Tietysti pääpihvi ainakin minun mielestäni on se prototyyppi ja momentti, mikä tällaisesta keskittyneestä työskentelystä saadaan. Asiakkaillamme tuntuu nyt olevan kiinnostusta Design Sprintiä kohtaan enemmänkin, joten uusia sprinttejä lähtee kohtapuoliin taas liikkeelle. Näissä voisimmekin kokeilla, miten saisimme säilytettyä momentin paremmin ja jatkettua työstämistä ilman informaatiohandoverien riskiä. Muun muassa tähän sprintin etuun palaan tarkemmin seuraavassa osassa.
Kirjoittaja
Sami Surakka
Haluatko kuulla lisää? Ota yhteyttä:
Tom Hannelius
Director, Software Consulting
firstname.lastname(at)insta.fi
