Fake Agile: Onko jokainen Scrum-tiimi ketterä?
Ei, valitettavasti kaikki Scrum-tiimit eivät ole ketteriä.
Minäpä selitän: Scrum-tiimi määritellään työskentelemällä Scrum-kehyksen mukaisesti: Sillä on siis sprintit, tietyt roolit ja rituaalit. Ja koska Scrum-kehyksen tarkoituksena on auttaa tiimejä työskentelemään ketterästi, Scrumin pitäisi automaattisesti tehdä jokaisesta tiimistä ketterä, eikö niin?
Valitettavasti käytännössä organisaatiot onnistuvat aina ottamaan Scrumin käyttöön ja tekemään tiimeistään kaikkea muuta kuin ketteriä. Tätä kutsutaan usein "Zombie Scrumiksi".
Mikä on "väärennetty Agile"?
"Fake Agile" tarkoittaa tiimejä, jotka työskentelevät virallisesti ketterien kehysten ja menetelmien parissa ilman, että heillä on todellisia oppimissilmukoita asiakkaiden kanssa. Fake Agile tarkoittaa siis sitä, että joko a) inkrementtejä ei toimiteta iteratiivisesti asiakkaille tai b) asiakaspalautetta inkrementistä ei käytetä lyhyen aikavälin priorisoinnissa.
Mitkä ovat väärennetyn Agile:n syyt?
Väärennettyyn Agile:hen on monia syitä. Kokemukseni mukaan yleisimmät syyt väärennettyyn Agile:hen käytännössä ovat seuraavat:
Väärennös Agile Syy #1: Ei asiakaspalautetta
Jos ketterä tiimi ei saa suoraa palautetta käyttäjiltä, se ei voi toimia ketterästi. Käytännössä johto muotoilee usein asiakaspyynnöt ja välittää ne tiimeille tuoteomistajien kautta – Todelliset palautekierrokset asiakkaiden kanssa kuihtuvat pois tai niitä ei edes ole olemassa.
Ketterä tiimi tarvitsee suoraa asiakaskontaktia!
Väärennös Agile Syy #2: Keskity nopeuteen ja tarinapisteisiin
Puh, tarvitseeko meidän sanoa paljon enemmän tarinapisteistä vuonna 2025? Luulen, että meillä kaikilla on tarpeeksi kokemusta siitä, miten paljon nopeuteen ja tarinapisteisiin keskittyminen haittaa asiakashyötyä.
Esimerkki: Mitä tapahtuu, jos toiminto on muodollisesti valmis ensimmäisen iteraation jälkeen, mutta ei vielä saavuta asiakashyötyä? Jos asiakashyöty on meille tärkeä, työskentelemme sen parissa, kunnes asiakashyöty todella saavutetaan. Loppujen lopuksi se voi viedä kolme iteraatiota, mutta ainakin asiakas on nyt tyytyväinen.
Mutta hetkinen, nyt esimieheni tulee yhtäkkiä nurkan takaa ja valittaa, että tiimini toteutti vähemmän tarinapisteitä viime sprintissä. Nopeuteni kannalta olisi siis ollut parempi, jos olisimme yksinkertaisesti jättäneet ei-arvokkaan toiminnon ja työskennelleet suoraan seuraavan toiminnon parissa, jotta olisimme voineet luoda enemmän tarinapisteitä.
Mitä roskaa, vai mitä? Jos toistamme tätä prosessia vielä muutaman kuukauden ajan, meillä on tuote, jossa on paljon toimintoja, joista on hyvin vähän hyötyä asiakkaille.
Ei siis liene yllätys, että sekä asiakkaat että kehitystiimit ovat tyytymättömiä ja lähtevät.
Yleisemmin sanottuna kyse on nyt hyvin tunnetusta laista: Goodhardtin laki
"Kun toimenpiteestä tulee tavoite, se lakkaa olemasta hyvä toimenpide."
Väärennös Agile Syy #3: Dogmin diktatuuri
Insinöörit rakastavat sitä, että kaikelle on olemassa kiinteät säännöt. Se tekee prosesseista suunniteltavia.
Miltä tuntuisi, jos voisimme myös määritellä työmenetelmämme täysin sääntöjen avulla – Eikö se olisi hienoa? Ei, ei olisi.
Pelkästään Scrumin ja sen monien sääntöjen ja ohjeiden ansiosta ketterä työskentely tuntuu jo nyt monista tiimeistä siltä, että ne työskentelevät jäykkien ohjeiden mukaan. Sen ei pitäisi olla sellaista. Älä siis pahenna tilannetta entisestään lisäämällä ketterään työskentelyyn lisää sääntöjä ja ohjeita.
Parhaimmissa tuntemissani ketterissä tiimeissä työskentely tuntuu inhimilliseltä, eloisalta, spontaanilta ja yhteistyökykyiseltä. Myönnettäköön, että useimmissa ketterissä tiimeissä se ei tunnu siltä.
Agile-tiimeillä on oltava ainakin riittävästi vapautta, jotta ne voivat tehdä joustavaa yhteistyötä asiakkaiden kanssa. Jos säännöt ja prosessit estävät tämän, sääntöjä ja prosesseja on tarkasteltava.
Tässä postauksessa olen jo kirjoittanut nimenomaan toimista, joita tarvitaan Scrum-tiimien suojaamiseksi Zombie Scrumilta: Korjaa Zombie Scrum
Väärennetty Agile on todellinen: miten suojautua?
Mikään ei suojaa sinua täysin väärältä ketteryydeltä. Mutta on yksi asia, joka voi suojata sinua mahdollisimman hyvin: Tehokas prosessi, jonka keskiössä on jatkuva parantaminen.
Tämä alkaa tietysti hyvistä retrospektiiveistä, joissa tiimin jäsenet voivat avoimesti jakaa näkemyksiään ja johtaa ja toteuttaa tehokkaasti parannustoimenpiteitä.
Niin kauan kuin tämä prosessi toimii, tiimisi ketteryys ei ole menetetty.
Jos haluat viedä ketterät retrospektiivit seuraavalle tasolle, suosittelen –naturally – Echometer-työkalua retrospektiivejä varten. Voit kokeilla sitä ilmaiseksi täällä: Kokeile Echometer