Tietopankki – agile ammattisanasto

Mikä ihmeen agile, tämä mystisen ammattisanaston kaikenkokoava kunkku? Agile eli ketterä tekeminen on pohjimmiltaan sateenkaari, jonka päässä loistaa kokoelma työyhteisön kannalta hyväksi todettuja arvoja ilman varsinaista metodologiaa eli oppia tarkemmista menetelmistä.

Agile-ajattelun ja arvojen synnyinkoti on kokemusperäisessä eli empiirisessä tavassa ymmärtää maailmaa. Empiirinen taas meinaa sitä, että kaikki mitä tiedämme tulevasta perustuu siihen, mitä olemme voineet oppia menneestä. Ei sen kummempaa.

Termi empiria tarkoittaa siis kaikkea sitä konkreettista mitä voimme nähdä, kokea, ja aistia – eli esimerkiksi esineitä, ihmisiä ja muita konkreettisia tapahtumia. Ajatus on, että todellisuudesta irrallaan olevan Excel-hutun sijaan päätöksen tekoa pohjataan näihin asioihin.

Toinen tärkeä astinlauta agile-sateenkaaren päähän on lean-ajattelu. Termi lean tarkoittaa amerikaksi hoikkaa ja solakkaa, ja juuri sitä lean-ajattelussakin tavoitellaan – pyritään karsimaan kaikkea turhaa, ja keskittymään olennaiseen, eli vähentämään hukkaa. Lean on siis liiketoiminnan oheistoimintoihin ja byrokraattiseen säätöön kohdistuva laihdutuskuuri. Jokainen “liinisti” toimiva ammattilainen miettii aina kerran tai kaksi, onko tässä minun ja meidän touhussa nyt jotain järkeä? Millä rutiineilla ja tekemisillä tuotamme eniten arvoa? Millä tauhkalla taas mahdollisesti jopa vähennämme sitä?

Agile-kattotermin syntyperillä käytiin salaperäinen tulevien agilekunkkujen kokous, jonka jälkeen julkaistiin agile manifesto. Tämä nelikohtainen julistus toimii edelleen ketterän toimintatavan perustana.

Lisäksi julistuksen selittämiseksi sama poppoo julkaisi edelleen käytössä olevat 12 agile-tekemisen periaatetta.

Lisäksi agile-ajattelun tueksi on olemassa kokoelma keskeisiä ketteriä menetelmiä, eli hyväksi todettuja tapoja, joilla nämä julistukset voi viedä käytäntöön. Ei siis kannata keksiä pyörää uudelleen, ellei sitten ole sähköpyörä-bisneksessä.

Menetelmiä edistämään on olemassa joukko keskeisiä agile-tekemisen rooleja, jotka ovat tulleet tutuiksi varsinkin laajasti käytetystä Scrum-viitekehyksestä.

Mitä se agile sitten on? Kysyimme meidän koneilta ketteriltä konsulteilta ja saimme mm. seuraavia yhteenkokoavia määritelmiä:

Agile on keskittynyttä, systemaattista muutokseen vastaamista. Agile on arvontuottamista nopeammin siksi, että kaikessa mitä tehdään, varmistetaan, että tehdään asioita – ja vain niitä asioita – joista oikeasti on hyötyä. Eli ne tuottavat arvoa asiakkaalle, kollegalle tai muulle palveltavalle taholle.

Agile on henkilöiden välistä oikeaa keskustelua ja yhteistyötä dokumentaatiofetissin tai organisaatiopelin sijaan. Se on aitoa, sydämellistä välittämistä kollegoista ja asiakkaista. Se on sitä, että keskustellaan läpinäkyvästi ja opitaan yhdessä, sen sijaan, että yritetään kaunistella numeroita osakkeen omistajalle tai pomolle ennen tavoitekeskustelua. Agile on syklistä ja iteratiivista tekemistä, jossa opitaan koko ajan itsestä ja muista.

Agile-maailman elämänkoulussa ei ole siis ole pinnaajia, kiusaajia ja lunttaajia, paitsi ehkä hyvien käytäntöjen rohkean kopioimisen osalta.

Agile on pyrkimys hyvään ja merkitykseen. Se on turhan korvaamista merkityksellä. Kuten yksi agile-kunkuista Jeff Sutherland kirjassaan muotoili (vapaa suomennos): “Merkityksetön työ ei ole ainoastaan huono liiketoiminnalle. Se tappaa sielun.”

Agile-kattotermin syntyperillä käytiin salaperäinen tulevien agilekunkkujen kokous, jossa keskusteltiin ja pyöriteltiin tuntikaupalla, miten kiteyttää se johtoajatus uudistuksista, jotka porukka selkeästi jakoi ajatuksen tasolla mutta ei osannut nimetä. Lopulta valkotaululle syntyi seuraava julistus, joka elää edelleen. “Arvostamme

• Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja
• Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota
• Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja
• Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa

Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän.“

Mitäs tämä nyt sitten aikuisten oikeesti kohta kohdalta meinaa?

Ensiksi on kommentoitava yleisesti kohtaa “jälkimmäisilläkin on arvoa”. Kun alat levittämään innolla agile-sanomaa aivan uudessa ympäristössä, saatat kohdata muutosvastarintalintujen lirkutusta juuri siltä osin, että agile-maailmassa jätettäisiin kaikki suunnittelematta, dokumentoimatta, tai sopimatta.

Ei.

Julistus puhuu prioriteeteista. Se puhuu siitä, minne suurin osa energiastamme ja tekemisestä ohjataan. Esimerkkinä julistuksessa ei sanota, ettei ohjelmistokehitystiimin tulisi tuottaa enää mitään dokumentaatiota. Se vain asettaa arvojärjestyksessä ensimmäiseksi sen, että se mitä me dokumentoimme, ylipäänsä toimii ensin. Muutenhan koko dokumentaatio muuttuu teoreettiseksi vitsikirjaksi.

Yksilöt ja kanssakäymiset

Meillä on kaikilla korvat, suu ja aivot. Keskustelkaamme siis. Usein lyhytkin keskustelu, jossa yritämme oikeasti ymmärtää toisiamme ja käsillä olevaa aihetta johtaa suurempaan ymmärrykseen kuin kasa kiiltäviä PowerPoint-slaideja FYI-viesteissä. Tiedäthän sen ihanan tunteen, kun joskus pelkkä asian ääneen sanominen parhaalle kaverille auttaa jo samassa sekunnissa keksimään ratkaisun? Sama pätee työelämässä. Luovuus piilee aidossa kanssakäymisessä, ratkaisut ikään kuin kuplivat esille meistä, kun olemme aidosti läsnä. Älä siis piiloudu sinne JIRAan hyvä ihminen. Vetäise kollegaa hihasta.

Toimiva ohjelmisto

Alkuperäisessä julistuksessa puhutaan ohjelmistosta, koska agilen kehto oli ketterässä ohjelmistokehityksessä, mutta termi voidaan tänä päivänä ymmärtää kattamaan mitä tahansa yrityksesi palvelua tai tuotetta. Koska hei, miksi se olisi vaan niiden devaajien ja koodareiden oikeus toimia yhdessä fiksummin?

Tällä julistuksen kohdalla tarkoitetaankin tarjoomasta riippuen seuraavaa: on paljon tärkeämpää, että myymämme asia toimii oikeasti käytännössä ja tekee, mitä luvataan, kuin kirjoittaa tuhansia sivuja siitä, miten sen pitäisi ehkä toimia tai miten se on saatu toimimaan juuri sillä tavalla.

Asiakasyhteistyö

Asiakasyhteistyön nostamisella toiminnan keskiöön sopimusneuvottelujen sijaan tarkoitetaan sitä, että on varsin lyhytnäköistä ajatella, että mikäli me olemme tehneet nyt kaiken sen mitä alunperin pyydettiin, niin lälläslää, olemme onnistuneet vaikka olisitkin muuttaneet mieltäsi. Tätähän sinä pyysit!

Todellisuudessa ihmisten odotukset ja toiveet kehittyvät koko ajan maailman mukana. Voi myös olla vaikeaa oikeasti ymmärtää itseään ja omia toiveitaan, ennen kuin näkee jotain konkreettista.

Ajattelepa vaikka, että päättäisit tehdä Pientä Pintaremonttia kotonasi puolison kanssa. Hahmottelette minkä värisen seinän, millaiset listat, millaisen valaistuksen ja millaiset huonekalut tilaan haluat. Aika usein puolisosi hermot ovat palaneet jo siinä vaiheessa kun se seinä on lopulta saatu maalattua, koska saatatkin nähdessäsi seinän oikeasti muuttaa äkisti mieltäsi lopuista asioista. Tai toteatkin, että tämä väri ei olekaan luonnossa isolla seinällä sellainen kuin pienestä värinäytteestä kuvittelin.

Sama pätee asiakkaasi tarpeisiin, oli asiakkaasi sitten toinen yritys, kuluttaja, tai vaikka sisäinen, toinen osasto. Siksi ketterästi toimiessa pyritään toteuttamaan asiakkaan toiveita pienissä paloissa, ja mukauttamaan sitten palautteen perusteella tulevaa. Koska lopulta, vaikka voisitkin todistaa olevasi oikeassa alkuperäisen tilauksen suhteen, ainoastaan täyttämällä asiakkaan todelliset toiveet vähitellen sinulla on tyytyväinen asiakas vielä huomennakin.

Eli ei käytetä kuukausikaupalla aikaa siihen, että yritetään naulata kaikki asiat kiinni “sopimukseen”, jossa on kiinnitetty aikataulu sekä sisältä, ja jolla voi sitten paukuttaa kumppania päähän kun asiat muuttuvat ja käytetään hulppeat summat rahaa muutoshallintaan. Sen sijaan, lähdetään liikkeelle perusasioilla: millaisella tiimillä asiat tehdään, mikä on tavoite, minkälaisella backlogilla toimitaan? Sitten lähdetään ketterien periaatteiden mukaisesti etenemään siten, että aina säännöllisin väliajoin demotaan, mitä on saatu aikaiseksi ja muutetaan suuntaa tarvittessa.

Vastaaminen muutokseen

Jos katsot nyt loppuviikon säätiedotusta ja siellä povataan sadetta, laitatko perjantaina päälle sadetakin, vaikka aurinko sittenkin helottaisi täydeltä taivaalta? Tuskinpa vain. Miksi siis toimisit näin työpiirissä?

Niin hassulta kuin se kuulostaakin, ei työprojekteissa ei ole perinteisesti tavatonta pyöriä väärässä vaatetuksessa sään muuttuessa. Tämä johtuu siitä, että perinteisesti operatiivisessa suunnittelussa ja johtamisessa on arvostettu ennustettavuutta ja pitkän tähtäimen suunnitelmia empiirisen reagoinnin sijaan.

Ketterän arvoista yksi tärkein onkin siis vastaaminen muutoksen. Muutoksen syleily innolla ja uteliaisuudella on se ratkaiseva tekijä, joka tekee ketterästä tiimistä kompetentin vielä ylihuomennakin.

Backlog (työjono) on tehtävälista asioista, jotka tämän hetken tiedon perusteella pitää vielä tehdä projektissa tai työssä. Se on kuin kauppalista, jossa on täydennyksiä perustarvikkeisiin sekä huomisen ruuan reseptissä tarvittavat aineet.

Projektitöissä tämä lista sisältää kaikenlaisia tiimin tehtäviä, kuten uusia ominaisuuksia, virheiden korjauksia tai muita parannuksia.

Erityisesti ketterässä tuotekehityksessä, kuten Scrumissa, backlog on keskeinen työkalu. Siinä tehtävät (tyypilisesti käyttäjätarinat, “user stories”) järjestetään tärkeysjärjestykseen, ja niitä päivitetään säännöllisesti projektin edetessä. Tarpeettomat ja vanhentuneet asiat poistetaan listalta, mutta jokin tärkeä asia saattaa pistää järjestyksen aivan uuteen uskoon.

Backlog sisältää myös tuotteen tavoitteen – kenelle ja miksi tätä tuotetta rakennetaan, ja mitä asiakkaan ongelmaa ollaan ratkaisemassa.

Yleisemmin backlog voi viitata mihin tahansa kertyneeseen, tekemättömään työhön, joka odottaa huomiota tai suorittamista. Myös oma todo-listasi on backlogi.

Milloin joku asia on valmis? Valmiin määritelmä on sellainen muodollinen lista tai kuvaus, joka auttaa tiimiä tarkistamaan, että valitut asiat on tehty laadukkaasti ja kunnolla. Kun sovitaan yhdessä milloin joku asia on tehty, ei tarvitse kiistellä siitä, onko lasi puoliksi tyhjä vai puoliksi täynnä.

Organisaatiossa saattaa olla yhteinen valmiin määritelmä, jos siellä on jo monta Scrum-tiimiä työn touhussa. Jos ei, tiimi voi keskustellen kehittää tämän määritelmän itse. Vähintään olisi hyvä edes keskustellen varmistaa, että jokainen tiimijäsen ymmärtää määritelmän samalla tavalla.

Valmiin määritelmä riippuu aina tiimin tavoitteesta ja kontektista, mutta siellä voi esiintyä esimerkiksi seuraavanlaisia asioita:

• Peer review eli kaverin katselmus koodille tai toteutukselle tehty!
• Tietoturva varmistettu, automaattiset testit ajettu
• Oikoluettu
• Dokumentaatio päivitetty
• Toteutus testattu eri laitteilla

Mitä tahansa mikä meidän ympäristössämme kertoo sen, että olemme tsekanneet ne kulmat, jotka varmistavat työmme laadun.

Olipa kerran ennen DevOpsia erikseen Development ja Operations. Sitten jollain syttyi lamppu, että hei, eikös nämä kehitys ja ylläpito liity aika olennaisesti toisiinsa, ja niitä voisi tehdä enemmän käsikädessä rallatellen kuin kahtena eri siilona. Hyvin kärjistäen voisi sanoa, että laatu ylipäätään on parempaa, kun kehittäjät ottavat vastuuta myös ylläpidosta, eli joutuvat miettimään minkä kanssa sitten elävät, jos tekevät sutta ja sekundaa. Toisaalta ylläpito-tehtävissä mietitään myös tulevaisuutta, eikä junnata vanhassa. Ajatellaan asiaa niinkuin sen asiakkaan kannalta, joille nämä ovat yksi ja sama kokemus, ja joka ei välitä organisaatiopeleistä. Näin syntyi DevOps!

Nykyään DevOps on kasvanut tästä käytännöllisestä, lähinnä pilvipalveluihin liittyvästä rajauksesta kokonaisvaltaisemmaksi filosofiaksi ja eräänlaiseksi moottoriksi, joka kattaa laajemman skaalan tekemistä, ajattelua ja työkaluja, sekä rooleja aina kehityksestä tuotehallintaan. DevOpsin sateenvarjon alle voi laskea myös kokoelman liiniä ja agilea tekemistä läheisesti tukevia periaatteita, esimerkiksi vahvan pyrkimyksen laadukkaaseen automaatioon prosesseista ja julkaisuista tietoturvaan. Toistuvien prosessien automaatio onkin DevOpsin ytimessä: sekä ajan säästön että laadun varmistamisen vuoksi. Esimerkiksi tietoturvatestien automaatio ja julkaisuputken automaatio voivat olla DevOps-tiimin tärkeitä tavoitteita.

DevOps on osoittautunut sen verran fiksuksi ohjenuoraksi tehdä hommia, että nykyään puhutaankin trendikkäästi myös monista alakäsitteistä aina SecOpsista DesignOpsiin, riippuen siitä, mille vastuualueelle sieltä tuttuja ajatuksia ja työkaluja milloinkin sovelletaan.

Empiirinen meinaa yksinkertaisesti sitä, että se mitä tiedämme tulevasta, perustuu siihen mitä olemme voineet oppia menneestä. Ei sen kummempaa. Termi empiria tarkoittaa kaikkea sitä konkreettista mitä voimme nähdä, kokea, aistia-eli esimerkiksi esineitä, ihmisiä ja muita konkreettisia tapahtumia. Ajatus on, että todellisuudesta irrallaan olevan Excel-hutun sijaan päätöksen tekoa pohjataan niihin konkreettisiin asioihin jotka ovat oikeasti tapahtuneet ja joita voimme järjellä ymmärtää ja todentaa.

Empiristi arvostaa tutkimusmenetelmistä esimerkiksi havainnointia, eikä pelkää tehdä niiden perusteella yleispäteviä päätelmiä tästä hetkestä tai tulevasta. Empiristin mielestä tällaisilla päätelmillä on kuitenkin enemmän kättä pidempää perustaa, kuin esimerkiksi täysin tuulestatemmatuilla, haaveellisilla Excel graafeilla, jotka eivät perustu mihinkään havaintoihin vaan lähinnä projektinjohtajan toiveisiin ja pelkoihin.

Sähköposteihin, Slack-viesteihin, tai palaverikutsuihin ilmestynyt etuliite, joka on yleistynyt nopeammin kuin sängyn takana torjumatta pesivät luteet. Suorana käännöksenä tarkoittaa: For Your Information, eli tiedoksesi tai hyvä tietää tämäkin. Todellisessa arjessa tarkoittaa yleensä huonosti vastaanottajalle jäsenneltyä tai valmisteltua informaatiota, jonka alkuperäinen vastaanottaja heittää eteenpäin jokaiselle tutulle ja tutun tutulle ajatuksena siivota se omalta työpöydältä ja varmistaa, että on ainakin jossain määrin viestinyt eteenpäin. FYI-viestin vastaanottaja yleensä silmäilee hetken sisältöä hiuksiaan haroen ja yrittää tunnistaa siitä itsensä, harhautuu miettimään seuraavaa lomamatkaa ja lähettää sen eteenpäin seuraaville uhreille.

Mitä on Kanban? Se on toinen maailman käytetyimmistä ketteristä menetelmistä, Scrumin lisäksi. Kanban sopii monenlaiseen tekemiseen ja erilaisille tiimeille. Yleensä tiimi valitsee Kanbanin, jos Scrumissa turhauttaa kahden viikon syklien työmäärän ennustamiseen menevä aika. Tiimit voivat myös kokea turhauttavana sen, että Scrumin sprintti-suunnitelmiin ei aina päästä, ja Kanban, jossa asioita valmistuu yksi kerrallaan, voi olla henkisesti tyydyttävämpi vaihtoehto. Kanban-kuitenkin sopii ehkä jo kehittyneemmille ketterille tiimeille, jossa tarkkaa syklitystä ei tarvita. Ketterän pyöräilyn opettelu on usein hyvä aloittaa Scrumista, jossa tarkat tapahtumat ja sprintti-syklit tarjoavat opettelijalle eräänlaiset apupyörät.

Kanbanissa toisin kuin Scrumissa ei ole määritelty tarkkoja tapahtumia, syklejä, rooleja ja tekemisiä. Sen sijaan, keskiössä on kolme periaatetta:

1.) Visualisoi kaikki työ eli tee siitä läpinäkyvää

2.) Rajoita keskeneräisen työn määrää. Tämä tehdään tiimin yhdessä sopimilla WIP eli Work in Progress- rajoilla. Yleinen käytäntö on sopia, että käynnissä voi olla kerrallaan yksi työ per henkilö. Jotkut tiimit myös sopivat rajasta, joka on pienempi suhteessa tiimiläisten määrään, edistääkseen tiimityötä.

3.) Hallitse arvovirtaa (ihmisten sijaan), eli yritetään tehdä asioiden läpimenoajoista mahdollisimman lyhyitä

Kanban-taulu on ketterien tiimien yleinen työkalu, jolla hallitetaan tekemisen virtaa. Yksinkertaisimmillaan siinä on kolme kolumnia:

• To Do, eli mitä meidän pitäisi tehdä (backlog tai tuotekehitysjono, jossa tulevat asiat ovat prioriteettijärjestyksessä)
• In Progress, eli mitä on tekeillä
• Done, eli mitä on valmiina. Katso myös valmiin määritelmä.

Kanban-taululla olevat asiat ovat käyttäjätarinoita.

Katso tältä videoltamme 5 minuutin tiivis kuvaus Kanbanista.

Ketterät menetelmät ovat joukko tarkempia oppeja siitä, miten ketteriä arvoja voidaan tuoda toimivasti tiimien ja organisaation arkeen. Yhteistä niille on usein esimerkiksi se, että riskejä hallitaan nimenomaan lyhyillä iteraatioilla ja asioiden todentamisella empiriisesti arvailun sijaan. Tiimi on usein ketterien menetelmien keskeinen yksikkö, hiki hatussa suoritettavan yksilöpuurtamisen sijaan. Agile onkin enemmän joukkuelaji. Monessa menetelmässä on kuitenkin tiettyjä, joskus myös yhteisiä tiimiroolejakin. Katso esimerkiksi Scrumin roolit.

Käyttäjätarina eli user story on sellainen tapa kuvata ja pilkkoa tiimin luomaa konkreettista arvoa, jonka mummosikin ymmärtää. Käyttäjätarina kiteyttää asiakkaan tarpeen – mikä on ominaisuus, kuka ominaisuutta tarvitsee, mihin ja miksi. Esimerkiksi:

Sivuston satunnaisena käyttäjänä haluan kirjautua helposti kertakäyttökoodilla, jottei minun tarvitse muistaa miljoonia käyttäjätunnuksia ja salasanoja.

Tässä tapauksessa:

Kuka: sivuston satunnainen käyttäjä
Mitä: kirjautuminen kertakäyttökoodilla
Miksi (arvo): helppous

Teknisten asioiden kirjoittaminen käyttäjätarina-muotoon edistää myös tiimityötä. Se rohkaisee ja muistuttaa koko tiimiä palaamaan kerta toisensa jälkeen siihen, miksi jotain asiaa tehdään. Sellaisia asioita on myös helpompi priorisoida keskenään, joiden arvo on rautalangasta väännetty ja kaikkien nähtävillä. Kolmanneksi se rohkaisee keskustelua ja asioiden rakentavaa haastamista- onko tämä sittenkään näin tai arvokasta? Asioista, joita emme ymmärrä, onko hankala tai mahdoton keskustella. Jos emme ymmärrä, pysymme useimmiten vaiti ja turhaudumme.

Käyttäjätarinoihin liittyykin niin sanottu 3C periaate eli card, conversation ja confirmation. Eli ei riitä, että käyttäjätarina on kirjoitettu Jiraan, vaan keskutelulla on varmistettava, että kaikki ymmärtävät tarinan samalla tavalla. Keskustelun perusteella voidaan myös kirjata hyväksymiskriteerit, jotka vahvistavat mitä lopputuloksena pitää syntyä.

Lean on liiketoiminnan oheistoimintoihin ja byrokraattiseen säätöön kohdistuva perusteellinen laihdutuskuuri. Lean meinaa ameriikan kielellä hoikkaa ja solakkaa, ja juuri sitä lean-ajattelussakin tavoitellaan. Lean pyrkii eliminoimaan hukkaa eli sitä turhaa tauhkaa, joka vie aikaa ja energiaa olennaiselta.

Liinisti toimiessa pyritään siis karsimaan kaikkea ylimääräistä, ja keskittymään olennaiseen. Jokainen “liinisti” toimiva ammattilainen miettiikin aina kerran ja kaksi, onko tässä minun ja meidän touhussa nyt oikeasti jotain järkeä? Millä rutiineilla ja tekemisillä tuotamme eniten arvoa? Millä säädöllä taas mahdollisesti jopa vähennämme tuottamaamme arvoa?

Tekemällä paljon epäolennaista meillä jää vähemmän aikaa ja energiaa olennaiseen. Tämä saattaa näkyä ihan sinne asiakkaalle asti, jos esimerkiksi tuotteessamme ja palvelussamme on niin paljon kermaa päällä, että itse kakku hukkuu sen alle lahjakkaasti. Toisaalta, sisäisessä työssä hukka voi tarkoittaa esimerkiksi loputtomia palavereita ilman selkeää agendaa, tai rutiininomaisesti tuotettavia raportteja ja PowerPoint-esityksiä joita kukaan ei koskaan lue.

Lean-ammattilainen miettii esimerkiksi virtaustehokkuutta ja pyrkii ohjaamaan organisaation iloisena syöksyilevää virtaa oikeaan suuntaan, kohti asiakkaan imua. Nämä termit onneksi kuvaavat jo mielikuvien tasolla aika hyvin sitä, mistä tässä on kyse. Virtaustehokkuutta voi vahvistaa poistamalla virran tieltä kiviä ja hukkaa, jotta virta juoksisi siihen oikeaan, olennaisimpaan suuntaan mahdollisimman tehokkaasti. Virran piennarta voi vahvistaa määrittelemällä tarkasti, mitä se olennainen on.

Liinistin varrella virran harjoittama imuohjaus taas perustuu siihen, mihin tämä virta pitäisi loppujen lopuksi juosta. Ainoa joka osaa vastata tähän kysymykseen oikein, on liinistin loppuasiakas. Vaikka kaikki tiet vievät Roomaan, kaikki asiakkaat eivät. Liinisti siis pyrkii imuohjaamaan organisaation virran asiakkaan mereen vain jos kysyntää on. Eli suomeksi sanottuna: valmistamaan tuotteita ja palveluita vain tilauksesta, ei pöytälaatikkoon huvikseen pölyyntymään.

Liinistin arkkivihollinen on se väärään suuntaan ohjaava pato, joka nousee terhakkaan liinistin asiakasvirran tielle ajatuksella että “kun ne asiat on aina tehty näin”. Liinistin mielestä tällainen ajattelu on byrokraattista hukkaa. Liinisti ei välitä missä asiakkaan meri oli ennen talvisotaa, vaan minne virrat tulisi ohjata nyt.

Katso Agile Manifesto.

Se kuuluisa agile-menetelmien timantti MVP, eli Minimum Viable Product. Sananmukaisessa käännöksessä puhutaan tuotteesta, mutta todellisuudessa kyseessä voi olla mikä tahansa palvelu, konsepti, prosessi tai osa sitä, mitä haluamme nopeasti testata oikeilla asiakkailla saadaksemme sitä tärkeintä eli oikeaa, empiiristä palautetta tuotekehitykseen. Siksi jotkut puhuvatkin MVE:stä eli Minimum Viable Experiencestä.

MVP on siis eli tiukin mahdollinen scope, jolla tuotamme eniten arvoa nopeasti. Arvo tässä tapauksessa ymmärretään usein väärin. Se ei ole laajamittaista, kaupallista, euromääräistä arvoa- vielä. Arvo on enemmänkin sitä palautetta mitä saamme, liikkuaksemme edellä mainittua kohti.

Hyvä keino tehdä MVP:stä hyödyllinen vähällä vaivalla onkin noudattaa vanhaa sanontaa: Fake It Till You Make It. Eli keksi joku keino joka ei vielä vaadi koodaamista tai laajamittaisia organisaatiomuutoksia testataksesi itse ideaa ennen toteutusta. Rakenna siis paperilennokki ennen oikeaa lentokonetta.

MVP:n määrittely johtaa usein samankaltaisiin riitoihin organisaatioissa kuin Perhe Alias jouluaattona. Välttääksesi ne, lue lisää vinkkejä MVP:n rajaamiseen blogistamme täältä.

Ketterän julistuksen takana vaikuttavat 12 käskyä eli periaatetta. Periaatteiden on tarkoitus ohjata tiimien toimintaa tuottavampaan ja miellyttävämpään suuntaan.

1. Tärkein tavoitteemme on tyydyttää asiakas toimittamalla tämän tarpeet täyttäviä versioita ohjelmistosta aikaisessa vaiheessa ja säännöllisesti.
2. Otamme vastaan muuttuvat vaatimukset myös kehityksen myöhäisessä vaiheessa. Ketterät menetelmät hyödyntävät muutosta asiakkaan kilpailukyvyn edistämiseksi.
3. Toimitamme versioita toimivasta ohjelmistosta säännöllisesti, parin viikon tai kuukauden välein, ja suosimme lyhyempää aikaväliä.
4. Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä päivittäin koko projektin ajan.
5. Rakennamme projektit motivoituneiden yksilöiden ympärille. Annamme heille puitteet ja tuen, jonka he tarvitsevat ja luotamme siihen, että he saavat työn tehtyä.
6. Tehokkain ja toimivin tapa tiedon välittämiseksi kehitystiimille ja tiimin jäsenten kesken on kasvokkain käytävä keskustelu.
7. Toimiva ohjelmisto on edistymisen ensisijainen mittari.
8. Ketterät menetelmät kannustavat kestävään toimintatapaan. Hankkeen omistajien, kehittäjien ja ohjelmiston käyttäjien tulisi pystyä ylläpitämään työtahtinsa hamaan tulevaisuuteen.
9. Teknisen laadun ja ohjelmiston hyvän rakenteen jatkuva huomiointi edesauttaa ketteryyttä.
10. Yksinkertaisuus – tekemättä jätettävän työn maksimointi – on oleellista.
11. Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä.
12. Tiimi tarkastelee säännöllisesti, kuinka parantaa tehokkuuttaan, ja mukauttaa toimintaansa sen mukaisesti.

Retrospektiivi on itsearvioinnin ja jatkuvan parantamisen työkalu, jota käytetään laajalti ohjelmistokehityksessä sekä monissa muissa konteksteissa. Se on prosessi, jossa tiimi arvioi menneen työjakson tai projektin, tunnistaa mitä meni hyvin ja missä on parantamisen varaa. Tavoitteena on oppia menneistä kokemuksista ja kehittää tehokkaampia työskentelytapoja. Retrospektiiviin kuuluu avoin ja rakentava keskustelu, jossa painopiste on positiivisissa muutoksissa, ei syyttelyssä tai negatiivisessa arvostelussa.

SAFe on yksi ketterä menetelmä, joka on tarkoitettu valtaville organisaatioille ja operaatioille, joissa on monia tiimejä ja niiden välisiä riippuvaisuuksia.

SAFessa tiimeillä on yhteinen sykli, ja samanmittaiset tekemisen iteraatiosyklit eli sprintit, sanotaan nyt niitä vaikka pelimoduleiksi. Noin 4-6 tällaista pelimodulia muodostaa yhden pelitason, jossa moduleiden välillä on suunnitelmia ja riippuvuuksia.

Katso SAFen perusteet kattavammin tästä blogista.

Tervetuloa maailman käytetyimmän ketterän menetelmän pariin! Menetelmän nimi menetelmän nimi (engl. scrum) viittaa rugbyn erikoistilanneryhmitykseen. Se on jäänyt käyttöön ehkä johtuen johtuen menetelmän yhtäläisyyksistä rugby-joukkueeseen ja sen toimintaan; molemmat ovat erilaisiin tilanteisiin sopeutuvaisia, nopeita ja itseohjautuvia.

Scrumia on alunperin käytetty lähinnä tuotekehitys- ja ohjelmistokehitystiimeissä, mutta viime aikoina on alettu tajuta sen arvo mihin tahansa tekemiseen aina liiketoiminnan johtamisesta vaikka markkinointiin saakka. Koska taikatemppu tehokkuuteen on usein osa-alueesta riippumatta sama: läpinäkyvyyden ja jatkuvan oppimisen keinoin lisätään niin tehokkuutta kuin merkityksellisyyden tunnettakin.

Scrum on osa-alueesta riippumatta joukkuepeli, ei yksilöpuurtamista. Scrum-tiimi on kykeneväinen itseohjautuvuuteen eli päätöksen tekoon siitä syystä, että tiimistä löytyy kaikki tekemiseen tarvittavat substanssi-osaamiset yhdistettynä vahvaan tunteeseen siitä, että me tiiminä hemmetti soikoon osaamme tämän asian ja jos emme osaa, niin yhdessä reflektoiden opettelemme. Tästä syystä Scrum-tiiminä onnistuminen kytkeytyy usein ihan yrityksen ylimpään johtoon ja organisaatiokulttuuriin asti. Jotta Scrum-tiimistä saadaan parhaat tehot ja laatu irti, on oltava vahva luottamuksen ja kannustuksen ilmapiiri, jotta tiimi uskaltaa kokeilla ja onnistua.

Tiimi suunnittelee ja tekee kaiken sprinteissä, eli maksimissaan 30 päivän ja yleensä viikon tai kahden iteraatiosykleissä. Sprintillä on selkeä tavoite ja päämäärä, ja sen lopputuloksia kutsutaan inkrementeiksi, askeliksi kohti asiakkaalle ja liiketoiminnalle merkityksellistä lopputuotetta tai palvelua.  Jokaisen inkrementin pitää täyttää valmiin määritelmä eli DoD.

Inkrementtien suunnittelusta tekee helpompaa tiimin vähitellen rakentuva tuotteen kehitysjono eli backlog, eli lista hyvin mietittyjä arvauksia siitä, mikä voisi olla seuraavaksi arvokkainta tekemistä alkavalla iteraatiojaksolla. Tuotteen kehitysjono on vähitellen syntyvä, järjestetty lista siitä, mikä on tarpeen tuotteen
parantamiseksi. Se on ainoa lähde Scrum-tiimissä tehtävälle työlle, josta kehittäjät valitsevat aina tekemisen seuraavalle sprintille.

Tuotteen backlog on tärkeysjärjestyksessä tiimin tuoteomistajan (Product Owner, PO) ja koko tiimin toimesta. Huom: tärkeysjärjestyksessä. Tärkeysjärjestys tarkoittaa sitä, että KAIKKI asiat ovat oikeasti tärkeysjärjestyksessä, peräkkäin. Ei sitä, että kaikki asiat ovat kuitenkin loppupeleissä yhtä tärkeitä. Tärkeysjärjestyksen määrittelyssä tiimiä ja tuoteomistajaa auttaa arvon ja ajan suhde. Se, että joku asia on itsessään arvokasta, ei yksin riitä. Tiimi vertaa sitä vielä siihen aikaan, joka heiltä menee tuoda tämä asia päivänvaloon aina asiakkaalle asti. Tiimin pöytälaatikossa pyörivä keskeneräinen suunnittelukappale ei luo arvoa kenellekään, se on ainoastaan kuluerä. Siksi tiimi vertaa näitä kahta asiaa keskenään tehdessään päätökset.

Iteraatiosykleistä merkittäviä tekevät niihin sisäänkirjoitetut Scrumin tapahtumat.

Scrum-tarinan super sankareita taas ovat Scrum-tiimin jäsenet.

Tästä voit kerrata äsken mainitut Scrumin tuotokset.

• Sprintti (sprint)
  
  Scrumin sydämen syke. Se sateenkaari, joka sulkee sisäänsä muut tapahtumat. Aina saman mittainen iteraatio- ja suunnittelusykli, jonka sisällä samat tapahtumat toistuvat samoina aikoina ja samassa järjestyksessä. Tavoitteena on johdonmukainen, jatkuva oppiminen sekä ennustettavuus. Sprintillä on tuoteomistajan (PO) ehdottama ja koko tiimin yhdessä hyväksymä tavoite, joka kokoaa pienemmät tehtävät yhteen ja antaa niille merkityksen ja suunnan. Sprintin yleisin pituus on 2 viikkoa, mutta se voi kestää maksimissaan 30 päivää ja esimerkiksi vain viikon. Sprintin aikana tiimi ja Product Owner viestivät aktiivisesti tekemisistä ja auttavat toisiaan. Koko tiimi on vastuussa Sprintin onnistumisesta, ei kukaan yksin.
  
  
• Sprintin suunnittelu (Sprint Planning)
  
  Sprintti-sateenkaaren alku! Joka toinen viikko tässä tapahtumassa aloitetaan uusi 2- viikon Sprint. Product Owner valmistautuu ehdottamaan Sprintin yleistä tavoitetta eli jotakin teemaa/otsikkoa, joka sitoo pienempiä tekemisiä yhteen. Kehittäjät taas vastaavat itse Sprint-suunnitelman tekemisestä eli valitsevat tuotteen backlogilta tavoitteeseen liittyviä, valmiiksi muotoiltuja tekemisiä ja arvioivat niiden kokoluokan. Samalla koko tiimi käy keskustelun siitä, että ne ymmärretään samalla tavalla. Kehittäjät päättävät, kuinka monta asiaa, esim. käyttäjätarinaa, he ehtivät tehdä sprintin aikana. Tarvittaessa muokataan vielä sprintin tavoitteita. Kun asiasta päästään yhteisymmärrykseen, Sprintti voi alkaa.
  
  Sprintin suunnittelussa tulisi vastata seuraavaan 3 kysymykseen:
  
  1.) Miksi tämä sprintti on arvokas? (tavoite)
  2.) Mitä tässä sprintissä voidaan saada valmiiksi?
  3.) Miten valittu työ saadaan valmiiksi?
  
• Päivittäispalaveri (Daily)
  
  15-minuutin päivittäinen tiimitsekki, joka on aina samaan aikaan, samassa paikassa. Tarkoitus on syventää tiimityötä ja ratkoa yhdessä haasteita- ei raportoida toisillemme raportoimisen iloksi. Pulssipalaveri, jossa käydään läpi päivän polttavat liittyen sprintti-tavoitteeseen, ja miten voimme auttaa toisiamme niissä.
  
• Sprintin katselmointi (Sprint Review)
  
  Sateenkaaren loppupäässä odottava konkreettinen katselmus siihen, mitä saatiin loppuvalla Sprintillä aikaiseksi. Scrum-tiimi ruotii ja demoaa lopputuloksia suunnitelmia vasten. Tärkeimpien sidosryhmien tulisi olla mukana. Menneiden havaintojen perusteella voidaan muokata tulevaa kehitysjonoa heijastelemaan keskustelussa syntyneitä havaintoja.
  
• Retrospektiivi
  
  Sateenkaaren päässä odottaa itsetutkiskelu. Tämä on se hetki, kun tutkiskelemme laadullisesti itseämme ja tiimiämme. Mikä meni hyvin? Säilytetään sellaiset toimintamallit? Mikä olisi voinut mennä vielä paremmin? Ratkotaan se yhdessä! Parhaat ratkaisuehdotukset voidaan lisätä tulevaan kehitysjonoon. Jotkut pitävät retrospektiiviä jopa Scrumin tärkeimpänä asiana, koska siinä korostuu koko ajatuksen ydin eli jatkuva oppiminen, joka nopeuttaa tekemistä ja tekee jokaisesta työpäivästä paremman. Älkää siis skipatko tätä tapahtumaa, vaan panostakaa siihen.
  
  Keskustelkaa asioista Aikuisten Oikeesti. Tarkoitus on mennä asioiden ja ilmiöiden taakse. Siinä missä Sprintin katselmoinnissa keskitytään substanssiin ja lopputulokseen, Retrospektiivissä eli tuttavallisemmin Retrossa kurkkaamme yhdessä esiripun taakse. Emme kysy ainoastaan mitä tapahtui, vaan miksi? Näin voimme oppia jatkuvasti uutta ja voida paremmin.
  
  Yrittäkää myös aidosti kuunnella toisianne. Älä keskity siis väittämään kaverin palautetta vastaan vaikka se tekisi vähän kipeääkin. Tarkoitus on hyvä, ja teidän yhteinen.

Nämä jutut ovat sitä konkreettista arvoa jota Scrum-tiimi tuottaa:

Tuotteen kehitysjono eli backlog

Lista arvauksia siitä, mikä on seuraavaksi kaikkein tärkeintä tekemistä isomman tavoitteemme kannalta. Tuotteen kehitysjono syntyy vähitellen tiimityössä ja keskustelussa. Sprintin valmistelussa kehitystiimi valitsee sieltä parhaiten Sprintin tavoitetta tukevat asiat työstöön. Tuoteomistajalla on lopullinen sana asioiden tärkeysjärjestyksestä tuotekehitysjonossa, mutta tyypillisesti koko tiimi työstää ja priorisoi kehitysjonoa yhteistyössä.

Sprintin kehitysjono

Kehittäjien yhdelle sprintille valitsemat tekemiset, jotka tukevat sprintin tavoitteen toteutumista. Sprintin kehitysjonon asiat valitaan sieltä äsken mainitulta tuotteen backlogilta.

Inkrementti

Inkrementti on yksi konkreettinen askel kohti isompaa tuotteen tai palvelun tavoitetta. Ollakseen jollain tavalla arvokas, sen pitää olla käyttökelpoinen ja luoda arvoa jollekin. Yhdessä sprintissä voidaan luoda yksi tai useampia arvokkaita inkrementtejä. Näitä sitten ihastellaan yhdessä Sprintin katselmuksessa, tai jopa sitä ennen, jos tiimi pystyy esittelemään tuotoksensa asiakkaille asti jo aiemmin. Inkrementin tulee täyttää valmiin määritelmä.

Toimintamalli, jossa on yhdistelty Scrumin ja Kanbanin elementtejä tiimille sopivalla tavalla.

TADAA, Scrum-tarinan supersankarit ovat tässä! Ja hei, VAIN tässä. Scrumissa ei ole tarkoitus keksiä lisää rooleja ja vastuita näiden ympärille tai sisälle. Nämä riittää. Toki tärkeitä sidosryhmiä ja rooleja siellä voi olla muitakin, mutta itse tarinan sankarit ovat vain ja ainoastaan tässä:

Scrum-tiimi

Scrumin keskiössä on tiimi. Scrumissa on kyse meistä, ei minusta ja sinusta. Scrum-tiimiin kuuluu vain ja ainoastaan: yksi tuoteomistaja, yksi Scrum Master, ja kehittäjät. Varsinaisessa työstössä tuoteomistaja ja Scrum Master voidaan lukea myös kehittäjiksi, jos he tekevät varsinaista työtä tiimin tavoitteen eteen Sprinttien aikana. “Kehittäjät” termi voi olla hieman hämäävä, ja perustunee siihen, että Scrum on alunperin lähtöisin ohjelmistokehityksestä, vaikka sitä nykyään sovelletaan menestyksekkäästi mitä erilaisimmissa tiimeissä aina markkinoinnista yritysjohtoon. Kehittäjä voi kuitenkin olla kuka tahansa tiimille arvokas jäsen erikoisosaamisella: esimerkiksi palvelumuotoilija tai talousnero.

Scrum-tiimin tulisi olla riittävän pieni, jotta se voi pysyä nopeana ja itseohjautuvana. Tyypillinen nyrkkisääntö on enintään 10 jäsentä. Tätä isommassa porukassa syntyy helposti tietokatkoja ja alaryhmiä. Jos sinusta siis tuntuu, että olisi tarve perustaa tätä isompi tiimi, harkitse kahta Scrum-tiimiä ja tavoitteiden jakamista. Toisaalta jos tavoitetta ei voi jakaa, voit myös perustaa erillisiä Scrum-tiimejä, joilla on sama tuotemistaja.

Scrum-tiimi ottaa vastuun kaikesta ydinvastuuseen liittyvästä tekemisestä ja suunnittelusta. He ovat oman itsensä herroja: itseohjautuvia, autonomisia, ja osaavat onnistumiseen tarvittavat asiat.

Kehittäjät

Scrum-tiimin kehittäjät ovat ne ihmiset, jotka tuottavat Sprinttien aikana arvoa ja käyttökelpoisia lopputuloksia eli inkrementtejä. Kehittäjillä tulisi olla kaikki tarvittavat osaamiset, joita tavoitteisiin vaaditaan. Mitä ne ovat, vaihtelee tavoitteen mukaan. Joka tapauksessa kehittäjien vastuulla on:

-Sprintin suunnitelma eli kehitysjono
-Laatu ja siihen liittyvä “valmiin määritelmä”. Milloin joku asia on tiimin mielestä siinä mielessä hyvin tehty, että sitä voi kutsua valmiiksi?
-Suunnitelman mukauttaminen uusien oppien mukaisesti
-Toistensa kohteleminen hyvin.

Tuoteomistaja (Product Owner)

Mikä ihmeen PO? Tuoteomistaja eli usein tuttavallisemmin “PO” on vastuussa siitä, että se mitä tiimi tekee, tuottaa arvoa loppuasiakkaalle. Tyyppinä PO on usein luova, rohkea, ja hänen yksi tärkeimmistä ominaisuuksistaan on kyky sanoa “ei!”, jotta olennainen ei huku aina kasvavan tuotteen kehitysjonon eli backlogin uumeniin.

Tuoteomistaja vastaa tuotteen kehitysjonosta eli backlogista. Tämä ei tarkoita että hän tekisi ja järjestäisi sen yksin, mutta hänellä on lopullinen sana esimerkiksi asioiden prioriteettijärjestyksen suhteen. Tuoteomistaja vastaa myös siitä, että koko Scrum-tiimin touhulla on hyvä, selkeä, järkevästi viestitty tavoite ja suunta.

Scrum Master

Scrum Masterin vastuulla on tukea tiimiä jatkuvassa kehittymisessä ja Scrum-toimintamallin käyttöönotossa ja noudattamisessa. Scrum Master on yleensä reilu tyyppi, ja tiimin palveleva johtaja, joka luotsaa koko porukkaa oikeaan suuntaan omalla esimerkillä ja nätisti ja oivalluttavasti johdatellen. Hän myös auttaa tiimiä poistamaan esteitä onnistumisen tieltä.

Kurkkaa backlog!

Kurkkaapa tämä kohta: käyttäjätarina.

Tämä on se agilistin tai liinistin kirosana, joka tiivistää kaiken pahan tässä maailmassa. Vesiputousmallissa eli perinteisessä projektimallissa eletään maailmassa, jossa kuvitellaan, että voimme tietää, suunnitella ja vieläpä kuvata kaiken kauniiksi kaavioiksi etukäteen, valtavan hankkeen tai ohjelmistokehitysprojektin alkaessa.

Vesiputous-kaverin yksi tärkeä työkalu on mm. Gantt- kaavio. Ganttin kaavio on aiemmin projektinhallinnassa suosittu janakaavio, joka esittää projektin ja sen työvaiheiden edistymisen suhteessa aikaan. Kaavion kehitti amerikkalainen insinööri ja keksijä Henry Gantt jo 1800-luvulla, ja se on nimetty hänen mukaansa.

Ketterän kehittäjän mielestä vesiputous-mallissa on se ongelma, ettei todellisuus koskaan oikeasti vastaa näitä ihanteellisia kaavioita ja unelmia. Vesiputouksen pinnan alla kytee kiviä, jotka eivät virtausta suunnitellessa näkyneetkään maastokartassa. Myös sää voi muuttua ja nostaa veden pintaa, tai mitä tahansa muuta yllättävää tapahtua. Siksi ketterä kehittäjä tarjoaa iteratiivista, jatkuvasti itseään korjaavaa agile-mallia tilalle tarkempana ja todellisempana vaihtoehtona.