de de de en es es de de de de en it de tr cv en ru es es de de de de en it de de tr cv en ru de de de de de de fr de de de de en de de en en de en de en pl de de de en de de de sv fa it en de de de de de de de
Agi­le Metho­den und Frame­works gibt es vie­le, aber was ist die Essenz von Agi­li­tät? Und wie lässt sie sich beschrei­ben ohne auf die Ter­mi­no­lo­gie von Scrum & Co. zurück­zu­grei­fen? Das Mani­fest für agi­le Soft­ware­ent­wick­lung wirkt auf den ers­ten Blick wie ein guter Start­punkt zur Beant­wor­tung die­ser Fra­gen. Jedoch sind The­sen wie „Reagie­ren auf Ver­än­de­rung mehr als das Befol­gen eines Plans“ eher Absichts­er­klä­run­gen und nicht wirk­lich hand­lungs­lei­tend. Die Prin­zi­pi­en hin­ter dem Mani­fest sind da schon deut­lich kon­kre­ter. Dort heißt es bei­spiels­wei­se: „Lie­fe­re funk­tio­nie­ren­de Soft­ware regel­mä­ßig inner­halb weni­ger Wochen oder Mona­te und bevor­zu­ge dabei die kür­ze­re Zeit­span­ne.“ Ein zusam­men­hän­gen­des Bild, wor­um es der Agi­li­tät im Kern geht, lie­fern die­se Prin­zi­pi­en aber in ihrer Viel­falt der über­deck­ten Aspek­te lei­der auch nicht.
Was ist also nun als wesent­lich anzu­se­hen für die Agi­li­tät? Ers­tens und am auf­fäl­ligs­ten, weil als Gegen­po­si­ti­on zu dem ver­brei­te­ten plan­ge­trie­be­nen ana­ly­ti­schen Vor­ge­hen ist das sicher­lich die Empi­rie: Agi­les Vor­ge­hen bedeu­tet empi­ri­sches Erkun­den von Lösun­gen und Märk­ten in einem kom­ple­xen Umfeld. Zwei­tens setzt Agi­li­tät kon­se­quent auf Empower­ment der Teams und damit ins­be­son­de­re in bes­ter Tra­di­ti­on des Lean-Manage­ments dar­auf, die eige­ne Arbeits­wei­se und die Arbeits­pro­zes­se zu hin­ter­fra­gen und zu ver­bes­sern. Und drit­tens bedeu­tet Agi­li­tät Owners­hip und Team­work. Agi­li­tät ist die Abkehr von klein­tei­li­gem Exper­ten­tum, das zur Bear­bei­tung eines jeg­li­chen nicht-tri­via­len Pro­dukts vie­le Über­ga­ben nach sich zieht, hin zu klei­nen, schlag­kräf­ti­gen, cross-funk­tio­na­len Teams, die gemein­sam Ver­ant­wor­tung für ihr Pro­dukt über­neh­men und es mit Lie­fe­run­gen in kur­zen Abstän­den weiterentwickeln.
Empi­rie stammt vom grie­chi­schen euπeιpίa (empei­ría), das in etwa mit Erfah­rung oder Erfah­rungs­wis­sen über­setzt wer­den kann. Empi­rie ist der Ver­such, Zusam­men­hän­ge durch das sys­te­ma­ti­sche Sam­meln von Erfah­run­gen zu ver­ste­hen. Dazu wer­den theo­re­ti­sche Annah­men über die Welt als Hypo­the­sen for­mu­liert und durch geeig­ne­te Expe­ri­men­te über­prüft oder wider­legt. Im Gegen­satz zur Ana­ly­tik (vom griech. ἀvaλύeιv ana­ly­ein ‚auf­lö­sen‘) wird das unter­such­te Sys­tem nicht in Bestand­tei­le zer­legt, son­dern die Wirk­zu­sam­men­hän­ge im Gro­ßen betrach­tet. Das mensch­li­che Gehirn etwa lässt sich ana­ly­tisch unter­su­chen und dadurch als kom­pli­zier­tes und dyna­mi­sches Geflecht von Neu­ro­nen begrei­fen, Denk­mus­ter las­sen sich aber nur empi­risch durch geeig­ne­te psy­cho­lo­gi­sche Expe­ri­men­te nachweisen.
Agi­li­tät beginnt damit, sich die Unsi­cher­heit und Kom­ple­xi­tät des Vor­ha­bens und sei­ner Umwelt ehr­lich ein­zu­ge­ste­hen. Die logi­sche Ant­wort auf die­se Kom­ple­xi­tät ist es dann, eher empi­risch und weni­ger ana­ly­tisch und plan­ge­trie­ben zu arbei­ten. Jede Prio­ri­sie­rung, jedes Sprint-Goal und jedes Sprint-Plan­ning ist damit eigent­lich eine Hypo­the­se über einen erwar­te­ten Kun­den­nut­zen. Gute Hypo­the­sen wer­den sich bewäh­ren und schlech­te wer­den von der Rea­li­tät wider­legt. Dar­um bedeu­tet Agi­li­tät auch mehr als die blo­ße Lie­fe­rung von immer neu­en Inkre­men­ten des Pro­dukts. Ganz wesent­lich ist die sys­te­ma­ti­sche Erfas­sung von Daten über die Wir­kung der Lie­fe­rung, um die damit ver­bun­de­ne Hypo­the­se zu bestä­ti­gen oder zu widerlegen.
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
Agi­li­tät grün­det auf dem Lean Manage­ment und kann als Anwen­dung der fünf Lean Prin­zi­pi­en auf Soft­ware­ent­wick­lung ver­stan­den wer­den. Der Fokus von Agi­li­tät liegt auf der schnel­len Lie­fe­rung von Kun­den­wert durch funk­tio­nie­ren­de Soft­ware. Und der opti­ma­le Fluss dafür ent­steht im inter­dis­zi­pli­nä­ren selbst­or­ga­ni­sier­ten Team, das den kom­plet­ten Wert­strom von der Idee bis zum Betrieb der Soft­ware abdeckt.
Im Lean Manage­ment sind alle Mit­ar­bei­ter auf­ge­for­dert und ermäch­tigt, kon­ti­nu­ier­lich Abläu­fe zu hin­ter­fra­gen und an deren Ver­bes­se­rung zu arbei­ten. Die­ses Empower­ment der „ein­fa­chen“ Arbei­ter und damit der Fokus auf den Fak­tor Mensch stellt eine deut­li­che Abkehr von der vor­mals domi­nan­ten tay­lo­ris­ti­schen Denk­wei­se dar: Die­je­ni­gen, die im Pro­zess arbei­ten und nicht mehr ihre Mana­ger, ken­nen die Abläu­fe am bes­ten und sind folg­lich die­je­ni­gen, die die­se am bes­ten opti­mie­ren kön­nen. Taiichi Ōno, der Erfin­der des Toyo­ta-Pro­duk­ti­ons­sys­tems drückt es so aus:
Stan­dards should not be for­ced down from abo­ve but rather set by the pro­duc­tion workers themselves.
Die­ses Empower­ment steht im Zen­trum der Agi­li­tät. Nicht der genia­le Mana­ger, son­dern selbst­or­ga­ni­sie­ren­de Teams schaf­fen die bes­ten Archi­tek­tu­ren, Anfor­de­run­gen und Ent­wür­fe, wie es in den Prin­zi­pi­en hin­ter dem Mani­fest für agi­le Soft­ware­ent­wick­lung unmiss­ver­ständ­lich for­mu­liert ist. Und in bes­ter Tra­di­ti­on des Lean Manage­ment sind die­se Teams auch für die kon­ti­nu­ier­li­che Ver­bes­se­rung ihrer Abläu­fe ver­ant­wort­lich: „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.“
Viel zu oft wer­den agi­le Metho­den und ins­be­son­de­re Scrum auf die Opti­mie­rung von Arbeits­ab­läu­fen redu­ziert. Die­ses Miss­ver­ständ­nis grün­det auf der Annah­me, dass man nur die vor­han­de­ne Arbeit unter ansons­ten unver­än­der­ten Rah­men­be­din­gun­gen anders und bes­ser orga­ni­sie­ren müs­se, um dann schnel­ler oder anpas­sungs­fä­hi­ger zu wer­den. Die­ser mecha­nis­ti­sche Blick auf Agi­li­tät igno­riert aber völ­lig, dass es eigent­lich um Team­work und Owners­hip geht. Metho­den wie Scrum geben dem Team nur den Rah­men und die Struk­tur, um gemein­sam kon­ti­nu­ier­lich und fokus­siert nicht nur an belie­bi­gen Auf­ga­ben, son­dern an sei­nem Pro­dukt zu arbeiten.
A team is not a group of peop­le that work tog­e­ther. A team is a group of peop­le that trust each other.
Agi­li­tät heißt, gemein­sam durch Expe­ri­men­te zu ler­nen und dar­aus sowohl die Zusam­men­ar­beit als auch das Pro­dukt kon­ti­nu­ier­lich zu ver­bes­sern. Die­ses Ler­nen funk­tio­niert aber nur, wenn die betei­lig­ten Men­schen wirk­lich als Team agie­ren kön­nen und nicht nur zeit­wei­se und antei­lig zufäl­lig in die­ser Woche mal zusam­men­ar­bei­ten, weil ihre Exper­ti­se gera­de in die­ser Pha­se des Pro­jekts gefragt ist. Der Agi­li­tät ist damit in gewis­ser Wei­se die Owners­hip im Sin­ne der Zuge­hö­rig­keit zu einem Team und der gemein­sa­men Ver­ant­wor­tung für ein Pro­dukt wich­ti­ger als das Exper­ten­tum, das in den meis­ten funk­tio­nal fein-zise­lier­ten Orga­ni­sa­tio­nen Hoch­kul­tur fei­ert. Selbst­ver­ständ­lich wird das Exper­ten­wis­sen benö­tigt, aber eben nicht in dem Exper­ten­si­lo, son­dern dort, wo es zur Wert­schöp­fung ange­wen­det wird.