Mitä yhteistä on IT-infran ylläpidolla ja ohjelmistokehityksellä? Ei hätää, en aio kirjoittaa devopsista. Sen sijaan kerron, miten menestyneistä ohjelmistokehityksen käytännöistä voidaan ottaa mallia IT-palveluiden ylläpitoon ja kehitykseen.

IT-palvelualalla projektien aikataulujen venyminen on enemmän sääntö kuin poikkeus. Käytetyt projektinhallinnan menetelmät eivät anna luotettavia ennusteita työmääristä, ja niiden hallinnointi on raskasta. On tavallista, että projektit hyväksytetään tuotantoon raakileina. Näin erilaiset projektihännät jäävät kasvattamaan korjausvelkaa, mikä on turhauttavaa kaikille osapuolille.

Ongelman juurisyy on siinä, ettei monimutkaisissa projekteissa ole aina tarkkaa käsitystä kahdesta asiasta: miltä lopputulos näyttää, ja mitä vastoinkäymisiä matkan aikana tulee. Lisäksi hyödylliseltä kuulostavaa tekemistä on helppo keksiä, mutta mistä tiedämme, että keskitymme siihen, mikä on asiakkaalle arvokkainta?

Ketterän kehityksen menetelmät ovat meille tuttuja ohjelmistokehityksen puolelta, mutta ne on luotu ratkaisemaan juuri tällaisia ongelmia. Menetelmiä on useita, mutta yksi keskeisimmistä on Scrum, jonka kehitys lähti vauhtiin 90-luvun alkupuolella ja joka on sen jälkeen tullut hyvin monentyyppisten tiimien käyttöön.

Scrumista on kirjoitettu paljon. Siitä on myös julkaistu ilmainen, suomenkielinen opas, jossa perusperiaatteet on kuvattu erittäin hyvin. En tässä avaa varsinkaan käytännön puolta; ennen käytäntöön soveltumista on hyvin tärkeää ymmärtää miksi Scrum on olemassa ja minkälaisiin arvoihin se perustuu.

Scrum perustuu monitaitoisiin tiimeihin, jotka ihanteellisesti sisältävät kaikki ne ihmiset, jotka tarvitaan jonkin kokonaisuuden rakentamiseksi. Työ tehdään itseohjautuvasti, eli tiimi päättää itse työnjaosta ja priorisoinnista, mikä tukee sitoutumista. Hyvin toimivassa scrum-tiimissä jäsenet oppivat jatkuvasti toisiltaan ja työ ohjautuu luonnostaan kohti yhteisiä tavoitteita: se on siis siiloutumisen vastakohta.

Menetelmän pohjalla on empirismi, eli kokemuksen kerääminen ja päätösten tekeminen tosiasioihin perustuen. Tähän liittyvät seuraavat keskeiset periaatteet:

• Läpinäkyvyys: Työn ja se etenemisen tulee tehdä havaittavaksi kaikille osapuolille. Kaikella tekemisellä esimerkiksi tulee olla yhteisesti sovittu valmiin määritelmä (definition of done), jolloin sen valmistuminen voidaan yksiselitteisesti hyväksyä.
• Iteratiivisuus: Työtä tehdään ennalta sovituissa, toistuvissa ajanjaksoissa, jotka mahdollistavat tiimin keskittymisen, mutta ovat riittävän lyhyitä suunnanmuutosten tekemiseksi.
• Tarkastelu ja sopeuttaminen: Sekä tehtyä työtä että tulevaa tarkastellaan säännöllisesti, ja havaintojen perusteella tehdään muutoksia. Tavoitteena on positiivinen kierre, jossa epäonnistumisista opitaan ja onnistumiset antavat uutta energiaa etenemiselle.

Scrumia ja muita ketterän kehityksen menetelmiä on ohjelmistokehityksessä ja muuallakin hyödynnetty pitkään, ehkä yhtä usein väärin kuin oikein. Harmittavan usein on tilanteita, joissa mallia noudatetaan vain pinnallisesti: jaetaan roolit ja pidetään palaverit mallin määritelmien mukaisesti, mutta pohjimmiltaan toiminta ei eroa aiemmasta. Tällöin Scrum-mallista on pelkkää haittaa.

Vaikka Scrum on periaatteiltaan ja käytännöltään helppo ymmärtää, sen hallitseminen vaatii tiimiltä ja koko organisaatiolta opettelua ja harjoittelua, ja se vie aikaa. On tärkeää pitää mielessä, että mikään prosessi ei saa olla olemassa itseään varten, vaan sen tulee tukea tekemistä ja edellä kuvattuja periaatteita. Eri malleista tuleekin poimia työn luonteeseen ja tiimin koostumukseen sopivat keinot.

IT-palvelutyössä ehkä tyypillisin piirre ovat päivittäin tulevat erilaiset muutospyynnöt ja häiriöt, joita ei voida etukäteen suunnitella. Ne vievät helposti keskittymiskykyä ja kuluttavat voimavaroja vaikeasti ennustettavalla tavalla, joten ne vaativat erityistä huomiota. Niissäkin empirismin periaatteet ovat hyödyksi: pyri tuomaan näkyväksi niiden aiheuttama kuormitus, ja kehitä toimintamallia jatkuvasti.

Scrum on siis sovellettavissa moneen muuhunkin asiaan kuin ohjelmistokehitykseen. Oikein toteutettuna parannat sillä tiimisi ja sen palvelemien sisäisten ja ulkoisten asiakkaiden tyytyväisyyttä, kun se auttaa ohjaamaan työtä oikeaan suuntaan ja jatkuvasti parantamaan toimintatapoja. Pidä mielessä: ihmiset ja yhteistyö ovat tärkeämpiä kuin prosessit ja työkalut!