Sovelluskehitystä voi toteuttaa monella eri tapaa ja jo jonkin aikaa ketterät menetelmät ovat olleet esillä parempaan lopputulokseen pääsemiseksi. Ketterät menetelmätkään eivät ole mitään hopeisia luoteja, vaan vaativat menetelmään perehtymistä, sopivien toimintatapojen kehittämistä ja organisaation kouluttamista uutta ajattelutapaa ajatellen. Osallistuin viime viikolla Reaktorin vetämälle ”Käytännön Kanban” -kurssille, jossa perehdyttiin yhteen menetelmään toteuttaa sovelluskehitystä ketterästi läpinäkyvämmin ja paremmin.
Kanban-menetelmä
Lyhyesti tiivistettynä Kanban-menetelmän ideana on toimintatavan ja työtehtävien visualisointi taulujen avulla ja rajoittaa käynnissä olevan päällekkäisen työn määrää ja pyrkiä saamaan työkokonaisuuksia valmiiksi nopealla tahdilla. Uutta työtä ei oteta sisään ennen kuin nykyiset on saatu valmiiksi. Tavoitetta kuvaa iskulause: ”Lopeta aloittaminen, aloita lopettaminen!” eli ”Stop Starting and Start Finishing!”. Prosessin ja organisaation nykytilan ymmärtämisen kautta tavoitellaan kysynnän ja kyvykkyyden tasapainon ylläpitämistä sekä asteittaista parantamista. Kanban-menetelmä liittyy Lean– ja Just-In-Time -ajatteluun ja sana ”kanban” tulee Japanista tarkoittaen visuaalista merkkiä.
”Kanban-menetelmällä tiimi pystyy hallinnoimaan, ennakoimaan ja rytmittämään tapahtumien kulkua tehokkaasti työssään. Menetelmä auttaa tiimiä ymmärtämään, kuinka työ toimii ja tekemään oikeita päätöksiä oikeaan aikaan. Kanban kertoo, milloin kannattaa aloittaa, hiljentää ja lopettaa aktiviteetit työn eri vaiheissa — nykytilanne ja ongelmat on helppo nähdä ja ymmärtää yhdellä silmäyksellä.” – Reaktorin Käytännön Kanban -kurssi
Käytännön Kanban -kurssi
Osallistuin viime viikolla Reaktorin Käytännön Kanban -kurssin, jonka aikana käsiteltiin menetelmän teoreettinen perusta, tärkeimmät periaatteet ja tutkittiin käytännönläheisesti Kanbanin soveltamista. Kerrankin koulutuksen painopiste oli sanalla käytäntö ja se toteutui mielestäni hyvin luentojen, tarinankerronnan, ryhmäkeskustelujen ja harjoitusten avulla. Koulutus painotti aktiivista oppimista ja kaksipäiväisen koulutuksen aikana opimme käytännön harjoitusten avulla muun muassa:
- Kanban-menetelmän ottaminen käyttöön päivittäisessä työssä olemassa olevia toimintatapoja, rooleja ja vastuita kunnioittaen
- Nykyisen toimintatavan visualisointi selkeästi ja ymmärrettävästi
- Tiimityöskentelyn, tuottavuuden ja laadun kehittäminen järjestelmällisesti
- Esteiden tunnistaminen ja poistaminen tiimien työssä
- Työn kehittäminen kurssin aikana opittujen mittareiden avulla
Ensimmäinen päivä
Koulutuksen ensimmäisenä päivänä käytiin lyhyesti läpi menetelmän teoreettinen perusta ja tärkeimmät periaatteet, mutta asioiden läpikäynti painottui esimerkkeihin ja tarinoihin, eikä kalvoilta asian läpikäymiseen, mikä toimi mainiosti asian sisäistämisessä. Päivän aika aihetta läpikäydessä ei tullut niinkään tunnetta, että käsiteltäisiin juuri Kanbania, vaan miten töitä pitäisi tehdä parempaan lopputulokseen pääsemiseksi ja miten Kanban-menetelmä liittyy siihen.
Kurssin pitäjät, Sami Lilja ja Sami Honkonen, ovat käsitelleeet kurssin asioita blogikirjoituksissaan kuten Importance of pull, WIP limits and Kanban system ja How to fix 90% of problems at work, jotka liittyvät ja käsittelevät Kanbanin kolmea ensimmäistä periaatetta.
Teorian läpikäynnistä muistiin kannattaa pistää ainakin Littlen laki (läpimenoaika = keskeneräinen työ / nopeus), eli mikä on keskimääräinen aika tehtävän läpisaattamiseksi. Ei kannata ahnehtia liikaa töitä, sillä eivät ne yhtään nopeammin valmistu. Usein organisaatio yrittää kasvattaa nopeutta, mutta merkittävämpi tulos on pienentää keskeneräisen työn määrää. En tässä käy tarkemmin läpi muita esitettyjä asioita, mutta mainittakoon ”vaihteluväli, ei trendi” (regression to mean), ”kyvykkyys vs. kysyntä” ja ”työn kirjo”. Myös Scrum-bania sivuuttiin nopeasti.
Käytännön ensikosketuksen Kanban-menetelmään sai tehokkaasti GetKanban-pelillä, joka osoitti loistavasti mistä menetelmästä on kyse ja miten sovelluskehityksessä eri vaiheiden merkitys ja läpimenoaika näkyvät lopputuloksessa. Pelin avulla näki, miten Kanban teki työn eri vaiheista läpinäkyvää ja työn tekemisen esteet olivat helpommin ennakoitavissa ja poistettavissa. Tosin peli heitti eteen muutamia poikkiteloja kuten Carloksen ja Peten, joihin oma tiimini kompastui. Ohjelmistokehitystiimin työssä Kanban helpottaa havaitsemaan, onko työn eteneminen estynyt, mikä estää työn etenemisen, mitä on työn alla tällä hetkellä tai kuinka paljon töitä on odottamassa. Toisella pelikerralla tiimini onnistui pelissä paremmin, kun analysoimme hieman tikettien mahdollista läpimenoa, toteutimme automaattiset testit ja muutimme WIP-rajoja. Eli kuten käytännössäkin pitäisi tehdä :)
Päivän päätteeksi esiteltiin Case-esimerkki ”Oma Elisa”-palvelun kehittämisestä ja Ray.fi -sivuston kehityksestä ja millaisia Kanban-tauluja tiimeillä oli ollut käytössä. Muutamina poimintoina esimerkeissä luovuttiin sprinteistä, ei tehty planningia vaan työtä lisää kun tarve ja estimointi tehtiin T-paita koolla läpimenoajasta, ei työmäärästä. Scrumista säilytettiin demot ja retrot ja 2 viikon välein tuotantoon. Lisäksi väki organisoitui vapaammin, ei ollut kiinteitä tiimejä ja WIP-rajat pakottivat parikoodaukseen. Päivittäisissä tilannekatsauksissa käytiin läpi vain laput, jotka olivat olleet pitkään boardilla (täppä per päivä lappuun). Backlogia ei täytetty jatkuvasti, vaan lämmittelyboardilta tuotiin lisää tavaraa, kun noin 2 viikon työt jäljellä.
Esimerkeistä keskustelua herättivät muun muassa miten eri osa-alueet ja niiden hallinta menivät käytännössä ja miten ”päivittäinen agenda” ja ”miten löydän töitä” toimivat käytännössä. Yksinkertaisuudessaan ne voisivat olla seuraavat:
Toinen päivä
Koulutuksen jälkimmäisenä päivänä keskityttiin Kanbanin soveltamiseen ja osallistujien omien projektien tarkoitukseen ja Kanban-taulujen pohtimiseen. Päivän aikana toteutettiin viisi eri taulua, joka osoitti käytännössä, että Kanban-menetelmä on suhteellisen helppo ottaa käyttöön kaikenlaisissa tiimeissä, eikä liikkeelle pääseminen ei vaadi isoja muutoksia työtapoihin. Organisaation prosesseja lähdetään muokkaamaan asteittain ja askel kerrallaan, ja samalla seurataan jatkuvasti palautetta ja saatuja tuloksia.
Kanban-taulun kehittämisen pohjaksi on hyvä muistaa ja pohtia seuraavia asioita:
Tässä pari esimerkkiä tuotoksista:
Kanban-taulun suunnittelussa kaikkia tehtäviä ei välttämättä kannata merkitä boardille. Esimerkiksi jos on paljon pieniä tehtäviä, eli kohinaa, hyväksytään se. Sitä ei kannata merkata boardille, mutta kannattaa jotenkin seurata sitä, esimerkiksi tukkimiehen kirjanpidolla. Eli nähdään paljon menee aikaa tiskin alta ja triviaaliin työhön.
Systeemiajattelu
Kanban-menetelmän ja mielestäni työelämään yleisestikin liittyvien asioiden lisäksi koulutuksessa käsiteltiin lyhyesti myös systeemiajattelua ja mistä kokonaisuus ja sen suorituskyky muodostuu. Asiaa avasi hyvin Russell Ackoffin ~8 minuutin puhe systeemiajattelusta (tai vitsien kera). ”Systeemi ei ole osiensa summa, vaan yhteistoiminnan tulos”. Asiaa selventää hyvin myös Honkosen ”You are part of a system” -kirjoitus.
Aiheeseen liittyen käsiteltiin myös arvo- ja häiriökysyntää (Value Demand ja Failure Demand). Asiaa pitää katsoa asiakkaan näkökulmasta, jolloin arvokysyntä on sitä, jota asiakas haluaa ja häiriö kaikkea muuta, kuten bugeja, muutospyyntöjä ja huonoa käyttöliittymää. Lisäksi yrityksen sisäistä häiriökysyntää ovat muun muassa raportointi, palaverit, infrahäiriöt ja odottaminen. Arvioilta 80 prosenttia työstä on häiriökysyntää ja vain 20 prosenttia arvokysyntää, eli sitä mitä pitäisi oikeasti tehdä. Kanban auttaa tekemään häiriökysynnän näkyväksi. Jotkut organisaatiot keskittyvät tekemään häiriökysyntää, kun pitäisi keksittyä tekemään arvokysyntää. Kannattaa olla täten tarkkana, ettei Kanbanilla hallita häiriökysyntää.
Muita läpikäytyä asioita olivat ”tarkoitus -> mittaus -> menetelmät”, ”oikeiden asioiden tekeminen oikein”, ”kysyntäanalyysi” ja ”kysyntä -> arvo -> virtaus”.
Yhteenveto
Reaktorin Käytännön Kanban -kurssin aikana käsiteltiin menetelmän teoreettinen perusta, tärkeimmät periaatteet ja tutkittiin käytännönläheisesti Kanban-menetelmän soveltamista. Kerrankin koulutuksen painopiste oli sanalla käytäntö ja se toteutui mielestäni hyvin luentojen, tarinankerronnan, ryhmäkeskustelujen ja harjoitusten avulla. Kurssilla käsiteltiin paljon asioita ja ongelmia, jotka ovat maalaisjärjellä ajateltuna selviä, mutta ikävän todellisia työpaikoilla. Keskustelu oli antoisaa ja herätti ajatuksia, miten asioita pitäisi kehittää.
Kurssin kuvaus lupaa paljon hyviä lopputuloksia ja ideana ja tavoitteena Kanban-menetelmä vaikuttaa lupaavalta kaaoksen hallintaan. En voi kuitenkaan sanoa, että kurssilla opituista asioista on ollut välittömästi hyötyä oman organisaationi työn kehittämisessä, mutta hitaasti eteenpäin kuitenkin. Tavoitteena on ottaa kurssilla opittuja asioita käyttöön, mutta uuden menetelmän ottaminen samantien osaksi päivittäistä työtä ei ole niin yksiselitteistä etenkään jäykässä organisaatiossa.
Kurssilta sai lisäksi mukaan David J. Andersonin Kanban -teoksen ja kätevän Kanban-lehdykkeen kiireisille johtajille. Lisäksi pitänee lukaista lisää kurssilla käsitellyistä aiheista muun muassa Henrik Knibergin Lean from the Trenches -kirjasta (PDF) ja pohtia Modig Åhlströmin Tätä on Lean -teoksen tai Daniel Kahnemanin Thinking, Fast and Slow -kirjan hankkimista.
Päivitys 28.11.2014: Osallistuin Käytännön Kanban -kurssille toistamiseen loppusyksystä ja tällä kertaa vain oman yksikköni väen kanssa, joka antoi paremman lähestymisen tiimin ongelmien ratkaisemiseen. Sami Lilja veti jälleen mainion kurssin ja sisältö oli suurin piirtein sama kuin keväällä. Nyt oman Kanban-taulun kehittämiseen oli hieman enemmän käytännön kokemusta, mutta osittain myös väen vaihtumisen takia ongelmat olivat samat. Mitä tehdä, kun henkilö on useassa eri asiakkaan projektissa ja ylläpidossa. Miten rajoittaa multitaskingia ja työn hajautumista. Tähän ei vielä löytynyt vastausta, mutta on tärkeää, että ei manageroida henkilöitä, vaan asiakkaalle tehtäviä tehtäviä.
