The Scrum Guide 2020 on edeltäjiään lyhyempi. Se pyrkii tekemään Scrumista kaikkeen monimutkaiseen työhön helpommin soveltuvan. Uuden version suomentamiseen osallistui lähes kaksikymmentä alan ammattilaista. Tässä tarinaa käännösprojektista sekä muutoksista versioiden 2017 ja 2020 välillä.
Scrum-opas 2020
Suomenkielisen Scrum-oppaan varsinainen verkkosivu on https://lekman.fi/scrumguide. Kansainväliset kieliversiot löytyvät osoitteesta https://scrumguides.org. Huomaa myös päivittynyt Scrum-sanasto (Scrum-oppaan lopussa) tai erikseen tässä.
Uuden version tavoitteena on tehdä Scrumista vähemmän ohjaileva sekä helpottaa Scrumin käyttöä kaikilla monimutkaisilla aloilla. Muutokset perustuvat tuttuun tapaan myös Scrumin käyttäjien palautteeseen. Scrumin alkuperäiset kehittäjät Jeff Sutherland, Ken Schwaber ja muut asiantuntijat keskustelivat muutoksista julkaisutapahtumassa 18.11.2020.
Käännösprojekti
Suomenkielisen käännöksen toimitti Lare Lekman apunaan kotimaiset Scrumin ammattilaiset Arto Eskelinen, Teemu Hyyryläinen, Tommi Kemppi, Maarit Laanti, Sami Lilja, Karoliina Luoto, Pentti Virtanen ja Lasse Ziegler.
Käännös toteutettiin noin 2,5h kestäneissä online-työpajoissa, joita pidettiin kahdeksan kappaletta. Kuhunkin työpajaan osallistui 3-9 kääntäjää mob programming -tekniikalla. Siinä yksi toimii kirjoittajana eli “kuskina” ja muut ovat “navigaattoreita”. Kuski keskittyy vain kirjoittamiseen ja navigaattorit taas antavat ohjeita ja keskustelevat vaihtoehdoista. Kun sovittu aika täyttyy (meillä 20 tai 30 minuuttia), tai kuski haluaa itse osallistua kääntämiseen, vaihdetaan kuskia. Mob programming -tekniikkaa käytettiin myös vuoden 2017 Scrum-oppaan kääntämisessä, tuolloin neuvotteluhuoneessa. Sama tekniikka toimii hyvin myös online-ympäristössä Zoomin ja Google Docsin avulla.
“Beta-käännöksen” kielenhuoltoon osallistuivat lisäksi Tuuli Pesonen, Erkki Tapola, Kari Ahokas, Sirkka Lekman, Pasi Savanainen, Eero Kurkela, Niko Salminen ja Vesa Purho. Heidän panoksensa oli hyvin arvokas, koska käännöstiimissä väistämättä sokeutuu työlleen. Kiitos kaikille! 🙂
Seitsemännen online-työpajan osallistujat 21.12.2020. Hymy on herkässä, kun käännöksen loppusuora häämöttää.
Alla on Scrum-oppaan 2020 suurempia ja pienempiä muutoksia.
1. Vähemmän ohjaileva
Vuosien varrella Scrum-opas alkoi muuttua ohjailevaan suuntaan. Uuden version tavoitteena oli palauttaa Scrum-viitekehys pienimpään riittävään muotoonsa poistamalla tai pehmentämällä ohjailevaa kielenkäyttöä. Ohjeistusta on karsittu esimerkiksi päivittäispalaverin toteutuksesta, tuotteen kehitysjonon meta-tiedoista, sprintin keskeyttämisestä sekä retrospektiivissa tunnistettujen prosessin parannusten käsittelystä sprintin kehitysjonossa.
Muutoksilla Scrumista halutaan minimalistinen, mutta monimutkaiseen työhön riittävä viitekehys. Samalla vähennetään väärinymmärrysten vaaraa. Esimerkiksi päivittäispalaverin kolme kysymystä johtivat valitettavan usein “robottimaiseen raportointiin”, vaikka ideana on tiimin vapaamuotoinen ja avoin keskustelu mahdollisimman hyvän työpäivän aikaansaamiseksi.
2. Vain yksi Scrum-tiimi ja vastuualueet roolien sijaan
Scrumin aikaisempien versioiden kolme roolia (tuoteomistaja, kehitystiimi ja Scrum Master) muodostivat yhdessä Scrum-tiimin. Tämä on kuitenkin saattanut aiheuttaa tiettyä “kahden tiimin” kitkaa tuoteomistajan ja kehittäjien välillä.
Uudessa Scrumissa on vain yksi tiimi, joka keskittyy yhteiseen tuotteen tavoitteeseen. Yhdistetyn tiimin nimi on Scrum-tiimi ja siihen kuuluu kolme vastuualuetta: Tuoteomistaja, kehittäjät ja Scrum Master.
Nimen muutoksen (kehitystiimi –> kehittäjät) lisäksi Scrumista poistuu roolit. Jatkossa roolit ovat vastuualueita (accountability), jotka Scrum-tiimin tulee jakaa ja hoitaa keskenään. Aluksi oudolta tuntuva vastuualueen käsite tukee sujuvaa yhteistyötä: Scrum-tiimin jäsenet eivät rajoita itseään käyntikortilla, vaan sillä mitä kukin osaa ja haluaa tehdä sekä miten vastuut jaetaan.
Suomen kielessä sanat vastuualue, asiasta vastaaminen ja vastuun ottaminen ovat arkikielessä lähes synonyymejä. Vastaavilla englanninkielisillä sanoilla taas on työelämässä täsmällisemmät merkitykset. Vastuualueesta (accountability) vastataan henkilökohtaisesti, kun taas vastuun ottaminen (responsibility) jostain asiasta voidaan esimerkiksi kertaluonteisesti tai pysyvämmin delegoida muille Scrum-tiimin jäsenille. Amerikkalaisessa ajattelussa (sekä uudessa Scrumissa) vastuu (responsibility) tulee aktiivisesti ottaa, eli sitä ei voi vain antaa ja olettaa tapahtuvaksi. Asian hoitamisesta kuitenkin lopulta vastaa kyseisen vastuualueen omistaja (accountable).
Scrumissa ei edelleenkään suositella tuoteomistajan ja Scrum Masterin vastuualueiden antamista samalle henkilölle (koska vastuualueilla on eri tavoitteet). Roolien muututtua vastuualueiksi tämä on kuitenkin suotavampaa, jos Scrum-tiimi kokee sen hyväksi.
Toim. huom. Scrum-sanaston päivityksen yhteydessä käännöstiimissä päätettiin kirjoittaa Scrum isolla alkukirjaimella, koska kyseessä on (vielä usein) vakiintumaton erisnimi. Iso alkukirjain on myös Scrumin kattojärjestöjen toive. Tämän vuoksi Scrum Master päädyttiin myös kirjoittamaan amerikkalaiseen tapaan isoin alkukirjaimin, jotta se on linjassa Scrumin kanssa.
3. Tuotteen tavoite on Scrumin uusi elementti
Uusi Scrum esittelee tuotteen tavoitteen. Se kuvaa tuotteen tulevaa tilaa, jonka saavuttamiseksi Scrum-tiimi voi tehdä suunnitelmia. Jokaisen sprintin tulee viedä tuotetta kohti tavoitetta.
Tuote on väline arvon tuottamiseksi. Sillä on selkeät rajat, tunnetut sidosryhmät sekä hyvin määritellyt käyttäjät tai asiakkaat. Tuote voi olla palvelu, fyysinen tuote tai jotain abstraktimpaa, kuten ohjelmisto.
Tuotteen visiota ei enää mainita Scrum-oppaassa. Käytännössä tuotteen visio on edelleen hyvä työkalu, joskin se on harvoin mitattavissa tai aikatauluun sidottu. Tuotteen tavoite pyrkii täyttämään tämän “aukon” varmistamalla, että kaikki ymmärtävät mihin hyödylliseen, mitattavissa olevaan, mahdollisimman täsmälliseen ja aikaan sidottuun päämäärään Scrum-tiimin työskentelyllä pyritään. Scrum-tiimin tulee saavuttaa (tai hylätä) yksi tuotteen tavoite kerrallaan. Keskittymällä yhteen tavoitteeseen kerrallaan nopeutetaan sen saavuttamista.
Tuotteen tavoite on Scrum-tiimin pitkän aikavälin tavoite, joka sisältyy tuotteen kehitysjonoon. Tuotteen kehitysjonon muut kohdat syntyvät vähitellen määrittelemään, mitä pitää tehdä, jotta tuotteen tavoite saavutetaan. Käytännössä tämä tarkoittaa sitä, että tuotteen kehitysjonossa olevan työn tulee edistää tuotteen tavoitetta. Lisäksi myös varsinainen tuotteen tavoite kirjataan tuotteen kehitysjonoon. Käytännön esimerkki tuotteen tavoitteesta voisi olla esim. “Hankitaan tuhat uutta rekisteröitynyttä käyttäjää joulukuun loppuun mennessä” tai “nostetaan loppukäyttäjien antamaa Net Promoter Scorea X:llä seuraavalla vuosineljänneksellä”.
Tuotteen tavoitteen tekemiseen voidaan hyödyntää tuotteen visiota, ja toisaalta tuotteen tavoite voi ohjata tuotteen vision luomista tai tarkentamista.
Käsitteitä suuremmasta pienempään:
(Tuotteen visio) – Ei kuulu varsinaisesti Scrumiin, mutta on edelleen hyödyllinen konsepti varsinkin tuoteomistajille.
Tuotteen kehitysjono – Tuotteen loputon toivelista, joka päivittyy tuotteen koko elinkaaren ajan. Siksi se on “suurempi” kuin yksittäinen tuotteen tavoite.
Tuotteen tavoite – Voi toteutua esim. useamman sprintin tai yhden tai useamman julkaisun kautta (yhdessä sprintissä voidaan toki myös tehdä useampia julkaisuja).
(Julkaisusuunnitelma) – Release Plan ei kuulu varsinaisesti Scrumiin, mutta on edelleen hyödyllinen tapa suunnitella useammasta sprintistä koostuvia tuotejulkaisuja (vetämällä Product Backlogiin poikkiviivoja Scrum-tiimin yhdessä hyväksi havaitsemiin kohtiin, jolla suunnitellaan julkaisuun tarvittavien sprinttien määrää ja alustavia sisältöjä).
Sprintin tavoite – Luodaan sprintin suunnittelussa kehittäjien, Scrum Masterin ja tuoteomistajan kesken. Sprintin tavoite antaa suuntaa sprintissä tehtävälle työlle, jonka tulisi edistää tuotteen tavoitetta.
Sprintin kehitysjono – Sprintin suunnittelussa kehittäjien tekemä suunnitelma, johon otetaan kehittäjien sopivaksi kokema määrä tuotteen kehitysjonon kohtia ja kirjataan niiden toteutukselle tekniset muistiinpanot (tehtävät). Sprintin kehitysjonoa päivitetään koko sprintin ajan, kun sprintissä toteutettavasta työstä opitaan lisää.
Päivittäispalaveri – Kehittäjät tarkastelevat etenemistään kohti sprintin tavoitetta ja päivittävät tarvittaessa sprintin kehitysjonoa. Näin työpäivästä saadaan mahdollisimman tuottava ja mukava.
4. Scrumin tuotosten uudet sidokset
Scrumin aiemmat versiot määrittelivät sprintin tavoitteen ja valmiin määritelmän ilman selkeää identiteettiä. Ne eivät olleet varsinaisia Scrumin tuotoksia (arfifact), mutta liittyivät tavallaan niihin. Uudessa versiossa jokainen Scrumin tuotos sisältää sidoksen, joiden tavoitteena on parantaa läpinäkyvyyttä ja keskittymistä tuotosten edistymiseen.
Tuotteen kehitysjono on sidottu tuotteen tavoitteeseen
Sprintin kehitysjonon on sidottu sprintin tavoitteeseen
Inkrementti (tuoteversio) on sidottu valmiin määritelmään.
5. Itseohjautuvuuden laajeneminen
Aiemmat Scrum-oppaat kuvasivat kehitystiimin itseohjautuvana (self-organizing) yksikkönä, joka saa (sovituissa rajoissa) valita kuka tiimiin kuuluu ja kuinka työtä tehdään. Uusi opas korostaa entistäkin enemmän tätä Scrum-tiimin itseohjautuvuutta. Koska Scrum-tiimiin kuuluu myös tuoteomistaja, tiimi voi itsenäisemmin päättää kuka tiimiin kuuluu, miten työtä tehdään ja myös mitä tehdään.
Käytännössä Scrum-tiimin itsehallinnon rajoista on (edelleen) fiksua sopia organisaation yhteisten pelisääntöjen ja etujen mukaisesti. Esim. Ei ole yleensä organisaation eikä sen asiakkaiden edun mukaista, että jokainen Scrum-tiimi valitsee itseään eniten miellyttävät teknologiat, ellei valinta kasvata asiakkaiden tyytyväisyyttä, organisaation liiketoimintaa ja tuoteperheen synergiaa.
Toim. huom. Englanninkielinen termi self-organizing on vaihtunut uudessa Scrum-oppaassa self-managementiksi. Suomenkielinen sana itseohjautuvuus on kuitenkin edelleen käytössä, koska se on oikeastaan lähempänä self-managementia kuin self-organizingia.
6. Sprintin suunnittelun kolme kysymystä
Sprintin suunnittelun aikaisempien aiheiden (“mitä” ja “kuinka”) lisäksi uusi opas korostaa kolmatta kysymystä “miksi”. Tämä liittyy sprintin tavoitteeseen, joka voi olla hankala määritellä, mutta joka kuitenkin antaa sprintin työlle tärkeän korkean tason tavoitteen.
7. Yksinkertaistettu kieliasu laajemmalle yleisölle
Uudessa versiossa on pyritty poistamaan päällekkäisyyksiä, monimutkaisia sanontoja sekä IT-alan sanastoa (esim. testaus, systeemi, design, vaatimus, jne). Uusi opas on varsinaiselta sisällöltään vain 13-sivuinen englanniksi ja suomeksi. Se on myös helpommin käytettävissä kaikilla monimutkaisilla aloilla, kuten esimerkiksi myyntiin, markkinointiin, rakennustekniikkaan, fyysisten laitteiden tai piirilevyjen kehittämiseen, HR:ään, jne.
8. Muita muutoksia
Yleisempi valmiin määritelmä. Aiemmissa Scrumin versioissa valmiin määritelmällä korostettiin tuotteen julkaisukelpoisuutta (“potentially releasable product increment”). Se on edelleen tärkeä tavoite, mutta sopii luontevimmin ohjelmistojen kehittämiseen. Uudessa versiossa sanaa potentiaalisesti julkaisukelpoinen ei enää mainita valmiin määritelmän yhteydessä. Tämä helpottaa valmiin määritelmän hyödyntämistä fyysisten tuotteiden kehittämiseen. Esim. Kerrostaloa tai piirilevyä kehitettäessä ei ole aina mahdollista tai mielekästä tuottaa jokaisessa sprintissä potentiaalisesti julkaisukelpoista inkrementtiä. Tärkeämpää on ottaa riittävän laadukas askel julkaisukelpoiseen suuntaan. Se on nyt mahdollista Scrumin pelisääntöjen puitteissa.
Ohjeet julkaisun ja sprintin jäljellä olevan työmäärän arvioimiseksi on poistettu. Scrum-oppaassa 2017 sanottiin: “Jäljellä oleva kokonaistyömäärä seuraavan tavoitteen saavuttamiseksi on milloin tahansa laskettavissa yhteen. Tuoteomistaja tarkistaa jäljellä olevan kokonaistyömäärän vähintään jokaisessa sprintin katselmoinnissa.” Sprintin osalta taas sanottiin: “Sprintin kehitysjonon jäljellä oleva kokonaistyömäärä on milloin tahansa laskettavissa yhteen. Kehitystiimi päivittää tätä kokonaistyömäärää vähintään jokaisessa päivittäispalaverissa arvioidakseen todennäköisyyttä sprintin tavoitteen saavuttamiselle.” Uudessa Scrum-oppaassa 2020 tyydytään toteamaan, että “etenemisen ennustamiseen on useita käytäntöjä, kuten edistymiskäyrät tai kertymäkuvaajat.” Valinnat etenemisnopeuden ja valmistumisajan arvioimisen toteuttamiseen jätetään siis avoimiksi.