Kuulostaa ristiriitaiselta luetella Scrumin sääntöjä ja samalla kehua Scrumin antavan tiimiläisille vapauden tehdä työt parhaaksi näkemällään tavalla. Jos kerran tiimi saa itse päättää työskentelytapansa, niin miksi on pakollisia palavereita? Eikö pelkkä backlog riitä? Voisiko koodaaja voisi olla tehokkain koodatessaan vain mahdollisimman paljon välittämättä mistään tai kenestäkään muusta? Onko täydellinen vapaus kuitenkaan kokonaisuuden kannalta järkevää?
TAGS:
Onko töissä vapautta
Vapautta miettiessä täytyy muistaa, että ollaan töissä. Tehdään mitä työnantaja (ja asiakas) haluaa, jotta saadaan palkkaa. Siinäpä se vapaus tehdä mitä haluaa oikeastaan katosi. Tuotekehitysprojekteissa oman suorituksen maksimointia tärkeämpää on koko tiimin yhteinen tehokkuus. Tehokkuuteen vaikuttaa lisäksi tekemisen suuntaaminen oikeisiin asioihin, asiakkaan kuuntelu ja muutoksiaan reagointi. Myös jonkinlainen budjetti ja aikataulu on yleensä oltava, mikä tavallaan rajoittaa tekemistä. Tarvitaan siis tiimityöskentelyä, mahdollisuuksia saada asiakaspalautetta, reagoida mahdollisiin muutoksiin, työmäärän seurantaa ja jotain arviota tulevasta työmäärästä. Prosessi ei siis voi olla mikään bunkkerissa tapahtuva koodauskerho, joka ilmoittaa valmiista tuotteesta ikkunasta tuprahtavalla valkoisella savulla.
Scrum-menetelmä pyrkii antamaan tiimille mahdollisimman paljon vapautta, huomioiden myös muut osapuolet. On pakollisia prosesseja, jotka vievät oikein pidettynä vain vähän aikaa. On huomioitu tiimityöskentely, asiakkaan palautteet ja muutoksiin reagointi. Oikeastaan vain työmäärän arviointiin ei Scrum ota kantaa, mutta siitä voisin kirjoittaa joskus lisää.
Tiimi ja asiakas
Vapautta rajoittamassa on siis oikeastaan tiimi ja tiimin asiakas, onko se sitten ulkoinen asiakas vai yrityksen oma projekti. Scrum-prosessi on tehty nimenomaan tiimiä ja asiakasta ajatellen.
Daily Scrumissa tiimin hiljaisemmatkin saavat suunvuoron ja ääneen sanottuihin ongelmiin voi löytyä yllättävältäkin taholta apuja, edistäen tuotekehitystä. Sprintin suunnittelussa sekä tiimi että asiakas voivat yhdessä osallistua. Reviewissä saadaan arvokasta palautetta asiakkaalta ja Retrospektiivissä koko tiimi voi osallistua kehittämään prosessia.
Työskentelytapoihinkaan ei ole täyttä vapautta, sillä jos yksi tiimissä tekee täysin omalla tavallaan, se ei välttämättä aja kokonaisuuden etua. Toisaalta jos tuosta omasta tavasta on tiimille enemmän hyötyä kuin haittaa, niin sitten sitä kannattaa harkita. Eli oikeastaan vapaus on tiimillä, ei niinkään yksilöllä tiimissä. Ja lopulta tarkoitus on maksimoida tuotekehityksen tehokkuus.
Tehokkuuden maksimointi ei tarkoita "puristetaan viimeisetkin veripisarat koodaajista" ajattelua, vaan on mietitty oikeaa tapaa motivoida tuotekehittäjiä pitkällä aikavälillä. Scrumin kehittäjät ovat pyrkineet nimenomaan ajattelemaan tuotekehityksen parasta, ei mitään johtajien himmeliä.
Scrumin antama vapaus
Mitä sitten on vapaata tehdä Scrumin asettamien raamien sisällä? Tiimillä on vapaus arvioida sprintin työmäärä ja mahdollisuus päättää työtavoistaan sprintin sisällä. Esimerkiksi tiimi voisi päättä tehdä tietyt osat parikoodauksena, erilaisten osaamissiilojen poistamiseksi. Omia testausmenetelmiä voisi kehittää, koodikatselmointia, valita omat työkalunsa, jne. Eli oikeastaan kaikki mitä tapahtuu Sprinttien sisällä, lyhyiden Daily Scrumien lisäksi.
Ajattelumallin pitäisi olla sellainen, että tiimiin luotettaisiin ja annettaisiin valita oma tapa tehdä tuotekehitystä. Vastuu ja luottamus tuovat motivaatiota, joka on erittäin tärkeää työhyvinvoinnin ja tehokkuuden kannalta. Tiimin pitäisi olla kuin oma itsenäinen yritys, joka ymmärtää olevansa itse vastuussa menestyksestään. Jos koodia ei synny, yritys ei toimi ja se joutuu lopettamaan.
Pakolliset palaverit
Kyllä, pakolliset palaverit vain pitää sietää. Itse asiassa jokaisen kannattaisi miettiä, miten voisi palavereissa auttaa tiimiä paremmaksi omalla osaamisellaan ja ehkä huomaisi palaverien olevan oikeasti hyödyllisiä. Oma asenne merkitsee näissä yllättävän paljon. Mikäli tuntuu, että sinulla ei ole mitään annettavaa, voit kuunnella ja yrittää oppia. Jos sekään ei kiinnosta, kannattaa miettiä haluatko olla tiimissä mukana ollenkaan.
Näiden pakollisten palaverien ansiosta kuitenkin Scrum Master ja Product Owner saavat melkeinpä kaiken tarvittavan, jotta tiimi voi keskittyä muun ajan työhönsä. Samalla tiimin sisällä jokainen saa äänensä kuuluviin. Daily Scrum, jota yleensä pidetään suurimpana "vapauden riistäjänä", vie ajallisesti suunnilleen saman verran kuin yksi kahvikupillisen juominen. Ei pitäisi olla liikaa vaadittu.
Tarkemmista Scrumin asettamista raameista kirjoitin aiemmin blogiin: https://eeku.fi/blog/scrumin-saantokirja/
Loppusanat
Tiimillä on tietyt velvollisuudet, jotka pitää hoitaa, jotta kokonaisuus toimii. Yksilöiden täytyy toimia osana tiimiä ja saada tiiminä aikaan mahdollisimman paljon. Nämä asiat Scrum pyrkii ratkaisemaan omalla prosessillaan, tarjoten sen sisällä myös motivaatiota kasvattavaa vapautta ja vastuuta.
Jos tuntuu, että Scrum tiimissä teillä ei ole vapautta, niin kannattaa miettiä asiota, jotka mielestäsi vapauttasi rajoittaa. Toimiiko teillä Scrum oikein? OLetteko itse luoneet itsellenne rajoituksia? Oletko ymmärtänyt tiimin velvollisuudet? Näistä asioista kannattaa keskustella Scrum Masterin kanssa tai ottaa puheeksi yleisesti vaikka retrospektiivissä. Usein tiimi ei itse ymmärrä käyttää hyväksi vapauttaan prosessin sisällä, vaan on yhä aiemman työskentelytavan vankina.
25.1.2021
