Vuonna 2010 internetin keskusteluryhmissä esitettiin 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 saisi muuttaa ja toisten mielestä itselle mukava toimintamalli on tärkeämpää kuin viitekehyksen tarkka noudattaminen.
Huomaan lukeutuvani käytännöllisesti ajatteleviin. Uskon, että aluksi kannattaa seurata tarkemmin ohjeita, jolloin toivottavasti välttää pahimmat väärinymmärrykset. Kun kokemuksen kautta ymmärtää Scrumin elementtien yhteyden lopputuloksiin, voi tarvittaessa muokata yksittäisiä elementtejä ja ottaa vastuun lopputuloksesta.
Useimmilla organisaatioilla riittää haasteita tiimityön perusteissa, kuten tuotteen tai palvelun rajaamisessa, aidon tiimin luomisessa ja yhteistyössä, työn pilkkomisessa sekä järjestämisessä tuoteomistajan kanssa.
Törmättyäni usein toistuviin perustason haasteisiin olen päätynyt seuraaviin minimivaatimuksiin ketterälle työskentelylle:
Toimita arvoa mahdollisimman nopeasti ja säännöllisesti (ts. aikarajatut iteraatiot)
Toimita käyttäjille arvokkaimmat asiat ensin (ts. optimoi tiimin tuottama arvo)
Kehitä toimintaa jokaisessa iteraatiossa (ts. tiimin retrospektiivit)
Nämä minimivaatimukset muodostavat mielestäni ketteryyden ytimen, joka antaa pohjan ketterien menetelmien soveltamiselle johtamisessa ja esimerkiksi valmistavassa teollisuudessa sekä muilla aloilla, jotka vaativat ohjelmistokehityksestä poikkeavaa ajattelua.
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.
- Ken Schwaber