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ä

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 yhteisretroja koko hankkeen puitteissa. Pidä huolta, että retroissa käsitellään priorisointia ja tuotelaatuista testausta, tai että niihin liittyvät asiat saavat kaistaa.