Scrum on pitkään ollut ohjelmistokehityksen de-facto agile-prosessimalli. Sen perusajatuksissa on paljon viisautta: se pakottaa suunnittelijat ja tilaajan pohtimaan tavoitteita ja työn rakennetta riittävän syvällisesti. Mutta samalla Scrum sisältää muutamia rakenteellisia valuvikoja, jotka nykypäivän paineisessa kehitysympäristössä kasvavat vuosi vuodelta. Kun aikataulut kiristyvät ja tiimit hakevat todellista ketteryyttä, nämä ongelmat korostuvat entisestään.
Seuraavassa muutamia kipukohtia, jotka jokaisen nykyaikaisen ohjelmistotiimin tulisi tunnistaa ja pyrkiä taklaamaan. Nämä ajatukset ovat kypsyneet monien isojen ja pitkien projektien kautta, kun yhtään todella toimivaa scrum-prosessia ei ole vielä osunut kohdalleen!
- Sprinttien keinotekoinen rytmi
Scrum pakottaa pilkkomaan työn kalenteriperusteisiin sprintteihin. Tarkoitus on hyvä: jakaa ongelmat hallittaviin osiin ja varmistaa luotettava työmääräarvio. Käytännössä tämä kuitenkin johtaa usein keinotekoisiin jakoihin ja hätiköityihin arkkitehtuuriratkaisuihin, kun päätöksiä tehdään sprintin aikataulun, ei tuotteen laadun ehdoilla.
- Sprint failure – rakenteellinen epäonnistuminen
Jos sprintit täytetään aina aiemman velocityn mukaan, tilastollisesti joka toinen sprintti epäonnistuu. Tämä on psykologisesti raskasta: kukaan ei halua työskennellä projektissa, jossa onnistumisen todennäköisyys on 50 %. Tiimit väsyvät, motivaatio kärsii ja laatu laskee.
- “Story done” ei riitä
Scrum ohjaa tekemään ”valmista” sprintin sisällä, usein hinnalla millä hyvänsä. Kun tarina saadaan toteutetuksi ja testit menevät läpi, koodi merkitään valmiiksi. Mutta missä on “done-done-done”-ajattelu? Jos ohjelmistoa halutaan ylläpitää ja kehittää jatkossa, sen rakennetta täytyy vaalia jatkuvasti. Jokaisen ”done” tarinan jälkeen tulisikin käyttää vielä 20 % lisäaikaa laadun parantamiseen.
- Suunnittelu katoaa prosessista
Scrum ei määrittele, kuinka paljon aikaa tulisi käyttää suunnitteluun ja määrittelyyn ennen koodausta. Suunnittelutyö, backlog refinement, design, ideointi jäävät helposti näkymättömäksi, vaikka niiden pitäisi kattaa vähintään 20–30 % koko syklistä. Ilman tätä vaihetta ohjelmistosta tulee sattumanvarainen, ei harkittu. Kun sprintit täytetään pelkällä toteutustyöllä, suunnittelulle ei jää aikaa. Huono sunnittelu kostautuu pitkittyneinä toteutustunteina ja noidankehä on valmis.
- Tuotteen omistajuus on hukassa
Yhä useammin Product Ownerilla ei ole aikaa määritellä tavoitteita riittävällä tarkkuudella. Tuotteen omistajuus hämärtyy, ja tiimi joutuu arvaamaan vaatimukset itse. Tämä johtaa hajanaisiin ratkaisuihin ja hukattuun potentiaaliin.
- Tulevaisuus: määrittely korvaa koodauksen
Kun tekoäly automatisoi koodauksen, todellinen kilpailuetu syntyy määrittelyssä. Kun “storien” toteutus hoituu nappia painamalla, jäljelle jää vain kysymys: osaammeko määritellä, mitä oikeasti haluamme rakentaa? Tulevaisuudessa jokaisen storyn toteutusarvio on 0 tuntia, 0 story points ja arvo syntyy vain ihmisen kyvystä ajatella.
Scrum ei ole paha, se oli vain aikansa tuote. Nyt on aika päivittää ajattelu seuraavalle tasolle: rakentaa kehitysprosesseja, jotka korostavat suunnittelun laatua, tuotteen omistajuutta ja jatkuvaa arkkitehtuurin ylläpitoa. Sekä entistä kattavampaa testausta -> shift left.
Scrum on kuollut, eläköön ajattelu!
(Artikkelin kuva luotu tekoälyllä)