Rakas ketteryys, kaipaan sinua. Olen kouluttautunut saloihisi ja nähnyt pilkahduksen sinusta useissa projekteissa. Mutta voisimmeko tavata kunnolla?
Miten kolmiodraama ketteryyden, toimittajan ja asiakkaan välillä saadaan toimimaan?
Ketteryydestä on tullut muotitermi, jolla halutaan viestiä nykyaikaisuutta ja tehokkuutta. Se, mitä ketterä ohjelmistokehitys oikeasti on, on jäänyt yksinkertaistuksien, suoranaisten myyttien varjoon. Nämä myytit voivat johtaa kokemukseen siitä, että ketterä kehittäminen ei toimi, vaikka todellisuudessa yritysten oma toimintaympäristö ei tue agilea tai ketteriä toimintatapoja.
Myytti: Ketteryys on yhtä kuin Jira, sprintit ja seremoniat
Yrityksestä halutaan tehdä ketterä, joten olemassa olevien käytäntöjen päälle on lisätty Jira, sprintit ja standardoituja seremonioita. Henkilöstö ei nyt ihan tiedä mitä se ketteryys on, mutta tadaa, ketterä tekeminen on arkipäivää!
Ei nyt ihan näin.
Todellisuudessa ketteryyden määrittelevät ihan muut asiat kuin tiettyjen työkalujen tai prosessien käyttö. Ketteryys ei ole metodi, vaan filosofia ja kulttuuri, ja jos siihen ei ole sitouduttu, sen juurruttaminen organisaatioon vaatii paljon työtä kaikilta organisaation jäseniltä.
Ketterän kehityksen ydin on agile-manifesti:
Löydämme parempia tapoja tehdä ohjelmistokehitystä, kun teemme sitä itse ja autamme muita siinä. Kokemuksemme perusteella arvostamme:
Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja
Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota
Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja
Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa
Jälkimmäisilläkin asioilla on arvoa, mutta
arvostamme ensiksi mainittuja enemmän.
Tähän peilaten on selvää, että kun vanhojen toimintatapojen päälle liimataan ketteryyteen yhdistettyjä menetelmiä ja työkaluja, se ei tee kenestäkään ketterää. Ja onpa käynyt niinkin, että ketterä tiimi on muuttunut jäykäksi sprinttien käyttöönoton jälkeen.
Todellista ketteryyttä on toiminnan mukauttaminen sen mukaan mikä toimii, ei valaa betoniin ”ketteriä” toimintatapoja. Hankaluus onkin siinä, että pitää löytää ne omaan organisaatioon, tiimiin ja projektiin sopivat ketteryyttä tukevat asiat, ja olla valmis muokkaamaan niitä tarvittaessa. Siksi ylhäältä päin saneltu ketteryys ei toimi.
Ja tuosta manifestista vielä; sehän ei sitten tarkoita, että esimerkiksi dokumentoinnin voi unohtaa kokonaan. Jos dokumentaatiota ei ole, sitä saa vaatia, vaikka käytössä olisikin ketterät menetelmät. Ketterässä kehityksessä dokumentaatio elää kehityksen mukana ja sitä löytyy useissa eri muodoissa: käyttäjätarinat, tekniset määritelmät, järjestelmäkuvaukset sekä käyttäjäohjeet.
Myytti: Ketteryys on helppo keino toiminnan tehostamiseen
Tavoitteista on jääty ja projektitkaan eivät suju niin tehokkaasti kuin haluttaisiin. Kyllähän tämä kaikki taklataan ketteröittämällä toiminta!
Mietitäänpä vielä.
Mikäli halutaan pikavoittoja ja toiminnan tehostamista nopeasti, ei ketterä kehitys ole ratkaisu. Se edellyttää toimiakseen luottamusta, tekijöiden autonomiaa, oikeanlaisia resursseja sekä sitoutuneita tekijöitä ja johtoa. Tämä vaatii paljon niin tiimin jäseniltä kuin johtajiltakin, ja on hyvä muistaa, että yksi mätä omena pilaa helposti koko korin. Tämän vuoksi on selvää, että ketteryys vaatii useissa organisaatioissa isompaa kulttuurista muutosta.
Yleisimpiä syitä sille, miksi ketteryyttä ei saada toimimaan, ovat:
- Ymmärryksen puute ketteryyden rooleista, seremonioista ja suunnittelutavoista
- Johdon sitoutumattomuus
- Tiimin sitoutumattomuus
- Luottamuksen puute
- Muutosvastarinta
- Apatia
Esimerkiksi luottamuksen puute aiheuttaa helposti sen, että johtajat tekevät kaikki suunnitelmat ja päätökset varsinaisten tekijöiden sijaan, ketteryyden hengen vastaisesti. Tällöin suunnitellaan helposti aivan liikaa työtä, ja kun suunnitelmat ovat tekijöiden kannalta epärealistisia ja tapahtuu odottamattomia muutoksia (se legendaarinen yksi pieni muutos ei olekaan niin pieni), johdon odotus usein on, että työt pitää vain saada tehtyä suunnitelman mukaisesti verellä, hiellä ja kyynelillä. Tällöin ketteryyden prosessit viskataan sivuun ja lakaistaan pois tieltä.
Tuloksena on kaaosta, huonoa koodia ja korjauskierteitä, budjetin ylityksiä sekä ohi menneitä deadlineja. Kokonaisuuden kruunaa työuupumuksen partaalle ajetut työntekijät. Ja jos joku nostaakin esille suunnitelmien epärealistisuuden, hänet leimataan helposti hankalaksi ja muutosvastarintaiseksi.
Myytti: Ketterän tiimin rooleilla ei ole niin suurta merkitystä, ja ne voivat hyvin olla osa-aikaisia
Kokeneesta koodarista tehtiin Scrum Master, kun se tietääkin niin paljon, mutta ei hänellä mitään kaistaa tai kiinnostusta Scrum Masterin töihin ole, sehän on vaan palaverien järjestämistä. Tiimiläisetkin osallistuvat vain osa-aikaisesti tähän ketteryyshommaan.
No tuota, siis.
Scrum Masterin rooli on usein väärin ymmärretty. Kyseessä on vaativa, valmentava rooli, jonka vastuihin kuuluu paitsi seremonioiden organisointi, myös tiimin tehokkuuden seuranta, esteiden poistaminen, fasilitointi, käytäntöjen parantaminen sekä työrauhan takaaminen ja toisaalta myös tuoteomistajan ja devaajien välisessä kommunikoinnissa auttaminen. Onnistuakseen tehtävässään Scrum Masterilla on oltava sekä johdon että tiimin tuki, jotta esiin tulleita ongelmia voidaan käsitellä avoimessa ja ratkaisukeskeisessä ilmapiirissä.
Liian usein kuitenkin näkee sitä, että Scrum Master on kokopäiväisen roolin sijaan vain yksi henkilön hatuista, ja useimmiten niistä vähiten tärkeä, jolloin arvokas, palvelevan johtajan rooli kapenee palaverien järjestämiseen.
Ketterän tiimin tehokkuus puolestaan laskee, jos tiimin jäsenet ovat mukana alle 100 %:n allokaatiolla. Kun velvollisuuksia on myös muualla, syö kontekstin vaihtaminen kapasiteettia, eivätkä tiimiläiset ole tavoitettavissa silloin kuin heitä tarvittaisiin. Ja jos henkilöt kuuluvat toiseen ketterään tiimiin, seremonioissa vietetty aika tuplaantuu.
Ketterässä kehityksessä riippuvuuksia tulisi välttää, ei luoda niitä tiimirakenteilla. Lisäksi varsinkin alle 50 %:n allokaatiot lähettävät ikävää viestiä: jokin muu on tärkeämpää kuin se, mitä ketterä tiimi on tekemässä.
Ketterää kehitystä tehtäessä olisikin tärkeää varmistaa, että tiimillä on tarvittavat resurssit sekä rooleihinsa tarvittava osaaminen. Esimerkiksi projektipäällikkö ei ole sama kuin tuoteomistaja, pääkäyttäjä tai järjestelmäarkkitehti. Tiimin pitää lähtökohtaisesti olla resursoitu niin, että he voivat mahdollisimman pitkälle toimia autonomisina ja pystyvät itsenäisesti edistämään vaatimusten kehitystä. Luotto tiimin osaamiseen on yksi ketteryyden peruspilareita.
Myytti: Ketteryys on vain ohjelmiston toimittajan asia
Ohjelmiston toimittaja sulkeutuu tiloihinsa tekemään projektia ketterästi, ja ulos tuleekin juuri asiakkaan toiveiden mukainen järjestelmä ilman sen kummempaa vaivannäköä asiakkaan puolelta. Kätevää!
Ehei.
Ketterissä projekteissa saattaa helposti unohtua se, että asiakkaalta vaaditaan projektin aikana huomattavasti enemmän osallistumista kuin perinteisessä vesiputousmallissa. Ketteryys perustuu vahvasti yhteistyöhön ja kanssakäymiseen asiakkaan kanssa, jotta rakennettava ohjelmisto toimisi juuri siten kuin asiakas toivoo.
Ketterin menetelmin tehtäessä asiakkaalta odotetaan liiketoimintamäärittelyä, kysymyksiin vastaamista, kommentteja sekä mielipiteitä. Asiakkaan on myös oltava valmis ottamaan vastaan osatoimituksia, testattava niitä ja kommentoitava, jos joitain asioita halutaan muuttaa.
Mikäli asiakas ei osallistu projektin aikana, kasaantuu riski projektin loppuun, mikä on tunnetusti keskeinen piirre vesiputousprojektissa.
Jos asiakkaan resurssit eivät riitä ketteryyteen, kannattaa projektin toteutusmallia vielä miettiä uudelleen.
Projektimallin valinta: ketteryys, vesiputous vai jotain ihan muuta?
Kuten kaikesta edellä mainitusta voi päätellä, kriittinen harkinta on aina paikallaan projektin toteutusmallia valittaessa.
Usein näkökulmaa vääristää keskustelu, joka pyörii paljon sen ympärillä, mikä on huonoa vesiputouksessa. Vesiputousta pidetään auttamatta vanhanaikaisena, jolloin ketteryyden valintaa ei välttämättä edes kyseenalaisteta. Samalla usein unohdetaan se, että puhdaskaan ketteryys ei ole sen helpompaa tai halvempaa kuin perinteinen vesiputous.
Projektin toteutusmallia tarkastellessa on hyvä huomioida erityisesti nämä seikat:
- Organisaation ydinarvot
- Projektin tärkeimmät liiketoimintatavoitteet
- Projektin tärkeimmät rajoitteet (aika, resurssit, laatu, budjetti)
- Projektin monimutkaisuus
- Projektin koko
- Sidosryhmät
- Riskit
Monet projektit ja hankkeet edellyttävät tarkoin kuvattuja aikatauluja ja prosesseja, tarkkoja määrittelydokumentteja, arkkitehtuurikuvauksia, datamalleja ja projektin laajuuden lukkoon lyöviä sopimuksia. Tämä ei ole linjassa ketteryyden filosofian kanssa, joka painottaa yhteistyötä, asiakaslähtöisyyttä sekä muutoksen hyväksyntää ja siihen reagoimista.
Ketterää mallia on siis turha soveltaa projekteihin, joissa jo heti alussa tiedetään, että lähtökohdat ovat ketteryyttä vastaan. Tärkeintä on kuitenkin arvon tuottaminen, ei tapa, jolla arvoa tuotetaan.
Rakkautta on monenlaista, ja jos kolmiodraama ketteryyden, toimittajan sekä asiakkaan välillä aiheuttaa harmaita hiuksia, Qalmarilta saa pariterapiaa tai apua täydellisen matchin löytämiseen.
