Agilität, Empirie und Falsifikation

Agili­tät macht nur Sinn im Kon­text von Unsi­cher­heit. Wer genau weiß, was der Kun­de will oder was der Markt braucht, muss nicht agil vor­ge­hen und kann sich Um- und Irr­we­ge spa­ren. Nur wer weiß das schon so genau? Und selbst wenn wir es hier und heu­te zu wis­sen glau­ben, kann es zum Zeit­punkt, wenn das Pro­dukt fer­tig sein wird doch schon wie­der ganz anders sein. Agi­li­tät macht also viel Sinn in unse­rer heu­ti­gen Welt, für die Cha­rak­te­ri­sie­rung VUCA (für Vola­ti­li­ty, Uncer­tain­ty, Com­ple­xi­ty und Ambi­gui­ty) immer mehr zutrifft. „Reagie­ren auf Ver­än­de­rung mehr als das Befol­gen eines Plans“, heißt es im Agi­len Mani­fest. Aber wie reagiert man eigent­lich auf Ver­än­de­rung und wie erkennt man eigent­lich, dass man falsch abge­bo­gen ist?

Genau dar­um hat Agi­li­tät sehr viel mit Empi­rie zu tun. Letzt­lich stellt man im agi­len Vor­ge­hen stän­dig Hypo­the­sen auf und ver­sucht die­se mög­lichst gut durch Mes­sun­gen und Feed­back­schlei­fen zu bestä­ti­gen oder zu wider­le­gen. Neben die­ser Empi­rie auf inhalt­li­cher Ebe­ne, ist Agi­li­tät zusätz­lich auf metho­di­scher Ebe­ne ein empi­ri­scher Pro­zess. „In regel­mä­ßi­gen Abstän­den reflek­tiert das Team, wie es effek­ti­ver wer­den kann und passt sein Ver­hal­ten ent­spre­chend an.“ ist ein Prin­zip hin­ter dem agi­len Mani­fest. Letzt­lich ist zum Bei­spiel im Scrum jeder Sprint eine Hypo­the­se zur Zusam­men­ar­beit, die in der Retro­spek­ti­ve am Ende bestä­tigt oder wider­legt wird.

Empi­rie stammt vom grie­chi­schen εμπειρία (empei­ría), was soviel heißt wie Erfah­rung oder Erfah­rungs­wis­sen. Gemeint ist damit das metho­disch-sys­te­ma­ti­sche Sam­meln von Daten mit dem Zweck theo­re­ti­sche Annah­men über die Welt zu über­prü­fen oder zu wider­le­gen. Agi­li­tät beginnt damit, sich die Unsi­cher­heit des Vor­ha­bens und der Umwelt ehr­lich ein­zu­ge­ste­hen. Die logi­sche Fol­ge aus die­ser Erkennt­nis der Unsi­cher­heit ist mit Hypo­the­sen zu arbei­ten. Jede Prio­ri­sie­rung, jedes Sprint-Plan­ning ist eine Hypo­the­se über einen ver­spro­che­nen Kun­den­nut­zen. Und gute Hypo­the­sen müs­sen sich bewäh­ren. Dar­um erfas­sen agi­le Teams so vie­le Daten über sich selbst und ihre Pro­duk­ti­vi­tät genau­so wie über das Pro­dukt und die Nutzer.

Ein empi­risch-wis­sen­schaft­li­ches Sys­tem muss an der Erfah­rung schei­tern können.
Karl Pop­per, Logik der For­schung 17

Die meis­ten Annah­men über Pro­duk­te und Kun­den kön­nen prin­zi­pi­ell nie kom­plett veri­fi­ziert wer­den im Sin­ne einer All­ge­mein­gül­tig­keit. Inso­fern sind alle unse­re Hypo­the­sen vor­läu­fig und nur noch nicht wider­legt. Das Bes­se­re ist der Feind des Guten. Ziel des Pro­dukt­teams muss es des­halb sein, die­ses Bes­se­re schnel­ler zu fin­den als die Kon­kur­renz. Und die­ses Bes­se­re fin­det man nur, wenn man kon­se­quent an der Fal­si­fi­zie­rung und nicht so sehr an der Bestä­ti­gung eige­nen bis­he­ri­gen Hypo­the­sen arbei­tet. Dar­um ist es eine gute Prak­tik, wenn agi­le Teams neue Fea­tures im Stil eines A/B‑Tests an einem Teil der Nut­zer kri­tisch ausprobieren.



Share This Post

Schreibe einen Kommentar