Scrum ei ole kaikenratkaiseva hopealuoti
Kuten edellisessä blogikirjoituksessa kerroin, perinteisen määrittele – toteuta – testaa -vesiputousmallin käyttäminen IT-projektityössä on auttamattomasti vanhentunut toimintatapa. Eikä se ollut koskaan edes järin hyvin toimiva.
Vesiputouksen suurin ongelma on se, että kunnollisten määrittelyiden tekeminen esimerkiksi kilpailutusta varten vie aikaa ja rahaa. Ja lopputuloksena on vasta määrittely. Määrittely itse on vain dokumentti. Se ei sellaisenaan tuota mitään, ennen kuin joku toteuttaa sen.
Onko järkevää käyttää kolmasosa projektin budjetista määrittelyn kirjoittamiseen ja huomata toteutustyön edetessä, että kaikkea ei sittenkään osattu ennakoida?
Ketterät menetelmät ja scrum eivät kuitenkaan ole kaikenratkaisevia hopealuoteja. Niissäkin on omat ongelmansa.
Scrum-projektihallintamenetelmä soveltuu omien kokemusteni mukaan heikosti tilanteeseen, jossa projektiin vaikuttavat seuraavat asiat:
- Osa-aikaiset tekijät
- Maantieteellinen hajaannus
- Paljon ulkoisia riippuvuuksia
Näistä ensimmäinen kohta, osa-aikaiset tekijät, on ketterän projektityön kannalta ehkä haitallisin – joskin ratkaistavissa oleva – ongelma.
Jos tekijät eivät pääse keskittymään yhteen projektiin, on “normaalikin” projekti ongelmissa. Jossainpäin kun on kuitenkin aina kiireellinen tulipalo, jota on pakko lähteä sammuttamaan. Tällöin kärsijänä on luonnollisesti projekti ja aikataulut pääsevät pettämään.
Yksittäisen tehtävän aikataulujen pettäminen on scrum-projektissa paljon suurempi ongelma kuin perinteisessä projektissa. Tavanomaisessa projektissa projektipäällikkö pystyy pitämään takataskussaan turvamarginaalipäiviä. Scrumissa moinen ei ole mahdollista; siinä varmuusmarginaalit ovat julkisia ja suoraan sanoen tulevat paljon useimmin myös käytettyä.
Paras ratkaisu osa-aikaisten tekijöiden kiroukseen on suoraviivainen: otetaan projektiin kokopäiväisiä tekijöitä. Vaikka sitten konsultteja. Tällöin linjaorganisaation palomiehet voivat keskittyä ohjaamaan toimintaa ja projektin kannalta aikatauluongelmat ovat huomattavasti epätodennäköisempiä kuin firman omaa väkeä käytettäessä.
Maantieteellinen hajaannus on ongelmana itsestäänselvä, mutta sen vakavuutta aliarvioidaan. Työkalujen osalta etätyö on vielä kohtuullisen helposti ratkaistavissa, mutta varsinainen ongelma on – kuten projekteissa yleensäkin – ihmisten kanssa.
Jos projektiryhmä ei työskentele yhdessä tilassa, jää paljon epävirallista ja jopa sanatonta viestintää tapahtumatta. Merkittävin ongelma on ehkä “tekemisen meiningin” fiiliksen aikaansaannin vaikeus ja MBWA:n mahdottomuus.
Kuten arvostamani teoreetikko Tarmo Toikkanen kirjoittaa, maantieteellisesti hajautettu scrum-tiimikin on mahdollista saada toimimaan. Mutta se on huomattavasti vaikeampaa ja haastavampaa, kuin yhdessä tilassa kokoontuva.
Yksi oleellisimpia tekijöitä maantieteellisesti hajautetun projektitiimin toimimaansaannin varmistamiseksi on pitää kiinni kurista. Päivittäiskokouksiin on tultava. Piste. Ja tarvittaessa huutomerkki.
Viimeisenä, muttei suinkaan vähäisimpänä, ongelmana ovat ulkoiset riippuvuudet. Nämä ovat scrum-työlle puhdasta myrkkyä.
Olen itse ollut aikoinaan vierestä katsomassa tilannetta, jossa yksinkertaisesta asiasta piti sopia erään toisen projektin kanssa, mutta nämä peruivat tapaamisia jatkuvasti lyhyellä varoitusajalla ja toimivat muutenkin kuin oppikirjaesimerkissä 9780836217582.
Seuraamalleni projektille palavereiden jatkuva peruminen sekä toimitettavista asioista lipsuminen aiheutti nopeasti aikatauluongelmia. Kun backlogissa alkoi olla yksinkertaisia tehtäviä “sovi palaverista XX:n kanssa” ja “pidä palaveri XX:n kanssa” estynyt-tilassa, oli lopulta parempi jättää tämä osuus projektin scopesta kokonaan ulos.
Olen tullut siihen tulokseen, että monet kriitiset ulkoiset riippuvuudet ovat scrum-projektille “No Go”-tason ongelma. En halua lähteä vetämään scrum-projektia, jossa lopullinen onnistuminen ja tärkeät tuotokset ovat toisten projektien onnistumisen varassa. Semminkään, kun epäonnistumisen aiheuttama negatiivinen spiraali leviää scrum-tiimiin nopeasti.
* * *
Scrum ja muut ketterät menetelmät eivät ole hopealuoteja. Ne ratkaisevat monia projektityön ongelmia, mutta esittelevät monia uusia ennakkoedellytyksiä projektille.
