Tuoteomistaja Markus Melander harjoittelemassa kehitystiimin kanssa.
Liikenneviraston projektipäällikkö Markus Melander päätti rekrytoida kehitystiiminsä uudella tavalla, koko tiimi kerralla. Samalla opimme, että ketterää kehitystiimiä kannattaa arvioida tiiminä, ei vain yksilöinä.
Ketterä alihankintaprojekti toteutetaan yleensä joko perinteiseen vesiputousprojektien tapaan toimittajan tiloissa, tai mieluummin rekrytoimalla useammista konsulteista koottu kehitystiimi tilaajan omiin tiloihin.
Jälkimmäinen malli on havaittu toimivaksi myös julkishallinnossa. Esimerkiksi Maanmittauslaitoksen Paikkatietoikkuna-projektissa yksi kehittäjistä valittiin scrummasteriksi ja tiimin työtä ohjaa tuoteomistajana Maanmittauslaitoksen Jani Kylmäaho. Mallin etuina on, että kehitystiimi on lähellä tilaajaa, mikä helpottaa kommunikointia ja kasvattaa molemminpuolista luottamusta. Rekrytointivaiheessa yksittäisten konsulttien haastattelu voi kuitenkin vaatia runsaasti aikaa, ja sopimus tulee solmia useamman toimittajan kanssa. Tiimin yhteistyökykyä voi myös olla vaikeaa arvioida ennen työn aloittamista, jos henkilöt eivät ole aikaisemmin työskennelleet yhdessä.
Liikenneviraston Digiroad2-hankkeessa uudistetaan tie- ja katuverkkoaineisto sekä työkalut tielinjojen ja sisältötiedon (esim. nopeusrajoitukset) keräämiseen, käsittelyyn ja jakamiseen.
DR2-hankkeen tuoteomistaja Markus Melander päätti kokeilla uutta rekrytointimallia, jossa rekrytoidaan koko kehitystiimi kerralla. Tämä lähestymistapa vaatii, että vähintään kahdella toimittajalla on tarjota projektiin kooltaan ja osaamiseltaan riittävän kattava tiimi. Digiroad2-projektissa saatiin kolmelta toimittajalta tarjoukset nelihenkisestä kehitystiimistä, joka tulisi työskentelemään Liikenneviraston tiloihin Pasilaan.
Kehitystiimien haastattelemiseen ja arviointiin Markus Melander hyödynsi Pekka Sarkolan GIS- ja Lare Lekmanin Agile/Scrum -asiantuntemusta. Kunkin tiimin haastatteluun käytettiin kaksi tuntia. Markus toimi puheenjohtajana, Pekka arvioi tiimin teknistä osaamista ja Lare prosessiosaamista. Haastattelut aloitettiin perinteisillä kysymyksillä kehittäjien osaamisesta, sopivuudesta ja motivaatiosta. Sen jälkeen oli vuorossa Pekan etukäteen valmistelemat kysymykset kehittäjien tekniseen osaamiseen liittyen. Tunnin haastatteluosan jälkeen pidettiin lyhyt tauko. Sitten oli vuorossa Laren fasilitoima 60 minuutin harjoitus testaamaan tiimin yhteistyötä ja menetelmäosaamista.
Harjoituksessa tiimin tehtävänä oli kehittää verkkosivut tuoteomistajan (Markuksen) valitsemalle eläimelle. Harjoitus alkoi 10 minuuttia kestävällä sprintin suunnittelupalaverilla, jonka jälkeen tiimi työskenteli 30 minuuttia ja sai halutessaan hyödyntää tuoteomistajaa. Sitten oli vuorossa 10 minuutin sprinttikatselmus, jossa tiimi esitteli työnsä tulokset tuoteomistajalle ja sai tältä palautetta. Lopuksi tiimiä pyydettiin pitämään itsenäisesti sprintin retrospektiivi. Seurasimme harjoitusta mielenkiinnolla.
Teknisesti yksinkertainen mutta aikarajattu harjoitus kertoi yllättävän paljon tiimin yhteistyöstä ja työskentelytavoista. Esimerkiksi tuoteomistajan hyödyntämisessä oli merkittäviä eroja: Eräs tiimi otti sprintin suunnittelupalaverissa kirjallisesti antamamme vaatimukset lähes sellaisenaan vastaan, kun Agile/Scrumia paremmin tuntevat varmistivat tuoteomistajalta ymmärtävänsä vaatimusten tavoitteen ja sisällön, sopivat teknisistä kompromisseista ja pyrkivät lyhyessä ajassa maksimaaliseen arvontuottoon.
Selkeistä prosessiosaamisen eroista huolimatta kaikki kolme tiimiä onnistuivat tuottamaan potentiaalisesti julkaisukelpoiset eläimen verkkosivut puolessa tunnissa, joka oli hieno suoritus. Parhaiten suoriutui eri osaamisalueiden painotetussa arvostelussa Reaktorin nelihenkinen tiimi.
Tiimin rekrytoinnissa opimme, että tiimejä kannattaa testata myös tiimeinä, ei ainoastaan yksilöhaastatteluilla. Näin voi paremmin seurata ja varmistaa tiimin kokemuksen ja yhteistyön sujuvuuden ketterillä menetelmillä. Lisäksi havaitsimme, että tuoteomistajan ja kehitystiimin väliseen avoimeen ja läheiseen vuorovaikutukseen on hyvä pyrkiä työhaastattelusta lähtien. Tässä auttaa molemmin puolinen kunnioitus.
Läheinen vuorovaikutus asettaa vaatimuksia hankinnalle, Markus Melander:
Julkisten hankintojen koetaan perinteisesti rajoittavan hankintaprosessia ja olemassaolevat hankintamenetelmät ohjaavat myös omalta osaltaan meidän virkamiesten toimintaa. Arvioidessamme miten hankinta tulee toteuttaa, toimivat keskeisinä argumentteina suunniteltu järjestelmäarkkitehtuuri sekä ohjelmistoprojektin (ketterä) toteutusmalli. Näin jälkikäteen arvioituna tiimien haastattelut ja arvioinnin osana toteutettu tiimiharjoitus toivat hankintaan läpinäkyvyyttä ja poistivat epävarmuutta, mikä yleisesti liittyy pelkästään dokumenttien, kuten CV:n ja tarjousten perusteella suoritettuun arviointiin. Avainhenkilöiden hankinnassa on haastattelu ehdottomasti hyvä asia. Suosittelen mallin soveltamista lämpimästi kaikille.
Tiimirekrytoinnin mallia jalostetaan Liikennevirastolla edelleen suoraviivaistamaan hankintaprosessia. Olisi mielenkiintoista soveltaa haastattelua siten, että hankinnan kohteeksi asetettaisiin ensin scrummaster ja tekninen arkkitehti, jotka sitten ottaisivat vastuun kehitystiimin kokoamisesta. Tämä keventäisi hankintaprosessia ja olisi todennäköisesti myös toimittajille helpompi, koska kehittäjiä ei tarvitsisi nimetä sitoumuksella tarjouksessa niin etupainotteisesti.
Comments