Koulutuksissani usein kerron esimerkkejä Scrum-menetelmän käyttämisestä väärin. Yleensä jossain vaiheessa joudun puheistani tilille, kun koulutettavat vaativat minua määrittelemään millainen on "oikea Scrum". Asian ydin on, missä asioissa voi joustaa ja missä ei, ja missä menee Scrumin rajat. Kuinka määritellään Scrum? Onko Scrumiin sääntökirjaa?
TAGS:
Eräs Scrumin ensimmäisistä käyttäjistä ja kehittäjistä, Mike Cohn, on sanonut, että "Scrum ja Ketterät menetelmät eivät sisällä sääntökirjaa (vaikka jotkut ovat sellaista yrittäneetkin laatia)". Hän korostaa sääntöjen orjallisen noudattamisen sijaan ketterien menetelmien perusperiaatteiden kunnioittamista, josta olen samaa mieltä. Valitettavasti tuo kaunis ajatus voi aiheuttaa ongelmia, mikäli joku näkee sen tekosyynä luistaa Scrumin perusasioista ja samalla usein myös ketteristä perusperiaatteista. Tällöin helposti rampauttaa pitkään kehitellyn ja toimivaksi todetun menetelmän.
Myös Extreme Programming menetelmän kehittäjä Kent Beck on samoilla linjoilla sanoessaan, että "käyttämällä 80% prosessista saat 20% hyödyistä". Prosessi on joukko toisiaan tukevia käytäntöjä ja kun jotain ottaa pois, alkaa muutkin osat heikentyä.
Laadin siis eräänlaisen Scrum-sääntökirjan asioista, jotka minusta ovat oleellinen ja merkittävä osa Scrum menetelmää. Lista asioista, jotka mielestäni muodostavat Scrumin ytimen ja joista lipsuminen tekee menetelmästä jotain muuta kuin Scrumin. Haluan vielä korostaa, että kyseessä on oma näkemykseni ja tämänkin jälkeen sanoisin ettei mitään sääntökirjaa ole olemassakaan.
Roolit
Tiimi
- Tiimi päättää itse kuinka suorittavat työnsä
- Tiimillä on tarvittava osaaminen ja välineet toteuttaa Sprintin tehtävät
- Arvioi itse työmääränsä jokaiseen sprinttiin, ilman ulkopuolisten painostusta
- EI SCRUM: Tiimi usein riippuvainen muista. Ei itsenäisyyttä. Ei saa keskittyä sprinttiin.
Scrum Master
- Tasa-arvoinen tiimin jäsen ilman käskyvaltaa
- Ymmärtää Scrum-menetelmän läpikotaisin ja huolehtii sen mukaisesta toiminnasta
- Huolehtii tiimin häiriötekijöistä maksimoiden tiimin tuottavuuden
- EI SCRUM: Komentaa tiimiä. Puskee arvioita tiimille. Ei tiimiläisten luottamusta.
Product Owner
- Tiimin ulkopuolinen ilman käskyvaltaa tiimiin
- Huolehtii tuotteen backlogista ja prioriteeteistä
- Ainoa työtehtävien lähde tiimille
- Ymmärtämään asiakkaan tarpeet ja jokaisen Product Backlog itemin tarkoituksen
- EI SCRUM: Komentaa tiimiä. Painostaa tiimin työmääräarvioita. Sekaantuu tiimin työhön.
Prosessit
Sprint planning
- Tiimi arvioi työmääränsä ja sitoutuu sprinttiin, ei kukaan muu
- Kukaan muu ei painosta tiimiä ottamaan liikaa työtä
- EI SCRUM: Tiimi ei itse arvioi tai sitoudu suunnitelmaan. Ulkopuolinen painostaa arvioissa.
Daily Scrum
- Tiimin synkronointi
- Huolehtii, että tiimin osaaminen hyödynnetään ja ongelmat tuodaan esille
- EI SCRUM: Kestää liian kauan. Ylimääräistä sisältöä. Tiimin ulkopuolisille tarkoitettu.
Sprint review
- Käydään läpi tehdyt asiat ja opitaan samalla arvioimaan paremmin
- Mahdollisuus demonstroida uusia ominaisuuksia, myös asiakkaille
- EI SCRUM: Ei yritetä kehittää arviointia
Sprint Retrospective
- Kehitetään prosessia. Koko tiimillä mahdollisuus osallistua kehittämiseen.
- EI SCRUM: Ei mahdollisuutta kehittää prosessia
Tuotokset (Artifaktit)
Product Backlog
- Priorisoitu tehtävälista, joka yleensä asiakkaan ymmärtämällä tasolla ilman teknisiä yksityiskohtia
- EI SCRUM: Priorisoinnit pielessä. Itemit liian isoja eikä mahdu sprinttiin. Sisältö epäselvää.
Sprint Backlog
- Tiimin rakentama tekninen ja konkreettinen tehtävälista työmääräarvioineen
- Rakennettu Product Backlogista priorisoinnin mukaisesti
- EI SCRUM: Ei tiimin arvioima tai hyväksymä. Ei selkeitä konkreettisia tehtäviä.
Product increment
- Tämä on itsestäänselvyys, joka oli pakko mainita :)
Loppusanat
Mikäli jotkut listaamistani asioista vaikuttavat turhilta, kannattaa miettiä tarkkaan niiden tarkoitusta ja poistamisen mahdollisia oireita. Esimerkiksi usein kuulen kuinka “Daily Scrum on turha, sillä työskentelemme tiiviisti samassa huoneessa ja kommunikoimme jatkuvasti”. Mutta onko varma, että ilman Dailyä se huoneen hiljaisinkin kertoo ongelmistaan? Onko varmaa, että se huoneen kovin koodaaja, joka haluaisi keskittyä vain omaan työhönsä, hyödyntää koko osaamisensa tiimin hyväksi? Nopeasti hoidettu Daily Scrum on tehokas tapa varmistaa tiedon siirtyminen tiimin sisällä ja tehostaa koko tiimin työskentelyä.
On myös paljon asioita jotka eivät ole osa Scrumia, vaikka ne saatetaan Scrum-koulutuksissa opettaa. Esimerkiksi Planning poker, Story-pisteet, Definition of Done, Scrum-seinä, Burndown chart, Velocity, Kanban, TDD, DevOps, CI/CD, eivät ole osa Scrum menetelmää, mutta niitä kyllä voidaan käyttää Scrumin lisätyökaluina. Ehdottomasti erilaisia lisätyökaluja kannattaa kokeilla ja niiden käyttö ei tietenkään “riko” Scrumia, vaan ovat usein hyvä lisä työskentelytapoihin.
Yleensä koulutuksissani olen tiivistänyt Scrum-ytimen 3×3 listaan, eli 3 roolia, 3 tuotosta ja 3 prosessia. Nyt listassa on 4 prosessia, mutta olen yhdistänyt Sprint Review ja Retrospective tapahtumat, sillä yleensä ne pidetään peräkkäin yhtenä palaverina. Todellinen syy (pakko tunnustaa) yhdistämiselle on, että tuollainen 3x3 näyttää koulutusmateriaaleissa paremmalta ja on helpompi muistaa, kuin 3-4-3 jaottelu.
Onko sinusta jokin asia tuolla turhaan ja sen voisi mielestäsi poistaa? Tai puuttuuko sieltä jotain oleellista? Mikäli sinulla on mielipiteitä “sääntökirjastani”, mielellään keskustelen aiheesta lisää. Aina tekee hyvää, kun joku haastaa ja kyseenalaistaa.
5.11.2019
