Menetelmät ovat kuin työkaluja. Aivan kuten lusikkaa on hölmöä verrata haarukkaan ilman tietoa ruoasta, on ensin määriteltävä mihin Scrumia tai Kanbania ollaan käyttämässä.
Eräs Scrum-kurssin oppilas pyysi kuvittelemaan seuraavan tuotekehitysprojektin:
Kokenut, hyvin toimiva ja itseorganisoitunut kehitystiimi.
Asiakkaat ja sidosryhmät osallistuvat aktiivisesti viikoittaiseen katselmointiin.
Kehitystiimi pitää tehokkaan retrospektiivin kahden viikon välein.
Lähes täydellinen tuoteomistaja.
Järjestetty, työmääräarvioitu ja hyvin työstetty tuotteen kehitysjono.
Jatkuvan integroinnin alusta, jossa julkaisumahdollisuus nappia painamalla.
Kehityksen vauhti on tiedossa, koska se mitataan kuukausittain.
Oppilaan kysymys oli, mitä hyötyä Scrumista on tällaiselle kehitystiimille tai yritykselle? Ja mitä hyötyä on sprintin suunnittelusta ja itse sprintistä? Eikö sprintti ole oikeastaan keinotekoinen aikaraja tällaiselle tiimille?
Hetken verran iski tyhjää… Minulla ei ole mitään Kanbania vastaan, päinvastoin kouluttajana kannustan käyttämään kulloinkin parhaiten sopivia työkaluja.
If you only have a hammer, you tend to see every problem as a nail. -Abraham Maslow
Oppilaan kysymys Scrumin hyödyllisyydestä on kuitenkin paradoksaalinen, koska määritelmän lähes jokainen rivi sisältää jonkin Scrumin elementin. Päästäkseen kuvatulle kypsyysasteelle kehitystiimi on omaksunut syvällisesti Scrumin elementit ja käytännöt. Scrum on siis mahdollistanut kuvatun kypsyystason.
Sprintin suunnittelupalaverin ensimmäinen hyöty on, että systemaattisuus vähentää monimutkaisuutta: Sprintin suunnittelupalaveri tuo säännöllisesti yhteen Scrum-tiimin ja sidosryhmien edustajat ilman tapauskohtaisia kokousjärjestelyitä, joihin uppoaa usein paljon aikaa ja energiaa.
Toinen sprintin suunnittelupalaverin hyöty on kasvokkain tapaaminen: Ihmiset joutuvat perustelemaan ja ymmärtämään vaatimuksia, designia ja tavoitteita. Tämä johtaa parempaan priorisointiin, motivaatioon ja työhön sitoutumiseen. Kehitystyötä ei pitäisi koskaan aloittaa ilman tällaista keskustelua, eikä tuoteomistaja välttämättä ehtisi käydä briiffaamassa kehitystiimille uutta ominaisuutta juuri silloin, kun sen kehitys Kanban-mallissa voidaan aloittaa.
Kolmanneksi sprintti antaa kehitystiimille selkeän yhteisen tavoitteen. Ilman tavoitteita unohdumme helpommin vääriin detaljeihin ja myöhästymme. Kehitystiimin yhteisen tavoitteen asettaminen ja saavuttaminen sprintin sisällä ei kehitä ainoastaan tuotetta vaan myös kehitystiimiä, koska tavoitteen saavuttamisesta saatava yhteinen onnistumisen tunne ja motivaatio tukevat tiimin yhteen hioutumista. Onnistumisen tunne on Scrumissa tärkeä sivutuote toisin kuin Kanbanissa, jossa on samantekevää onko työntekijä robotti vai ihminen, eikä siinä siksi oteta kantaa motivoimiseen.
Kanban is a material and information flow management tool.
Neljänneksi sprintti antaa työlle tahdin – kuin sydämen sykkeen – jossa koko organisaatio ja asiakkaat oppivat työskentelemään. Julkaisusuunnitelmia voidaan tehdä helpommin ja toistuva tahti antaa henkistä tukea monimutkaisen työn tekemiselle. Sprintit tuovat säännöllisesti yhteen koko organisaation viisauden (esim. tuoteomistajan, sidosryhmät, markkinoinnin, aikataulut) tuotteen onnistumisen optimoimiseksi.
Kanban houkuttelee minimalisminsa vuoksi. Koska se ei määrittele muuta kuin työn virtauksen, määritellään kaikki roolit, kokousrutiinit ja dokumentit tiimi- ja organisaatiokohtaisesti. Siis ikäänkuin rakennetaan oma Monopoli-peli sen sijaan, että pelattaisiin tunnettua Monopolia, jonka säännöt kaikki tuntevat.
Kannattaa siis miettiä mihin ja kuinka Kanbania soveltaa ja onko tiimillä riittävä kypsyystaso, jottei lopputuloksena ole komeasti nimetty adhoc-prosessi, jossa muutoksia tehdään milloin tahansa jonkun pyytäessä.
Lisää luettavaa:
Ken Schwaber: Waterfall, Kanban, and Scrum
Samuli Heljo: Reflections on Scrum and Kanban Development
Kate Terlecka: Lessons on Combining Kanban and Scrum
Lare Lekman: Mikä ihmeen Kanban?
Comments