Ketteryyttä vain nimessä

Tämän päivän haaste ketteryydessä ovat organisaatiot, jotka pyrkivät toteuttamaan prosessin täydellisesti, mutta sivuuttavat viitekehyksen tarkoituksen kokonaan [1]. Scrum paljastaa nykyisen hallinnon, ympäristön ja työtapojen suhteellisen vaikuttavuuden, jotta niitä voidaan kehittää [2]. Toisin sanottuna Scrumin käyttöönotto luo oppivan organisaation, joka parantaa havaintojen perusteella työtapojaan, tuotteitaan ja palveluitaan.

Ketteryys on edennyt 20 vuoden aikana merkittävästi korvaten perinteisen vesiputousmallin ideaalisena tapana tehdä ohjelmistokehitystä. Perinteet ovat kuitenkin siirtyneet ketterän mallin sisälle. Puhuminen esimerkiksi suunnittelusprintistä kertoo karua kieltä tästä.

Organisaatio

Organisaatioille on ollut vaikeaa siirtyä kokonaisvaltaisesta suunnittelusta ja hierarkkisesta päätöksenteosta lyhyissä työjaksoissa eli sprinteissä toteutettavaan kokeilukulttuuriin.

Nopeasti muuttuvassa kompleksisessa maailmassa suunnitelmat ovat vanhoja jo valmistuessaan. Organisaatiokaavion antaman päätösvallan sijaan ketteryys korostaa havaintoja ja todisteisiin perustuvaa päätöksentekoa. Useimmiten lähellä asiakasta työskentelevät ihmiset pystyvät tekemään parempia päätöksiä kuin yläkerran tai pääkonttorin väki.

Scrumissa Scrum Master on todellinen johtaja, vaikka hänellä ei ole asemaan perustuvaa käskyvaltaa. Hän luo psykologisesti turvallisen yrityskulttuurin, joka lisää uskallusta tuoda esiin erilaisia vaihtoehtoja ja näkökulmia. Itseään johtavien monialaisten Scrum-tiimien perustaminen on ollut monille organisaatioille iso harppaus tuntemattomaan.

Ongelmat alkavat sopimusneuvotteluista ja sopimuksista, joiden vuoksi kyky vastata muutokseen ei ole riittävää (katso [3]). Hankintalain jäykkä soveltaminen on aiheuttanut vaikeuksia [4].

Tiimien itsehallintoa ja tulosvastuuta on heikennetty johtoryhmillä, ohjausryhmillä, asiantuntijarooleilla, raportoinnilla ja ulkoistamalla. Skaalausmallien avulla on säilytetty perinteisen organisaation byrokraattisuus.

Scrum-tiimi

Perinteiset projektipäälliköt ja tuotepäälliköt ovat monesti säilyneet tuoteomistajien rinnalla. On myös ollut vaikeaa tunnistaa, minkä tuotteen tuoteomistaja omistaa ja mitä omistaminen tarkoittaa [5]. Strategiasta saakka ulottuvan omistajuuden sijaan hänellä on usein ollut perinteisen vaatimusmäärittelijän asema.

Koska tuoteomistaja edustaa kaikkia sidosryhmiä ja käyttäjiä, hän kommunikoi paljon näiden kanssa. Tuoteomistaja vastaa kuitenkin yksin päätöksistä, jotta päätöksenteko on nopeaa ja yhtenäistä. Jos sprinttien katselmusten lisäksi tarvitaan muita muodollisia yhteistyöfoorumeita, kutsuisinkin niitä johtoryhmien sijaan neuvonantajaryhmiksi. Näiden tehtävänä on sitouttaa tilaaja- ja käyttäjäorganisaatioita tuotteen käyttöön.

Scrumin ymmärtämisestä ja käyttöönotosta sekä Scrum-tiimin tehokkuudesta vastaava Scrum Master on organisaatioille kummajainen. Siispä yksi kehittäjistä on nimetty Scrum Masteriksi oman kehittäjätyön ohella. Tämän seurauksena organisaatioon on syntynyt Scrum Masterin töitä tekevä uusi rooli: ketterä valmentaja (agile coach). Koska käskyvallaton johtajuus on tuntunut mahdottomalta, tiimien lähettyvillä häärii joskus joukko erilaisia päälliköitä, tiiminvetäjiä ja linjaesimiehiä.

Asiantuntijaroolien ja niihin pohjautuvan funktionaalisen organisaation ongelmina ovat mukautuminen työn kysynnän vaihteluihin ja eri roolien ja osastojen välinen koordinaatio. Ulkoistamisella toteutettu sopeutuminen kysynnän vaihteluihin johtaa helposti koordinaatiokaaoksen, koska muutosten pitää mennä sopimus- ja hallintobyrokratian läpi.

Monialaisessa itseään johtavassa tiimissä on kaikki kokonaisten tuotteiden kehittämiseen tarvittava asiantuntemus. Toisaalta jokaisella tiimin jäsenellä on oman eritysosaamisalueensa lisäksi sellainen joukko muita käyttökelpoisia taitoja niin, että hänen ei tarvitse etsiä työtä tiiminsä ulkopuolelta. Työn koordinaatio on luonnostaan helppoa yhtä yhteistä tavoitetta kerrallaan toteuttavassa tiimissä. Empirismi, havaintoihin perustuva päätöksenteko ja synergia ovat parhaimmillaan kun kehittäjät arvostavat toistensa osaamista ja asiantuntemusta.

Kehitysjonot ja inkrementit

Tuotteiden koostaminen pienistä valmiista paloista eli inkrementeistä on suuri muutos kehitysorganisaatioille, jotka ovat tottuneet testaamaan, integroimaan, dokumentoimaan ja toimittamaan tuotteen asiakkaalle vasta kun se on kokonaisuudessaan valmis. Vahvan valmiin määritelmän toteuttava automaatio on tullut laajemmalti käyttöön vasta pilvipalveluiden yleistyessä. Inkrementtien suunnittelu on mahdollista kun ne ovat niin pieniä, että riippuvuudet tulevat näkyviin. Parhaat organisaatiot julkaisevat monta inkrementtiä päivässä.

Tuotteen kehitysjonon tekeminen perinteisen ajattelun pohjalta johtaa täydellisen vaatimusmäärittelydokumentin kirjoittamiseen. Se saattaa sisältää työtä tiimille useammaksi vuodeksi eteenpäin tarvittavan sprintin tai kahden sijaan. Liiallinen kirjoittaminen ja liian vähäinen vuoropuhelu ohjaavat helposti kehitysjonon ja siihen liittyvän aikataulun jäädyttämiseen, joka on jyrkässä ristiriidassa ketteryyden arvojen kanssa (katso [3]). Vuoropuhelun puute ja liiketoiminnan tavoitteiden ja teknisen toteutuksen kuvaamisen ristiriidat johtavat väärinymmärryksiin.

Sprintin kehitysjono on tiimin oma työnohjaustaulu, josta näkyy päivittäin meneillään olevat työt. Se opettaa tiimiä toimimaan aitona tiiminä ja ohjaamaan omaa työtään.

Molemmissa kehitysjonoissa on tavoite, johon sitoudutaan, koska kehitysjonon kohtia voidaan muuttaa vielä myöhäisessäkin vaiheessa (katso [3], periaatteet).

Scrum tapahtumat

Scrumin tapahtumat on suunniteltu mahdollistamaan tarvittava läpinäkyvyys ja herättämään keskustelua tarvittavista muutoksista. Ne ovat muodollinen mahdollisuus tutkia ja mukauttaa Scrumin tuotoksia [2].

Sprintit mahdollistavat paremman ennustettavuuden ja nopeamman oppimisen sekä rajoittavat monimutkaisuutta ja kustannuksiin ja työmäärään liittyviä riskejä [2]. Tämä tavoite saavutetaan, kun sprintti tuottaa vähintään yhden konkreettisen inkrementin. Laadukas käyttäjäpalaute syntyy inkrementin aidosta käytöstä tuotannossa ja liiketoiminnan mittareista, jotka vähentävät palautteen subjektiivisuutta.

Sprintin suunnittelun suurimpia ongelmia ovat työmäärän arviointi ja työn rajaaminen kapasiteettiin. Kompleksisessa ympäristössä työhön tulee yllätyksiä, joihin jäädytettyyn projektisuunnitelmaan perustuva suunnittelu ei osaa varautua. Perinteinen paineen lisäämiseen perustuva johtamismalli heikentää laatua ja tätä kautta edelleen tuottavuutta.

Päivittäispalaverit tekevät työtapojen ongelmat näkyviksi. Tiiminä työskentelyn ja monialaisuuden puute näyttäytyy usein kehittäjien turhautumisena ja stressinä. Jos he ovat monessa projektissa yhtä aikaa tai tiimi joutuu odottelemaan tiimin ulkopuolella suoritettavia tehtäviä, työ etenee niin hitaasti, että päivittäispalavereja ei haluta enää pitää päivittäin.

Työn edistymisen päivittäisellä seurannalla kehittäjät varmistavat, että yllätyksistä huolimatta sprintin tavoite saavutetaan tinkimättä valmiin määritelmässä sovitusta laadusta ja realistisessa laajuudessa.

Parhaimmillaan päivittäispalaverit ovat tiimihenkeä ja synergiaa edistäviä sosiaalisia tapahtumia. Pahimmillaan ne koetaan ahdistavana hiostamisena.

Sprintin katselmuksessa on olennaista inkrementistä saadun palautteen laatu ja kehitystyön jatkon ohjaaminen oppimisen avulla kohti parempaa tuotetta. Pelkän demon arvo on sidosryhmien saamassa läpinäkyvyydessä. Katselmus ei ole muodollinen hyväksymispiste. Sen odottaminen ei saa viivästyttää hyödyllisten inkrementtien julkaisemista asiakkaille.

Sprintin retrospektiivissä tiimi oppii parantamaan työtapojaan. Sopivalla tavalla muuttuvat työtavat ovat usein seurausta siitä, että tiimin jäsenet noudattavat Scrumin arvoja (sitoutuminen, keskittyminen, avoimuus, kunnioitus ja rohkeus) henkilökohtaisella tasolla.

Yhteenveto

Ketterän toimintatavan haaste on vesiputous-ajattelun soveltaminen ketterässä prosessissa. Ketteryys on parhaimmillaan nopeasti ja arvaamattomasti muuttuvassa kompleksisessa liiketoimintaympäristössä.

Vakiintuneisiin oloihin ja massatuotantoon soveltuvassa Taylorismissä [6] optimoidaan resurssitehokkuutta eli käytännössä projektin yksittäisten tehtävien kustannuksia. Silläkin on paikkansa, koska robotit eivät ole vielä vieneet ihmisiltä kaikkea rutiininomaista työtä. Lean ja ketterät mallit optimoivat kokonaistaloudellisuutta virtaustehokkuuden avulla. Lyhyt läpimenoaika ideasta tuotantoon optimoi tuottavuutta ja laatua.

Viitteet:

1. Scrum Alliance Board of Directors: Message to staff and community, 6.1.2022.
2. Scrum opas, 2020, scrumguides.org
3. Ketterän ohjelmistokehityksen julistus, http://agilemanifesto.org/iso/fi/manifesto.html
4. https://julkisetohjelmistohankinnat.wordpress.com/
5. https://www.romanpichler.com/blog/six-types-of-product-owners/
6. https://www.process.st/taylorism/

Sinua saattaisi kiinnostaa

• Tiiminvetäjän ketterä johtajuus
• Fiksumpaa työskentelyä ketteryydellä
• Ketterä projekti – agile projektijohtaminen
• Scrum perusteet
• Product owner I (PO I)
• Scrum Master I (SM I)

Tietoa kirjoittajasta:

Pentti Virtanen

Pentti on koulutukseltaan filosofian tohtori ja Certified Scrum Trainer. Hänen erityisalueenaan on toiminnan kehittäminen erityisesti ketterillä Lean- ja Scrum-ajattelumalleilla.

Pentin pitkä ja monipuoleinen työkokemus sisältää mm. käytännön projektijohtamista suuryhtiössa ja IT start-upin kasvutarinan 15 henkilöstä 500 henkilöön. Pentin tilaisuuksissa yhdistyvät vahva teoreettinen tausta ja opettavat tarinat hänen käytännön kokemuksistaan.

Scrum Ketteryys