Milloin Scrum ei toimi?

Mystesin asiantuntijat keskustelevat

Ketteryys. Lean. Agile. Scrum. Nämä kuluneet muotisanat hallitsevat edelleen IT-pöhinän sävyttämiä kahvipöytäkeskusteluja ja IT-projektijohtamisen hypeä, vaikka ovat arkipäivää useimmissa ohjelmistoprojekteissa.

Esimerkiksi Scrum on kuitenkin vain yksi tapa tehdä asioita, ja perusteluita muillekin käytännöille löytyy. Milloin Scrum toimii ja milloin ei? Asiantuntijamme keskustelevat ja avaavat omia näkemyksiään ja kokemuksiaan Scrumista.

Vesalla on 15 vuoden kokemus erilaisista ohjelmistoprojekteista. Hän on toiminut kehittäjärooleissa, tuoteomistajana ja projektipäällikkönä. Eri kokoiset tiimit, erilaiset asiakkaat sekä onnistuneet ja epäonnistuneet projektit ja näiden satunnaiselta vaikuttava korrelaatio innostivat tarkastelemaan ohjelmistokehityksen prosesseja. Vesa Keskinen

Software Architect, Mystes Oy

Ilkalla on yli 12 vuoden kokemus ohjelmistoalalta. Hän on työskennellyt ketterien menetelmien parissa Scrum masterina, kehittäjänä ja toiminnallisuusarkkitehtina. Hän on kiinnostunut erilaisista tiimikulttuureista ja siltojen rakentamisesta. Ilkan mielestä yksinkertainen on kaunista. Ilkka Vanhanen

Senior Software Developer, Mystes Oy

Scrum on joukko menetelmiä, joilla ujutetaan ketteryyttä osaksi päivittäistä tekemistä. Se tarjoaa selkeän työkalupakin, jolla suurempikin organisaatio voi halutessaan kääntää prosessiensa suuntaa menneestä kohti tulevaa, jähmeästä ketterämmäksi. Scrumin liitännäiset, kuten SAFe, tarjoavat konkreettisia keinoja muutoksen toteuttamiseen.

Tekeekö Scrum autuaan ketteräksi?

Vesa: Keskustelu on aina hyvä avata provosoivasti, jotta päästään heti vauhtiin. Todettakoon siis ykskantaan, että mielestäni Scrum on myynyt sielunsa ja siitä on tullut pelkästään vesiputousmalli uusissa vaatteissa. Lisäksi jo pelkkä Scrumin käytäntöjen sokea noudattaminen saa liian monet organisaatiot julistautumaan ketteriksi.

Ilkka: Scrumista on kieltämättä tullut muotisana ja sitä käytetään turhan väljästi yhteyksissä, joilla ei ole juuri mitään tekemistä Scrumin kanssa. Tämä ei kuitenkaan ole Scrumin vika.

Scrum ei yksinkertaisesti toimi silloin, kun asiakas, organisaatio tai tiimi ei ole mallin takana. Sitä ei voi pakottaa ylhäältä päin. Jos Scrum on vain päälle liimattu markkinointisana eikä avointa ja adaptiivista projektinhallintamallia tosissaan harjoiteta, kyse ei ole Scrumista.

Mitkä ovat Scrumin merkittävimmät ongelmat käytännössä?

Vesa: Mielestäni ehkä suurin käytännön ongelma on, että Scrumissa (varsinkin SAFe:n kanssa) yritetään saavuttaa läpinäkyvyyttä, hallittavuutta ja ennustettavuutta varsinaisen arvon tuottamisen kustannuksella.

Pahiten tämä näkyy sprinttien suunnittelussa: päätöksiä lyödään lukkoon liian aikaisin, backlogille pudotellaan liian monta toiminnallisuutta kerralla, työn määrää ja kustannuksia arvioidaan hatusta heittämällä. Eikä keskitytä siihen, mikä olisi oikeasti tärkeää tai riittävää.

Hallittavuutta tai ennustettavuutta ei pitäisi ylipäätään edes tavoitella. Sen sijaan täytyisi ymmärtää, että vasta tekemisen myötä löytyy oikea suunta. Läpinäkyvyyttä puolestaan ei voi muulla keinoin saada kuin osallistumalla ja sitoutumalla tiimin päivittäiseen työskentelyyn.

Hallinnan illuusio on pahasta: kannattaa tiedostaa mitä voi oikeasti kontrolloida ja missä hallittavuuden tavoittelu vain heikentää tosiasioiden havaitsemista

Ilkka: Mielestäni nimenomaan läpinäkyvyys on paras tapa hallittavuuden tai ennustettavuuden lisäämiseksi. Täydellistä läpinäkyvyyttä ei ole mahdollista saavuttaa, mutta Scrum tarjoaa erinomaiset työkalut sen parantamiseen. Siitä olen eri mieltä kanssasi, että läpinäkyvyyden tavoittelu olisi jotenkin arvon tuottamisen kanssa ristiriidassa. Eikö hyvä näkyvyys nimenomaan mahdollista nopeat korjausliikkeet ja minimoi turhan työn?

Olen samaa mieltä siinä, että hallinnan illuusio on pahasta: kannattaa tiedostaa mitä voi oikeasti kontrolloida ja missä hallittavuuden tavoittelu vain heikentää tosiasioiden havaitsemista. Sprint-suunnittelussa ei yritetä hallita asioita, joita ei vielä tunneta, vaan tehdään paras arvaus siitä, mihin suuntaan seuraavaksi mennään. Arvausta parannellaan, kun tiedetään lisää, ja tiimille ja sidosryhmille voidaan kommunikoida yhteinen lyhyen aikavälin suunta.

 

Ennustettavuus on vaikea juttu. Yleensä tuo liittyy työmäärän tai aikataulun ennustettavuuteen. Nykyään IT-projekteissa tiedostetaan jo hyvin se, että kompleksisten ongelmien ratkaisemiselle ei voi laittaa kiinteää hintalappua tai aikataulua. On kuitenkin ymmärrettävää, että reaalimaailmassa toimivaa asiakasta kiinnostaa erityisesti hintalappu ja aikataulu.

Scrum ei tarjoa valmiita ratkaisuja työn määrän tai kustannuksien absoluuttiselle arvioinnille. Se olisikin hullunkurista, koska ketterissä projekteissa ymmärretään, että maali on liikkuva. Scrumin anti ennustettavuudelle tulee avoimuudesta sekä yhteisesti sovituista raameista, jotka tarjoavat minimaalisen mutta riittävän määrän terminologiaa, rytmitystä ja reunaehtoja.

Minkälaisia kokemuksia tulee mieleen läpinäkyvyyteen ja hallittavuuteen liittyen?

Vesa: Läpinäkyvyys on mielenkiintoinen juttu. Olen ollut mukana projektissa, jossa hankittiin jopa ulkopuolinen konsulttitiimi tuomaan lisää näkyvyyttä johdolle. Avainhenkilöt eivät ehtineet edes aloituspalaveriin paikalle, joten saimme heti alkuun huonon esimerkin sitoutumisesta.

Oli prosessi Scrumin tai minkä tahansa muun mallin mukaista, läpinäkyvyys vaatii kaikkien osapuolten sitoutumista ja osallistumista. Vaikka läpinäkyvyys ei missään nimessä sodikaan arvon tuottamista vastaan, on edellä mainitun kaltainen toiminta parhaimmillaankin haaskausta (waste).

Projektin hallinnassa ja työmäärien ennustamisessa (tai parhaiden mahdollisten arvausten tekemisessä) on tärkeätä, että sitä tehdään tarpeeksi usein ja oikeista syistä. Sprinttien suunnittelussa ei saisi keskitytä siihen, saataisiinko nykyisellä tiimin vauhdilla (velocity) vielä “pari uutta juttua mukaan sprinttiin”.

Ehkä voisi ajatella, että vesiputous ja Scrum vastaavat vain eri kysymyksiin. Koska Scrumista on tullut muotia, organisaatiot yrittävät pakottaa sen tuosta vain vesiputouksen paikalle. Kent Beckiä ja 3X:n mallia mukaillen tuotteilla ja projekteilla on erilaisia vaiheita: Alussa voidaan saavuttaa suuria voittoja eikä menetetä juuri mitään, vaikka mentäisiin metsään. Pidemmällä elinkaarta voitot, joita voidaan saavuttaa, ovat pieniä, mutta menetettävää on paljon. Silloin on aivan varmasti tärkeää tehdä asioita hallitummin, kun taas alkumatkalla luova kaaos voi olla jopa hyväksi.

Läpinäkyvyys vaatii kaikkien osapuolten sitoutumista ja osallistumista

Ilkka: Asiat eivät tietenkään ole mustavalkoisia, vaan jopa saman projektin eri vaiheissa ketteryys ja ennustettavuus saavat ihan erilaisia merkityksiä. Tärkeintä on tuntea työkalupakki hyvin, kuunnella asiakasta ja ympäristöä ja osata valita kuhunkin tilanteeseen sopivat työkalut projektin koko elinkaaren aikana.

Itselleni tulee mieleen tapaus, jossa asiakkaan vaatima ”perinteinen” projektimalli ja ennustettavuuden tarve sovitettiin ketterään kehitysmalliin. Jaksotimme projektin hyväksymistestauksineen ja toimituksineen sprintin pituisiin kokonaisuuksiin. Asiakas hyväksyi jokaisen sprintin toimituksen erikseen. Seuraavan toimituksen sisältö sovittiin yhdessä.

Asiakkaalla säilyi riittävä kontrolli kokonaiskustannuksista ja projektin seuranta oli helppoa. Toisaalta kehitys pysyi ketteränä ja nopea toimitus- ja palauterytmi mahdollisti suunnanvaihdokset tarpeen mukaan.

Vesa: Kuulostaa mielenkiintoiselta! Eiköhän jatketa keskustelua tästä aiheesta. Ehkä löydämme myös lisää konkreettisia esimerkkejä Scrumin toimivuudesta? Minkälaisia yhteisiä tekijöitä niistä voisi hahmottua?

Hyviä juttuja vuodelta 2016 Täällä Mystesillä on saatu uusi vuosi mukavasti rullaamaan. Meistä jokainen taitaa odottaa vuodelta 2017 paljon, eikä syyttä. Nyt keskitymme kuitenkin vielä hetkeksi muistelemaan kaikkia niitä hyviä juttuja, jotka jäivät mieleen viime vuodesta. Mystes on yhtä kuin mystesläiset Kerätessä miette...
IoT – Katsaus esineiden internetiin Internet of Things (IoT) on ollut ilmoilla kohta jo vuosikymmenen. Käsite on laaja ja aiheeseen on liittynyt jonkun verran hypeä. Riisumalla mielikuvat ja katsomalla tosiasioita voi kuitenkin päätyä toteamaan, että esineiden internet tarkoittaa oikeasti isoa muutosta.
Ratkaiseeko IT-yrityksen koko vai halu palvella? Gartnerin raportti kertoo IT-markkinoilla meneillään olevasta muutoksesta, jossa pienet ja keskisuuret IT-yritykset ovat nousemassa yhä useammin merkittävien IT-järjestelmien toimittajiksi. Trendin takana lienee yrityksissä yhä useammin tehty havainto, että pienehköt IT-talot kuuntelevat asiakkaitaa...
Mutkatonta, avointa ja tehokasta yhteistyötä Vuoden 2016 asiakaskyselymme palautteet on käyty tarkasti läpi. Saimme jälleen kerran reilusti erinomaista palautetta ja hyviä kehitysehdotuksia! Parempaa tulosta ei voisi toivoa: 100% kyselyyn vastanneista on suositellut tai suosittelisi palveluitamme.
Miksi ohjelmistotestaus kannattaa? Usein kuulee sanottavan, että ohjelmistotestaus parantaa ohjelmiston laatua. Ohjelmistotestaus kyllä liittyy kiinteästi ohjelmiston laatuun, mutta pelkkä testaus ei suoraan ohjelmistonlaatua paranna. Parannuksen tuo se, että testauksen tulokset otetaan tosissaan ja niiden pohjalta tehdään korjaavat ...

Jaa tämä sivu