Kaikki Scrum-tiimit eivät ole ketteriä: Fake Agile

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?

Leider schaffen es Organisationen in der Praxis immer wieder Scrum einzuführen und die Teams dadurch alles andere als agil zu machen. Tästä käytetään usein nimitystä “Zombie Scrum”.

Was ist “Fake Agile”?

“Fake Agile” tarkoittaa tiimejä, jotka virallisesti käyttävät ketteriä viitekehyksiä ja menetelmiä, mutta ilman todellisia oppimiskierroksia asiakkaiden kanssa. Fake Agile tarkoittaa siis sitä, että a) iteraatioita ja inkrementtejä ei toimiteta asiakkaille ollenkaan tai b) inkrementistä saatavaa suoraa asiakaspalautetta ei käytetä lyhyen aikavälin priorisointiin.

Mitkä ovat väärennetyn Agile:n syyt?

Gründe für “Fake Agile” gibt es viele. Die häufigsten Ursachen in der Praxis für Fake Agile sind meiner Erfahrung nach folgende:

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

“When a measure becomes a target, it ceases to be a good measure.”

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.

Wie wäre es also, wenn wir unsere Arbeitsweisen auch komplett mit Regeln festlegen - wäre das nicht toll? Nein, wäre es nicht.

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