Ketteryys on aikuistumassa – ja se sattuu

Kirjoittaja: Teemu Hyyryläinen, Certified Scrum Trainer® (CST®)

Toistakymmentä vuotta sitten koulutushuoneessa piti vielä perustella, miksi puolen vuoden vaatimusmäärittelyt eivät toimi. Tänään tilanne on toinen. Lähes jokainen osallistuja on jo “tehnyt Scrumia” – ja monella on takanaan kaksi tai kolme muutoshanketta ja yhtä monta turhautumista.

Viime syksynä eräs Product Owner kertoi minulle aamukahvilla:
“Meillä on Scrum kunnossa. Sprintit, dailyt, retrot, kaikki. Mutta en muista, milloin viimeksi sanoimme ‘ei’ jollekin.” Sen jälkeen kahvi jäähtyi.

Tähän kahvitaukoon tiivistyy se, missä ketterä kehitys tällä hetkellä on.

Mekaaninen ketteryys syö vaikuttavuutta

Rakenteet ovat paikoillaan, mutta ydin puuttuu. Sprint Review on demo, ei päätöksenteon paikka. Backlog on toivelista, ei valintojen väline. Tuoteomistajalla on vastuu, mutta ei valtaa. Retrospektiiveissä kirjataan toimenpiteitä, joita kukaan ei ehdi tehdä.

Kutsun tätä mekaaniseksi ketteryydeksi. Se ei ole tiimien vika. Tiimit tekevät parhaansa siinä ympäristössä, joka niille on rakennettu. Ongelma on, että rituaaleja toistetaan ilman muistoa siitä, mitä ongelmaa ne alun perin ratkaisivat.

Kolme toistuvaa pulmaa – ja mitä niille voi tehdä

1. Tarkoitus on hämärtynyt
Manifeston syntykonteksti – pitkät suunnitteluvaiheet, myöhäinen palaute ja tuotteet, jotka eivät vastanneet muuttuneeseen tarpeeseen – on monelle uudelle ketteryyden tekijälle kaukainen tarina. Kun alkuperäinen ongelma unohtuu, ratkaisu muuttuu rituaaliksi.

Tämän voi kääntää oman tiimin tasolla yksinkertaisella kysymyksellä:
Minkä ongelman tämä palaveri ratkaisee? Jos vastausta ei löydy, palaveri ei ole ketterä, vaikka sen otsikko olisi.

2. Tuoteomistajuus on yhä pullonkaula
Suomalaisissa organisaatioissa rooli annetaan usein kiireiselle päällikölle tai asiantuntijalle, joka jatkaa entistä työtään ja saa Product Owner -tittelin “siihen päälle”. Mandaatti puuttuu, ja backlog paisuu sidosryhmäpolitiikan kentäksi.
Tämä on kohta, jossa moni hyvä PO väsyy.

Pidin viime keväänä koulutusta, jossa eräs osallistuja kertoi luopuneensa “ei”-sanan käytöstä kokonaan – sitä ei kuitenkaan kuunnella. Pyysin häntä kuvaamaan tilanteen, jossa “ei” oli viimeksi epäonnistunut.

Selvisi, että hän oli sanonut ei yksin, sähköpostissa, ilman vaihtoehtoa.
Sitten teimme yhdessä toisen muotoilun: “Voin ottaa tämän, jos jätämme tuon. Kumpi teille tuottaa enemmän arvoa?” Seuraavalla viikolla hän kirjoitti, että ensimmäistä kertaa kahteen vuoteen sidosryhmä oli itse ehdottanut, että jokin asia siirretään myöhemmäksi. Mandaatti ei aina ole annettavaa. Joskus se on muotoiltavaa.

3. Johtaminen muuttuu hitaammin kuin tiimien arki
Tämä on rehellisesti sanottuna se, joka pysäyttää useimmat ketterät muutokset.
Jos organisaatio suunnittelee vuoden kerrallaan, lukitsee budjetit aikaisin ja palkitsee ennusteen noudattamisesta oppimisen sijaan, tiimitason ketteryys kuluu loppuun muutamassa kuukaudessa.

Tätä ei voi yksittäinen PO ratkaista. Mutta hän voi tehdä jotain, mikä tekee ongelmasta näkyvän: dokumentoida päätökset, jotka olisi voitu tehdä paremmin lyhyemmällä syklillä, ja viedä ne johdolle – ei valituksena vaan datana.
Se on hidasta vaikuttamista, mutta se on vaikuttamista.

Kysytkö vääriä asioita?

Käytän esimerkeissä paljon Product Owneria, mutta sama tarina koskee myös Scrum Mastereita ja johtajia – he vain kohtaavat sen eri kulmasta. PO:n työpöytä on usein paikka, jossa ketteryyden ongelmat näkyvät ensimmäisenä konkreettisena pulmana.

Olen kouluttanut Suomessa, Hollannissa, Yhdysvalloissa ja Japanissa. Kulttuurit eroavat, mutta huoli on samankaltainen: työn määrä kasvaa, päätökset hidastuvat ja markkina muuttuu nopeammin kuin organisaatio ehtii oppia.

Osallistujat tulevat etsimään kahta asiaa.

Ensimmäinen on lupa pysähtyä
He tietävät jo paljon siitä, mitä pitäisi tehdä. He tarvitsevat tilan, jossa voi sanoa ääneen, miksi sitä ei juuri heidän organisaatiossaan tehdä.
Tämä on koulutuksen aliarvostettu tehtävä: tarjota hetki, jossa todelliset ongelmat saa nimetä.

Toinen on parempi ymmärrys kompleksisuudesta
Yhä useampi tiimi toimii tilanteessa, jossa edes ongelma ei ole täysin selvä, saati ratkaisu. Silloin prosessikaaviot eivät riitä – tarvitaan kykyä saada tolkkua epäselvästä tilanteesta, kokeilla turvallisesti ja tulkita palautetta.

Valmensin viime vuonna PO:ta, joka oli juuttunut kuukausia samaan ongelmaan: tiimi ei tehnyt sitä, mitä hän pyysi. Ratkaisuja oli kokeiltu kymmeniä. Kun istuimme alas Cynefin-viitekehyksen kanssa, kävi ilmi, että hän oli kohdellut tilannetta selkeänä – “sano selkeämmin mitä haluat” – vaikka se oli alusta asti ollut kompleksi.

Tiimi ei ymmärtänyt asiakastarvetta. Sitä ei ratkaista paremmilla user storyilla, vaan menemällä yhdessä asiakkaan luokse. Hän lopetti tarinoiden kirjoittamisen ja vei tiimin kahteen asiakaspalaveriin.

Ongelma katosi kolmessa viikossa. Sen arvo ei ollut yhdessä uudessa mallissa. Sen arvo oli paremmissa kysymyksissä: Millaisessa tilanteessa olemme, ja mikä toimintatapa tähän sopii?

Tekoäly nostaa priorisoinnin arvoa

Kun koodia, dokumentaatiota ja vaihtoehtoja syntyy entistä halvemmalla, pullonkaulaksi ei jää tekemisen nopeus. Pullonkaulaksi jää koordinaatio, päätöksenteko ja kyky oppia todellisesta vaikutuksesta. Tekoäly nopeuttaa tekemistä, mutta ei ratkaise, mitä kannattaa tehdä, kenelle ja miksi.

Tämä on hyvä uutinen Product Ownerille. Kun tekemisestä tulee halpaa, valitsemisesta tulee arvokasta. Rooli, joka tuntuu nyt sidosryhmäpolitiikalta, voi nousta yhdeksi organisaation vaikuttavimmista paikoista – jos roolin haltija kasvaa työn vastaanottamisesta tuotteen suunnan johtamiseen.

Sama pätee laajemmin. Scrum Masterille tämä tarkoittaa siirtymää palaverien fasilitoinnista oppimisen rakenteiden kehittämiseen. Projektipäällikölle se tarkoittaa, että suunnittelu ei katoa – se jaksottuu. Sitoumukset tehdään pienempinä, palautesyklit lyhennetään ja onnistuminen mitataan vaikutuksesta, ei valmiiden tehtävien määrästä.

Frameworkit eivät tee ajattelua puolestasi

Pidän todennäköisenä, että seuraava sukupolvi ketteryyden ammattilaisia ei enää rakenna identiteettiään yhden mallin varaan. Scrum, Kanban, LeSS, SAFe ja muut viitekehykset voivat olla hyödyllisiä. Mikään niistä ei kuitenkaan tee ajattelua puolestasi.

Frameworkit eivät vapauta ajattelusta. Ne paljastavat, kuinka paljon sitä tarvitaan.

Tulevaisuuden ketterä ammattilainen ei kysy ensimmäiseksi, mitä malli sanoo.
Hän kysyy, mitä tilanne vaatii.

Lopulta tärkeintä on vastaus tähän kysymykseen

Kun minulta kysytään, missä ketterä kehitys on tänään, vastaan näin:

Se on aikuistumassa. Innostus on takana. Mekaaninen toistaminen on tullut tiensä päähän. Edessä on vaikeampi ja kiinnostavampi kysymys:
Mitä haluamme ketteryyden olevan nyt, kun emme voi enää tyytyä seremonioihin? Jos organisaatio sanoo toimivansa ketterästi, hyvä ensimmäinen kysymys ei ole, onko heillä Scrum, Kanban tai jokin skaalattu malli käytössä.
Parempi kysymys on tämä:

Mitä voisit huomenna tehdä lyhentääksesi matkaa oivalluksesta tekemiseen?

Jos siihen on vaikea vastata, ongelma ei ole yksittäisessä toimintatavassa.
Silloin kannattaa palata siihen, mistä ketteryys lähti liikkeelle: oppimisen tekemisestä näkyväksi, nopeaksi ja toimintaa muuttavaksi. Juuri siihen sen pitäisi seuraavaksi kasvaa.