Mitkä ovat ketteryyden hyödyt?

Miksi meidän pitäisi toimia ketterästi? Onhan paljon tuskattomampaa ja varmempaa suunnitella projekti kunnolla, ja sitten toteuttaa suunnitelmaa tinkimättömästi? No, asiat ovat vaan muuttuneet, ja ketteryyden hyödyt nousseet entistä suuremmiksi. Nykyään maailma muuttuu nopeammin kuin ennen. Teknologinen ympäristö ja asiakkaan tarpeet eivät ole niin muuttumattomia kuin aikaisemmin. Brexitillä hekumoivat haikailevat takaisin aikaan, jolloin saarivaltio voi olla eristyksissä ja hallita maailmaa. Herätys tulee olemaan kivulias, kun huomataankin että maailma on muuttunut.

Nopeat muutokset pakottavat ketteryyteen

Nopeat asiakkaiden tarpeiden ja ympäristön muutokset lisäävät väärän tavoiteasetannan todennäköisyyttä. Ne myös vaikeuttavat perinpohjaisen suunnitelman tekemistä huomattavasti. Hankkeissa, joissa on paljon epävarmuuksia (kuten hankkeissa, jotka sisältävät ohjelmistokehitystä, tai yleensäkin epävarmoja asiakastarpeita), ketteryyden hyödyt nousevat esiin ja ketterät toimintamallit hakkaavat ei-ketterät kuten Roger Federer hakkaisi puisella mailalla pelaavan Björn Borgin.

Ketterillä toimintatavoilla on todennäköisempää, että saadaan sellainen lopputulos kuin asiakas haluaa.

Jos sinä et ole ketterä, sinun kilpailijasi varmasti on

Ketterillä toimintatavoilla toimien ensinnäkin on paljon todennäköisempää, että saadaan sellainen lopputulos kuin asiakas haluaa. Nykymaailmassa asiakkaiden tarpeet muuttuvat niin nopeasti, että 3 vuoden vesiputousmallinen, ei-ketterästi tehty projekti ei vaan voi osua maaliin niin hyvin kuin ketterin toimintatavoin tehty projekti, johon käytetään sama aika ja raha. Ketterällä projektipoppoolla on niin monta mahdollisuutta uudelleen määritellä mitä tehdään, että se onnistuu paljon suuremmalla todennäköisyydellä. Kukapa haluaa tehdä tehokkaasti jotain, mitä kukaan ei enää tarvitse?

Kokonaiskustannus tiedetään tarkasti – vaikka ei tiedettäisikään tarkasti sitä, mitä tullaan tekemään

Toinen ketteryyden hyödyistä on se, että tiedetään paljon tarkemmin koko hankkeen kokonaiskustannus. Tämä johtuu siitä, että yksi ketteryyden ensimmäisistä periaatteista on se, että ketterässä toimintatavassa lyödään lukkoon aikataulu ja resurssit, ja taasen tehtävät asiat eli scope ei ole fiksattu kiinni. Tavoitteena on tietenkin se, että tiedetään tarkkaan, milloin tuote valmistuu, mitä se maksaa. Lisäksi, ketterästi toimiva tiimi tekee tuotteeseen tärkeimmät toiminnot ensin, ja vähemmän tärkeät myöhemmin.

Jos taas verrataan ei-ketterään toimintamalliin, siellä lähdetään liikkeelle siitä, että release scope on lukittu, ja resurssit ja aikataulu voi muuttua (vaikka useimmiten nekin on ainakin johtajien puheiden mukaan lukittu). Tämä yleensä johtaakin kustannusten kasvamiseen, aikataulun venymiseen.

Jäädytetty release scope ja ketteryys ei sovi yhteen

Törmäämme joskus kuitenkin tilanteisiin, jossa yritys haluaa noudattaa ketteriä toimintatapoja (olla niin kutsutusti ”Agile”), mutta kehitettävän tuotteen ominaisuussetistä ei kuitenkaan haluta tinkiä, ei sitten yhtään. Eli, vaikka ollaan ”ketteriä” niin scope on fiksattu. Kysymys onkin, kuinka ketterä voi olla jäädytetyllä scopella? Vastaus on, että jäädytetty scope tappaa lähes kaiken ketteryyden. Jos tätä ei ole projektitiimissä ja johtoportaassa ymmärretty, on suoraan sanoen parempi jatkaa vesiputousmallissa.  Ainakin näin vältetään valheellinen ”olemme ketteriä” -mielentila.

Toiveiden lista on AINA pidempi kuin se, mikä on mahdollista

Miksi jäädytetty release scope sitten on niin tappava ketteryydelle? Ensimmäinen syy tähän on, että kehitystiimille annettava scope on AINA pidempi kuin se, mitä on mahdollista tehdä. Tämä on tuotekehityksen perustotuus – koska on paljon helpompi toivoa jotain, toivelista on aina pitkä. Lisäksi asiat ovat AINA monimutkaisempia kuin ennalta arvataan.

Toivottu release scope on aina suurempi kuin se, mikä pystytään toteuttamaan.

Liian suuri release scope johtaa featureiden implementointikiireeseen

Nämä asiat johtavat siihen, että toivottu release scope on aina suurempi kuin se, mikä pystytään suunnitellussa ajassa toteuttamaan. Kokeneet tuotekehittäjät tietävät tämän, ja jos heidät pakotetaan toimimaan ”jäädytetty scope” -tilanteessa, heille tulee alitajuinen kiireen tuntu implementoida kaikki featuret, jotka vaan ehditään. Mihin tämä kiire sitten johtaa? Se johtaa väistämättä siihen, että joko suunnitellusti tai alitajuisesti, tiimit priorisoivat uuden kehittämistä tuotantolaadun rakentamisen kustannuksella.

Miksi testata ja etsiä bugeja, kun niitä ei sitten saa heti korjata?

Jos on kiire implementoida featuret, ja tiedossa on, että scope on hankala saada tavoiteaikataulussa tehtyä, käy hyvin helposti niin, että tuotekehitystiimit alkavat alitajuisesti välttää bugien etsimistä tai löytämistä. Vaikka toimitaankin nimellisesti DoDin mukaan (Definition of Done) niin tuotantolaatuun tähtäävä testaus loisi konfliktin. Insinöörit ovat usein (eivät aina) enemmänkin konfliktia vältteleviä ihmistyyppejä, joten tällaisessa tilanteessa he saattavat karttaa alitajuisesti testausta, joka paljastaisi vikoja. Miksi löytää vikoja, jos niiden prioriteetti ei kuitenkaan mene uuden kehittämisen edelle? Se toisi vain lisästressiä tuotekehitystiimille, joka tuntee jo suurta painetta toimittaa fiksatun scopen tuotos aikataulussa.

Alitajuinen bugien etsinnän välttely johtaa bugiryöpsähdykseen releasetestauksessa

Tällainen bugien pelko johtaa väistämättä siihen, että release testauksessa bugeja sitten löytyy, ja paljon. Aikataulun pitäminen vaatii sitten maagisen paljon ylitöitä, tai jostain kaivettavia lisäresursseja.

Oikein tehty priorisointi pitää huolen siitä, että pakolliset featuret kehitetään ensin.

Jäädytetty release scope johtaa väärään priorisointiin

Toinen syy sille, miksi jäädytetty scope tappaa ketteryyden hyödyt on se, että on erittäin todennäköistä, että tuotekehityksen backlog priorisoidaan väärin. Oikein tehty priorisointi pitäisi huolen siitä, että pakolliset featuret kehitetään ennen valinnaisia, teknisesti tai käyttäjän tarpeiden suhteen riskaabelit featuret tehdään ennen niitä, joissa on vähemmän riskiä. Oikein priorisoidussa hankkeessa siis lähestyttäessä tavoiteaikataulua, tekemättä on vain vähemmän tärkeitä asioita. Lisäksi riskaabelit asiat on tehty aikaisin, ja jos muutoksia tai lisätöitä tarvitaan, niihin on aikaa.

Jäädytetty scope on kuin kommunistien suunnitelmatalous – menkää Pohjois-Koreaan katsomaan kannattiko se

Jos scope on fiksattu, se tarkoittaa, että kaikki on ”must have”. Se tarkoittaa, että tiimi ei voi priorisoida pakollisia ennen valinnaisia featureja. Koska ”kaikki pitää tehdä”, on myös todennäköisempää, että tiimit eivät käytä tarpeeksi aikaa teknisten riskien kartoittamiseen. Tämä saattaa johtaa yllätyksiin ihan loppusuoralla. Viimeinen virhe on se, että ”koska kaikki pitää tehdä”, se kannustaa tiimiä luottamaan olettamuksiin liikaa. Mikä takaa sen, että asiakkaan tarpeet oikeasti ymmärrettiin oikein? No, koska ”kaikki pitää tehdä” kai ne sitten tiedettiin oikein.

Miten välttää ongelmat?

Annan kolme vihjettä

1. Kannattaa kouluttaa projektin scopesta päättävät tahot. Tuotepäälliköt, tuoteomistajat, projektin ohjausryhmässä olevat henkilöt. Ketteryyden perusteet on nopea käydä läpi, mutta kokemuksellinen koulutus vaatii taitavan valmentajan, joka vie ajatukset aivoihin asti. Käytännön esimerkit ja työpajamainen koulutuslähestymistapa ovat toimivia metodeja oppimiseen. Jos koulutuksen jälkeenkin scope on freezattu, voidaan sitten yhdessä heittää kirves kaivoon.
2. Vahvista Scrum Mastereja – vahva Scrum Master uskaltaa nostaa kissan pöydälle, vaikka toimitusjohtajalle asti. Scrum Masterin pitäisi saada olla ”ketteryyden whistleblower”.
3. Kuuntele tiimejä ja ihmisiä – ihmiset kyllä tietävät, että jotain on vinossa. Pidä huolta, että tiimit pitävät retrospektiivejä, ja pidä myös ”overall retroja” koko hankkeen puitteissa. Pidä huolta, että retroissa käsitellään priorisointia ja tuotelaatuista testausta, tai että niihin liittyvät asiat saavat kaistaa.

 Tarvitsetko neuvoja ketteryyden kanssa? Tutustu Agile-oppaaseemme tai ota meihin yhteyttä!