Älä jäädytä release scopea – tuhoat ketteryyden
Älä jäädytä release scopea – tuhoat ketteryyden
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? Nykyään maailma muuttuu nopeammin kuin ennen. Teknologinen ympäristö ja asiakkaan tarpeet eivät ole niin muuttumattomia kuin aikaisemmin.
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 on paljon todennäköisempää, että saadaan sellainen lopputulos kuin asiakas haluaa. Asiakkaiden tarpeet muuttuvat niin nopeasti, että 3 vuoden vesiputousmallinen, ei-ketterästi tehty projekti ei voi osua maaliin niin hyvin kuin ketterin toimintatavoin tehty projekti, johon käytetään sama aika ja raha.
Ketterällä projektiryhmä oppii tekemisen aikana paljon. Sillä on monta mahdollisuutta tarkentaa työn määrityksiä. Onnistumisen todennäköisyys on paljon suurempi. Tehokkuus on seuraus, ei tavoite. Kuka 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 jäädytetty.
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 jäädytetty, ja resurssit ja aikataulu voi muuttua (vaikka useimmiten nekin yritetään lukita). Epävarmuuksia sisältävässä hankkeessa kaikkien kolmen lukitseminen on toiveajattelua. Tämä lähestymistapa johtaakin väistämättä kustannusten kasvamiseen ja aikataulun venymiseen.
Jäädytetty release scope ja ketteryys ei sovi yhteen
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.
Kaikkia hankkeen hankaluuksia ja “Mr Murphy iski taas” hetkiä ei voida ennustaa. Jokainen ongelma vaatii aikaa, rahaa, resursseja ja huomiota. Aika on resurssi joka ei voi olla negatiivinen. Mitä suuremmat epävarmuudet, sitä enemmän epävarmuus näkyy jäädytetyn scopen hankkeissa aikataulun venymisenä.
Liian suuri release scope johtaa kiireeseen
Jos toteuttava tiimi heidät pakotetaan toimimaan ”jäädytetty scope” -tilanteessa, heille tulee alitajuinen kiireen tuntu toteuttaa kaikki toiminnot, jotka vaan ehkä ehditään. Mihin tämä kiire sitten johtaa? 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 epävarmat 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. Jos muutoksia tai lisätöitä tarvitaan, niihin on aikaa.
Jäädytetty scope on kuin kommunistien suunnitelmatalous
Jos scope on jäässä, 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ä
- 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.
- Vahvista Scrum Mastereja – vahva Scrum Master uskaltaa nostaa kissan pöydälle, vaikka toimitusjohtajalle asti. Scrum Masterin pitäisi saada olla ”ketteryyden whistleblower”.
- 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 yhteisretroja koko hankkeen puitteissa. Pidä huolta, että retroissa käsitellään priorisointia ja tuotelaatuista testausta, tai että niihin liittyvät asiat saavat kaistaa.
Arto Kiiskinen
Lead Consultant
Artolla on 25 vuoden kokemus tuotekehityksestä eri rooleissa ja 7 vuoden kokemus tuoteomistajien ja tuotepäälliköiden kouluttamisesta ja valmentamisesta.