Ketteryyden ydin
Julkaistu: 15.06.2010 Kategoria(t): Scrum, Tuotekehitys 3 kommenttia »Scrum Practitioners -ryhmässä esitetään mielenkiintoisia kysymyksiä, kuten “When your company implemented Scrum, did they keep it pure or did they adapt it to their culture?”
Otsikko on lähtökohtaisesti erikoinen, koska Scrum sovitetaan aina omaan kulttuuriin esimerkiksi valitsemalla sprintin eli kehitysjakson pituus. Tällöin organisaation kulttuuri myös sopeutuu Scrumiin.
Keskustelun kommentit jakautuvat karkeasti puristisiin ja pragmaattisiin. Toisten mielestä Scrumia ei tulisi muuttaa ja toisten mielestä hyvä lopputulos on tärkeämpää kuin mallin noudattaminen.
Huomaan lukeutuvani käytännöllisesti ajatteleviin. Uskon, että aluksi kannattaa soittaa nuoteista ja kuunnella opettajaa. Kun harjoituksen kautta oivaltaa pianon koskettimien yhteyden musiikkiin ja Scrumin elementtien yhteyden projektin lopputulokseen, voi tarvittaessa muokata yksittäisiä elementtejä ja ottaa vastuun lopputuloksesta.
Pari vuotta valmennettuani en muista montaa “puhdasta” Scrum-toteutusta, mutta monia kiitettäviä toteutuksia. Monilla organisaatioilla riittää haasteita Scrumin perusteissa, kuten sprintin rutiineissa, vaatimusten pilkkomisessa, priorisoinnissa tai kehitysnopeuden mittaamisessa vähintään sprintin lopussa.
Törmättyäni usein perustason haasteisiin olen karsinut ehdottomia vaatimuksiani ja päätynyt yhtäläisiin minimivaatimuksiin Scrum Practitioner -ryhmän Bruce Rennien kanssa:
- Toimita säännöllisesti jotain.
- Varmista, että toimitat korkeimman prioriteetin asiat (ts. sopeudut nopeasti muutoksiin).
- Pyri parempaan jokaisessa iteraatiossa/julkaisussa.
Nämä minimivaatimukset muodostavat mielestäni ketteryyden ytimen, joka antaa pohjan ketterien menetelmien soveltamiselle johtamisessa, julkishallinnossa ja valmistavassa teollisuudessa, jotka voivat vaatia ohjelmistokehityksestä poikkeavia ratkaisuja.
Lopuksi Scrumin isän Ken Schwaberin viisaat sanat:
Scrum is an organizational change process masquerading as a project management process wrapper. If you adopt pieces of Scrum, you don’t get this benefit… and you will likely stop adopting pieces once the going gets hard.
Samaa mieltä. Itse olen ehtinyt myös nähdä useita eri versioita Scrumista ja ollessani Scrum masterina yritän katsoa, että asiat menee mahdollisimman paljon taiteen sääntöjen mukaan, mutta joka projektissa käytännön toteutus on hieman erilainen. Uskon, että nämä asiat porautuu syvälle organisaatiokulttuuriin sekä tiimidynamiikkaan ja olisi naivia kuvitella, että sama paletti toimii kaikissa tilanteissa kaikille tiimeille. Toimiva tiimidynamiikka on vähän enemmän kuin “Mitä eilen, mitä tänään, onko ongelmia?”
Toisaalta, Scrumista karsiminen on huono juttu, eli jos esim. retrospektiivi jätetään pois koska “Ei se nyt oikeen sovi meille”. Mielenkiintoista muuten huomata, että aika monissa kyseisen keskustelun kommenteissa aloitetaan “To me, xxx means” -hengessä. Tämä kuvastanee sitä, että jokaisella on myös oma näkemys siitä mitä prosessista poikkeaminen tarkoittaa.
Kiitos Samuli jakamisesta ja terveiset Saksasta Ken Schwaberin kurssilta.
Kuten sanoit, jokainen projekti ja henkilöstö vaatii oman “Scrum-sovituksensa”. Monet organisaatiot hyödyntävät Scrumin lisäksi eXtreme Programmingia, Lean Developmentia ja Test-Driven Developmentia. Tällaista prosessia voi määritelmän mukaan kutsua Scrumiksi niin kauan, kun Scrumin kymmentä omaa peruselementtiä ei karsita tai oleellisesti muuteta. Jos taas Scrumin perusteita päädytään muokkaamaan voidaan puhua esim. Agile-prosessista tai ScrumMutta-sovelluksesta (eng. ScrumBut).
Ken Schwaberilla on hyviä varoittavia esimerkkejä Scrumin perusteiden muuttamisesta. Mainitsemasi retrospektiivin poisjättämisen lisäksi jotkut kehitystiimin jäsenet saattavat säännöllisesti myöhästellä päivän Scrumista, koska kuvittelevat sen olevan raportointia scrummasterille tai tuoteomistajalle, josta “saa” olla myöhässä. Todellisuudessahan kyse on kehitystiimin omasta keskinäisestä työn jakamisesta ja optimoinnista, jossa scrummasteria ei välttämättä edes tarvita.
Ketteryyteen siirryttäessä on hienoa ja merkittävää, kun pääsee artikkelissa kuvattuihin kolmeen minimivaatimukseen. Osaamisen karttuessa kannattaa kuitenkin kokeilla, paljonko tuottavuus paranee Scrumin toteuttamisella. Tätä tukee ketteryyden kolmas minimivaatimus eli säännöllinen parempaan pyrkiminen.
[...] ns. hyviä blogeja kuten esimerkiksi Jari Parantaisen Gurumarkkinointia tai vaikkapa Lare Ekmanin Ketteryys- blogia, niin tuntuu siltä että omat kirjoitukset on hiukan eri tasoisia. Olo on kuin papukaijalla, joka [...]