Scrum, Kanban ja Scrumban vs startupin erityispiirteet

Tässä artikkelissa vertaillaan Scrumin, Kanbanin ja Scrumbanin soveltumista startup-yritysten toimintaympäristöön vertailemalla, miten kukin menetelmä kykenee vastaamaan kuhunkin startupille tyypilliseen erityispiirteeseen. Erityispiirteisiin lukeutuvat muun muassa tiimien koostumus, tiimin yhteispeli, tuoteomistajuus, asiakkaan tarpeisiin vastaamisen ja vaatimustenhallinnan vaikeus, julkaisuprosessin hallinnan merkitys sekä tarve prosessin keveydelle.

Tiimien koostumus

Yrityksen liiketoiminta on muutakin kuin pelkkää tuotekehitystä. Yrityksen täytyy palvella useita sidosryhmiä rinnakkain. Kuten mainittu, yrityksen täytyy myydä ja markkinoida tuotettaan, hoitaa asiakassuhteita sekä yrityksiin että kuluttaja- asiakkaisiin ja mahdollisesti hankkia rahoitusta pääomasijoittajilta tai valtiollisilta toimijoilta. Yrityksen täytyy hoitaa laki- ja lupa-asioita, ja toimia byrokratian rattaissa.

Myös tuotekehityksessä on useita erityisosaamista vaativia vaiheita. Itse ohjelmointi on ilmeinen osa kokonaisuutta. Tämän lisäksi yrityksen pitää muun muassa suunnitella, testata ja tuotteistaa projektinsa. Kehittäjätiimikin saattaa joutua toimimaan asiakasrajapinnassa totetuttaessaan mahdollisia käyttäjäkokeita.

Startupit ovat tyypillisesti hyvin pieniä henkilöstömäärältään. Startupit työskentelevät usein myös vain yhden tuotteen parissa ja hyvin matalalla organisaatiohierarkialla, joka tarkoittaa yleensä vain yhtä tiimiä. Siksi startupien tiimien yksimuotoisuus aiheuttaa ongelmia.

Mitä sanovat menetelmät?

Startupien on kyettävä tarjoamaan yhden tiimin sisällä osaaminen kaikkiin liiketoiminnan ja kehitystyön osa-alueisiin. Erityisesti itse tuotteen rakentamisen ulkopuoliset asiat helposti ylityöllistävät tiimiä, jolloin tuotanto viivästyy ja arvoa sekä rahaa tuottava toiminta estyy.

Scrum suosittelee tiimin olevan monimuotoinen ja poikkitoiminnallinen. Scrum- tiimin ideana on, että se sisältää kaiken sen osaamisen, mitä tarvitaan toimivan tuotteen rakentamiseen. Tiimissä on tuoteomistaja, Scrum Master, sekä osaajia kaikilta tuotekehitykseen liittyviltä osa-alueilta. Yrityksessä voi olla vielä tiimistä osittain irrallaan toimiva toimitusjohtaja, jolle voidaan asettaa myynti- ja markkinointivastuu, byrokratia sekä rahoittajien kanssa toimiminen. Tuoteomistaja hoitaa asiakasrajapinnan. Ainoa rajoitus Scrum-tiimeille on, että erityisosaaja-, eli spesialistitiimejä ei sallita.

Kanban ei aseta minkäänlaisia rajotteita tiimille. Kanban sallii sekä poikkitoiminnalliset että spesialistitiimit. Koska rajotteita ei ole, on mahdollista, että tiettyjä toiminnan osa-alueita ei oteta huomioon, jolloin kuvatunlaista osaamisen puutetta voi syntyä, ja toiminta voi sakata.
Scrumban sallii Kanbanin lailla spesialistitiimit, mutta kannustaa poikkitoiminnallisiin tiimeihin Scrumin tapaan. Scrumban tunnustaa tiettyjen roolien, kuten tuoteomistaja ja Scrum Master, olemassaolon.

Voidaan todeta, että tiimien monimuotoisuuden takaamiseksi Scrum ja Scrumban tarjoavat parhaat mekanismit. Kanbanin rajoituksettomuus voi johtaa siihen, että jotkin osa-alueet jäävät kattamatta.

Tiimin yhteispeli

Yritystoiminta ja tuotekehitys on joukkuepeliä. Tiimin sisäinen toiminta on siksi elintärkeää. Tiimin jäsenten on oltava motivoituneita, työllistettyjä ja heidän osaamistaan täytyy arvostaa. Mikäli joku tiimin jäsenistä turhautuu tai alkaa oireilla jollakin muulla tavalla, se voi tarttua muihin tiimin jäseniin, mikä puolestaan voi johtaa toiminnan heikkenemiseen.

Tiimin toimivuus voidaan varmistaa oikeantyyppisellä johtamisella. Johtamisessa on keskityttävä muun muassa seuraaviin periaatteisiin, jotta voidaa saavuttaa hyvin toimiva tiimi:

  • Prosessiajattelu: tähän kuuluu työnkulun visualisointi, kommunikointi ja rakenteellisten epäkohtien havainnointi sekä tavotteiden asettaminen.
  • Toiminnan tarkoituksellisuuden perustaminen: Tiimille on selvennettävä toiminnan visio, eikä heille saa olla epäselvää, mitä he ovat tekemässä ja miksi. Yhteinen tavoite saa tiimin työskentelemään tehokkaammin.
  • Luottamuksen ilmapiirin rakentaminen: korkean luottamuksen ilmapiiri luo korkean tehokkuuden tiimejä.
  • Ihmisten kunnoittaminen: Ohjelmistotuotanto on luovaa työtä, ja ihmiset, jotka tuntevat olonsa hyväksi ovat tuottavampia.
  • Luotettavat menetelmät konfliktien ratkaisuun: Vaikeat asiat on pyrittävä hoitamaan inhimillisesti, mutta niitä ei pidä lykätä.
Mitä sanovat menetelmät?

Scrum ja Scrumban tarjoavat ratkaisuksi Scrum Masterin. Scrum Masterin tehtävänä on olla niin sanottu palveleva johtaja, joka pyrkii poistamaan tiimin tiellä olevia esteitä. Scrum Masterin tehtävänä on huolehtia nimenomaan yllä mainitusta johtamisesta ja siihen liittyvistä asioista. Palvelevat johtajat luovat luottamusta, joka johtaa parempaan työntekijöiden osallistumiseen, ideointiin ja lisää nähdyn vaivan määrää, mikä tuottaa nopeampaa muutosta ja innovointia.

Kanban ei määrittele mitään roolia tiimin sisäisen toiminnan varmistamiseksi. Siksi on jälleen vaarana, että aihe jää havaitsematta ja käsittelemättä, mikä voi johtaa huonoihin tuloksiin. Toisaalta mikäli Kanbania toteuttavat yhteisöt ovat perehtyneet lean-periaatteisiin, on mahdollista, että ihmisiä kunnioittamalla ja energisoimalla voidaan päästä haluttuihin lopputuloksiin.

Voidaan todeta, että tiimien sisäisen toimivuuden takaamiseksi Scrum ja Scrumban tarjoavat parhaat mekanismit. Kanbanin rajoituksettomuus voi johtaa siihen, että aihe jää kattamatta.

Tuotteen omistaja

Tuote koostuu ominaisuuksista, ja hyvä tuote sellaisista ominaisuuksista, joita asiakkaat haluavat käyttää. On havaittu, että startupit epäonnistuvat, jos niiden tuotteella ei ole omistajaa. Tuoteomistaja päättää, mitkä ominaisuudet toteutetaan lopputuotteeseen. Tuoteomistajan vastuulla on siis tuotteen elinkaari, joka alkaa asiakkaiden vaatimusten hallinnasta ja päättyy tuotteen julkaisuun.

Mitä sanovat menetelmät?

Scrum ja Scrumban määrittelevät tuoteomistajan roolin. Scrumissa ja Scrumbanissa tuoteomistajan tehtävänä on olla yhteydessä asiakkaisiin, joiden kanssa hän määrittelee ominaisuudet, jotka totetutetaan tuotteeseen. Tuoteomistajalla on visio lopputuotteesta, jonka hän yrittää siirtää tiimille.
Vaikka Scrumissa tuoteomistaja priorisoi tuotteen kehitysjonon, tiimit valitsevat sieltä vapaasti sprintissä toteutettavat ominaisuudet. Scrumbanissa tuoteomistaja priorisoi työjonon, jonka päältä kehittäjätiimi imee työtehtäviä prosessiin. Scrumbanissa asiakkaan kanssa toimivalla tuoteomistajalla on siis parempi kontrolli tuotettavista ominaisuuksista.

Kanbanissa ei määritellä tuoteomistajan roolia, mikä huonoimmassa tilanteessa voi johtaa siihen, että tuotteella ei ole omistajaa, mikä puolestaan johtaa yllä kuvattuun epäonnistumiseen. Lisäksi asiakasrajapinnassa toimiminen voi jäädä liian vähäiseksi, joka voi johtaa myös osaltaan epäonnistumiseen, kun ei tiedetä asiakkaiden tarpeita eikä siten asiakkaiden tarpeisiin pystytä vastaamaan.

Voidaan todeta, että tuotteen omistajan roolin takaamiseksi Scrum ja Scrumban tarjoavat parhaat mekanismit. Kanbanin rajoituksettomuus voi johtaa siihen, että aihe jää kattamatta.

Vastaaminen asiakkaiden tarpeisiin

Startupit tuottavat sovelluksia korkean potentiaalin markkinoille yksittäisten asiakkaiden sijaan, jolloin niiden avainstrategiana on saada tuotteet markkinoille mahdollisimman nopeasti. Valitettavasti startupeissa ohjelmistojen vaatimukset ovat usein yrityksen itsensä keksimiä, harvoin dokumentoituja ja ne validoidaan vasta, kun tuote on markkinoilla. Tuotteen epäonnistuminen johtuukin suuresti siitä, että se ei vastannut asiakkaiden tarpeita.

Validoidun oppimiprosessin puute ja resurssien käyttäminen tuottamattomiin asioihin johtavat epäonnistumisiin. Validoidun oppimisprosessin avulla voidaan identifioida asiakkaiden todelliset tarpeet, eli oikeat tuotettavat asiat, eli asiat, joista asiakkaat ovat valmiita maksamaan.

Eräs tapa luoda validoitu oppimisprosessi on Eric Riesin popularisoima yrityksen johtamismalli Lean Startup, jolle on ominaista validoidun oppimisen lisäksi nopea kokeellisuus, lyhyet tuotteenkehityssyklit ja asiakkaiden kuuleminen taajaan siitä, mitä he tuotteelta haluavat.

Lean Startup korostaa oppimisen tärkeyttä startupin kehityksen mittarina. Startupissa vältetään keskittymistä liikevoiton tekemiseen liian aikaisessa vaiheessa, vaan keskitytään mieluummin oppimaan, mikä strategia toimii parhaiten. Startupin täytyy selvittää kurinalaisesti ja järjestelmällisesti, tapahtuuko kehitystä ja tapahtuuko oppimista.

Lean Startupin ytimessä on niin sanottu Rakenna – Mittaa – Opi -sykli (RMO- sykli, engl. Build – Measure – Learn -cycle), joka on esitetty kuvassa 1. Syklin aikana luodaan ideoista tuote, jonka mittaamisen seurauksena luodusta datasta pyritään oppimaan uusia ideoita. Syklin kesto pyritään kutistamaan mahdollisimman pieneksi.

Kuva Build-Measure-Learn-syklistä
Kuva 1 Rakenna – Mittaa – Opi -sykli ja ”Pivot or persevere”-päätös

Syklien tuotokset ovat kysynnäntestaustuotteita (engl. Minimum Viable Product, MVP). MVP on tuote, joka mahdollistaa RMO-syklin täyden kierroksen vähimmällä vaivalla ja kehitysajalla. Käytännössä tämä tarkoittaa Rakenna-vaiheen vaivan ja kehitysajan minimointia. Kysynnäntestaustuotteesta voi puuttua monia ominaisuuksia, jotka saattavat olla myöhemmin elintärkeitä – mikäli kysynnäntestaustuote on sellaisessa vaiheessa, että sen avulla voidaan aloittaa oppiminen, on tuote valmis.

Monimutkaisten ja pitkään tehtyjen kauas ulottuvien toimintasuunnitelmien noudattamisen sijaan yrityksessä tarkastellaan aina syklien päätteeksi, onko yritys matkalla kohti strategian mukaista ideaalitilannetta. On päätettävä, ”pivotoidaanko” – muutetaanko yrityksen toimintaa, tuotetta tai liikeideaa (strategiaa)– vai jatketaanko alkuperäisen strategian mukaan jatkaen tuotteen optimointia (engl. pivot or persevere). Päätös tehdään, kun kysynnäntestaustuotteen innovaatio on mitattu käyttäen innovaatiomittareita ja siitä tiedosta on tehty johtopäätöksiä. Lean Startupin kaltaisella mallilla pystytään tuottamaan asiakkaiden haluamia asioita ja vastataan markkinoiden epävarmuuteen.

Mitä sanovat menetelmät?

Scrumin aikaikkunoidut sprintit estävät nopean reagoimisen ja julkaisusyklin lyhentämisen potentiaaliseen minimiinsä. Scrumissa tuoteomistaja vastaa asiakasrajapinnassa toimimisesta, ja selvittää asiakkaan haluamia ominaisuuksia. Kuitenkin koska tiimi itse valitsee, mitkä ominaisuudet toteutetaan milläkin ajanhetkellä, voi heillä olla vääränlainen käsitys siitä, mitä asiakkaat haluavat, ja tuotantoon saattaa päätyä sillä hetkellä vääriä asioita. Toki tuoteomistaja voi ohjata päätöksentekoa tiettyyn suuntaan, mutta viimenen sana on aina kehittäjätiimillä.

Kanbanin imuohjattu jatkuvaan virtaukseen perustuva tuotanto mahdollistaa tehtävien ottamisen nopeammin tuotantoon. Tuoteomistajan roolin puute voi johtaa heikkoon asiakkaiden kanssa kommunikointiin. Kehittäjätiimin työnkulku voi keskeytyä ja työrauha rikkoutua, mikäli se joutuu toimimaan asiakkaan kanssa, eikä pääse keskittymään tuotantoon.

Scrumbanissa käytetty kanbanin kaltainen tuotantomalli myös mahdollistaa tehtävien nopean aloittamisen. Toisaalta tuoteomistaja huolehtii asiakkaiden tarpeiden kartoituksesta, ja priorisoi ominaisuudet työjonossa jättäen työrauhan kehittäjätiimille.

Voidaan todeta, että Scrumban tarjoaa parhaimman viitekehyksen asiakkaiden tarpeisiin vastaamiseksi nopealla aikajänteellä. Scrumin aikaikkunoidut sprintit voivat johtaa heikentyneeseen reaktiokykyyn, ja Kanbanin tuoteomistajan roolin puute puolestaan huonoon kommunikointiin asiakasrajapinnassa sekä tiimin työrauhan häiriintymiseen.

Vaatimustenhallinta

Vaatimustenhallinta liittyy osittain asiakkaiden tarpeisiin vastaamiseen, ja siinä onnistumiseen. Mikäli kunnollista menettelytapaa ei ole perustettu, voi tuotteelle asetetut vaatimukset muodostua hallitsemattomaksi kokonaisuudeksi. Tuotteelta voidaan vaatia enemmän uusia ominaisuuksia, kuin tiimi voi toimittaa, eikä ominaisuuksien väliltä valitsemiseen ole olemassa hyvää mekanismia. Tämä saattaa johtaa erilaisten sidosryhmien turhautumiseen, kun uusia ominaisuuksia ei saada ulos markkinoille, eikä niiden kehitystä voida seurata.

Mitä sanovat menetelmät?

Kaikki kolme tuotantomenetelmää käyttävät jonkinlaista työjono vaatimustenhallintaan. Scrumissa on kaksi työjonoa, tuotteen ja sprintin kehitysjonot. Scrumbanissa ja Kanbanissa puolestaan käytetään vain yhtä työjonoa, jonka päältä työtä imetään seuraaviin vaiheisiin.

Edellä esitelty tuoteomistaja vastaa kehitysjonon muokkaamisesta. Scrumissa ja Scrumbanissa tuoteomistajan vastuulle jää hallita asiakkaiden ja muiden vaatimuksia. Koska tuoteomistaja toimii aktiivisesti asiakasrajapinnassa, on todennäköistä, että tuotteeseen valikoituu asiakkaiden haluamia ominaisuuksia.

Kanbanissa ei ole määritelty erityistä roolia, joka vastaisi kehitysjonoista. Kuitenkin kanbaniin kuuluu sisäänrakennettuna työjono, jolloin edes jonkinlainen mekanismi vaatimustenhallintaan on olemassa.

Kaikki tuotantomenetelmät ohjaavat työnkulun jonkinlaiseen visualisointiin, ja taulujen avoimuutta säätelemällä voidaan erilaisille sidosryhmille jakaa tietoa muun muassa ominaisuuksien kehitysasteesta. Ainakin Scrumissa ja Scrumbanissa sidosryhmät ovat tervetulleita joihinkin tuotannon vaiheisiin, kuten sprintin loppukatselmointeihin. Tiedon jakaminen ja avoimuus voivat vähentää sidosryhmien turhautumista.

Voidaan todeta, että Scrum ja Scrumban tarjoavat parhaat mekanismit vaatimustenhallintaan. Kanbanissa tuoteomistajan roolin puute voi johtaa väärin priorisoituun kehitysjonoon – varsinkin, jos samaan aikaan vaatimukset ovat yrityksen itsensä keksimiä, huonosti dokumentoituja ja ne validoidaan vasta, kun tuote on markkinoilla.

Tuotteen julkaisemisprosessi

Startupin täytyy julkistaa tuotteensa, jotta siitä on hyötyä. Jotta markkinoiden ja asiakkaiden vaatimuksiin voidaan vastata ja nopeaa julkaisutahtia ylläpitää, on tuotteen julkaisemisprosessin oltava kunnossa. Oire huonosta julkaisemisprosessista on uusien tuotteiden julkaisun kestäminen odotettua kauemmin. Siihen liittyvät toiminnot ovat peräkkäisiä rinnakkaisuuden sijaan ja koordinointi on heikkoa yrityksen sisällä ja erilaisten sidosryhmien välillä.
Nopeaan julkaisutahtiin pyrkiminen saattaa johtaa myös siihen, että tuote julkistetaan liian varhain. Liian varhain julkistettu tuote voi puolestaan sisältää monimutkaisiakin virheitä, jotka aiheuttavat pahimmillaan kriittisiä ongelmia asiakkaille. Asiakkaiden kohtaamat ongelmat johtavat imago-ongelmien lisäksi myös virheilmoituksiin, jotka aiheuttavat ylimääräistä työtä tuotantotiimille ja johtavat uusien ominaisuuksien kehittämisen viivästymiseen.

Mitä sanovat menetelmät?

Scrum ja Scrumban määrittelevät tuoteomistajan roolin. Tuoteomistajan tehtävänä on vastata tuotteen julkaisusta. Hän tarkastaa tiimin tekemän tuoteversion retrospektiiveissa, ja päättää, onko se julkaisukelpoinen vai ei. Hän toimii asiassa yhteistyössä asiakkaan kanssa.

Kanbanissa ei määritellä tuoteomistajan roolia. Se voi huonoimmassa tapauksessa johtaa siihen, että tuotteella ei ole omistajaa, mikä puolestaan johtaa kunnollisen julkaisuprosessin puutteeseen. Kunnollisen julkaisuprosessin puute puolestaan altistaa yllä kuvattuun ongelmatilanteeseen.

Voidaan todeta, että julkaisuprosessin hallintaan Scrum ja Scrumban tarjoavat parhaat mekanismit. Kanbanin rajoituksettomuus voi johtaa siihen, että aihe jää kattamatta

Prosessien keveys

Startupit ovat vastahakoisia ottamaan käyttöön prosesseja tai byrokratiaa, koska ne saattavat haitata startupeille luonnollista joustavuutta, nopeutta ja innovatiivisuutta. Startupien tuotantomenetelmien on oltava kevyitä, jotta ne voivat käyttää resurssinsa ennemmin tuotekehitykseen kuin prosessien ylläpitämiseen. Startupien tuotantomenetelmien täytyy olla joustavia ja reaktiivisia, jotta ne voivat mukautua toimitaympäristön taajaan tapahtuviin muutoksiin.

Mitä sanovat menetelmät?

Scrum on tutkituista menetelmistä kaikkein raskain. Se määrittelee yhdeksän erilaista rajoitetta. Kuitenkin Scrum on verrattain kevyt ja ketterä verrattuna useisiin muihin ohjelmistotuotantomenetelmiin, kuten eXtreme Programming tai Rational Unified Process.

Kanban on kaikkein kevein tutkituista menetelmistä. Puhtaassa Kanbanissa on vain kolme rajoittavaa tekijää. Vaikka Kanban on näennäisesti kevein menetelmä, liika vapaus voi johtaa suuriin ongelmiin, mikäli muun muassa edellämainittuihin haasteisiin ei osata reagoida järkevästi. Lisäksi puhdasta Kanbania harvoin käytetään sellaisenaan.

Scrumban sijoittuu hieman variaatiosta riippuen jonnekin Scrumin ja Kanbanin välimaastoon. Scrumban pyrkii asettamaan juuri tarvittavan määrän rajotteita, ettei erityisesti Kanbanin tapauksessa havaittuja vaaranpaikkoja pääse syntymään, mutta säilyttäen kuitenkin tarvittavan joustavuuden, jotta markkinoiden nopeisiin muutoksiin voidaan vastata.
Mikään tutkituista menetelmistä ei ole merkittävästi liian raskas toimiakseen startupin pääasiallisena ohjelmistotuotantomenetelmänä. Kuitenkin Scrumbanin kohtuulliset rajoitteet ja säilynyt joustavuus voidaan tulkita startupin kontekstiin parhaiten sopivaksi.

Tulokset – voittaja: Scrumban

Taulukossa 1 on koottuna yhteen edellisissä kohdissa käsitellyt startupien ongelmakohdat, kunkin ohjelmistotuotantomenetlmän tarjoamat ratkaisut ongelman ratkaisemiseksi, ja analyysin lopputuloksena parhaaksi valittu ratkaisu kuhunkin ongelmaan.

Taulukko 1 Yhteenvetotaulukko

Ongelmakohta Scrumin ratkaisu Kanbanin ratkaisu Scrumbanin ratkaisu Paras ratkaisu
Tiimien koostumus Poikkitoiminnalliset tiimit Ei erityistä ratkaisua Poikkitoiminnalliset tiimit Scrum, Scrumban
Tiimin yhteispeli Scrum Master: palveleva johtaja Ei erityistä ratkaisua Scrum Master: palveleva johtaja Scrum, Scrumban
Ei tuoteomistajaa Tuoteomistajan rooli Ei erityistä ratkaisua Tuoteomistajan rooli Scrum, Scrumban
Vastaaminen asiakkaiden tarpeisiin + Tuoteomistaja

-Aikaikkunoitu sprintti

+ Ei aikaikkunoitua sprinttiä

-Ei tuoteomistajaa

+ Ei aikaikkunoitua sprinttiä, tuoteomistaja Scrumban
Vaatimustenhallinta + Tuoteomistaja, tuotteen kehitysjono + Tuotteen kehitysjono

-Ei tuoteomistajaa

+ Tuoteomistaja, työjono Scrum, Scrumban
Tuotteen julkaisuprosessin puute + Tuoteomistaja, retrospektiivit Ei erityistä ratkaisua + Tuoteomistaja, retrospektiivit Scrum, Scrumban
Prosessin keveys Raskain +/- Kevein Sopivassa suhteessa rajoituksia ja joustavuutta Scrumban

Kuten taulukosta voidaan todeta, Scrumban tarjoaa tyydyttävän ratkaisun kaikkiin käsiteltyihin ongelmakohtiin. Toiseksi parhaiten startupien ongelmakohtiin onnistuu vastaamaan Scrum, ja huonoiten puhdas Kanban.
On kuitenkin huomattava, että Kanban sallii huomattavat määrät erilaisia ratkaisuja tiimien ja yritysten yksilöllisiin tarpeisiin. Erilaiset lisäratkaisut kuitenkin siirtävät menetelmän pois puhtaan Kanbanin alueelta, ja tuloksena syntyy esimerkiksi Scrumbanin kaltaisia hybridejä.

Mitä mieltä olet Scrumbanista? Onko se mielestäsi vakavasti otettava kilpailija Scrumille? Käsittelen omia mielipiteitäni Scrumista erillisessä artikkelissa. Osallistu keskusteluun kommenteissa, ja linkkaa ihmeessä artikkeli tuttavillesi, jotka painivat ohjelmistotuotantomenetelmien ja haasteellisten toimintaympäristöjen keskellä.

Kommentoi

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