Agilität im Widerstreit zwischen Freiheit und Ordnung

Die Arbeit in Indus­trie­un­ter­neh­men ist geprägt von Pro­zes­sen, Rol­len und Stan­dards – zen­tral geplant, aus­ge­ar­bei­tet, doku­men­tiert, aus­ge­rollt, geschult und in ihrer Anwen­dung und Ein­hal­tung regel­mä­ßig über­prüft. Dafür gibt es dann ISO- und DIN-Stem­pel und alle sind glück­lich. Jeden­falls auf dem Papier. Man kann und muss sich tat­säch­lich manch­mal fra­gen, ob die eigent­li­che Arbeit wegen oder doch eher trotz der vie­len Pro­zes­se funk­tio­niert. Davon soll aber nur am Ran­de die Rede sein. Viel­mehr geht es um die Fra­ge, ob agi­le Orga­ni­sa­tio­nen Pro­zes­se und Stan­dards brau­chen. Und wenn ja, wie die­se eigent­lich ent­ste­hen und sich weiterentwickeln.

Ein Grund­prin­zip von agi­len Orga­ni­sa­tio­nen ist die Dezen­tra­li­sie­rung. Klei­ne und schlag­kräf­ti­ge Ein­hei­ten agie­ren mög­lichst kom­plett eigen­ver­ant­wort­lich gegen­über ihren Kun­den. Buurtz­org macht das zum Bei­spiel mit den Pfle­ge­teams so, FAVI mit den Mini-Fabri­ken und Spo­ti­fy mit sei­nem Squads oder Ama­zon mit den Two-Piz­za-Teams. Alles was die Ent­schei­dungs- und Hand­lungs­frei­heit die­ser Teams in Form von zen­tral vor­ge­ge­be­ner Pro­zes­se und Stan­dards ein­schränkt, schränkt die Agi­li­tät und damit den Kun­den­nut­zen ein.

Aber wo kämen wir denn da hin, wenn jedes Team anders arbei­te­te? Wird das nicht ganz schön unüber­sicht­lich? Wie soll man denn so zusam­men­ar­bei­ten? Ein paar Pro­zes­se und Stan­dards braucht es dann doch trotz aller Agi­li­tät. Kein ver­nünf­ti­ges Soft­ware­un­ter­neh­men wird es zum Bei­spiel zulas­sen, dass Teams die an einem gemein­sa­men Pro­dukt arbei­ten ihren Source­code in unter­schied­li­chen Repo­si­to­ries mit unter­schied­li­chen Bran­ching-Stra­te­gien ver­wal­ten. Zu müh­sam wäre es, das alles kon­ti­nu­ier­lich in ein lauf­fä­hi­ges Pro­dukt zu inte­grie­ren. Goog­le geht sogar soweit, sei­nen gesam­ten Source-Code, der aus meh­re­ren Mil­li­ar­den Zei­len besteht, seit mehr als 16 Jah­ren in einem ein­zi­gen Repo­si­to­ry zu speichern.

Auch auf Ver­spre­chen von Schnitt­stel­len will man sich bei aller Agi­li­tät ver­las­sen kön­nen und nicht täg­lich von einem kom­plett ande­ren Ver­hal­ten über­rascht wer­den. Dar­um hat es sich in vie­len agi­len Soft­ware­un­ter­neh­men als gute Prak­tik ein­ge­bür­gert, Schnitt­stel­len zu ver­sio­nie­ren, zu doku­men­tie­ren und mit auto­ma­ti­sie­ren Tests das ver­spro­che­ne Ver­hal­ten stän­dig zu veri­fi­zie­ren. Auf ein­mal ver­öf­fent­lich­te Schnitt­stel­len muss man sich blind ver­las­sen kön­nen und es muss einen Satz an auto­ma­ti­sier­ten Test­fäl­len geben, mit denen sich die Schnitt­stel­le über­prü­fen lässt. Ganz schön viel Regeln und ganz schön star­re Pro­zes­se für die agi­len Teams also.

Die Frei­heit des Ein­zel­nen endet dort, wo die Frei­heit des Ande­ren beginnt.
Imma­nu­el Kant

Die­se Leit­li­nie hilft auch hier bei der Unter­schei­dung. Ob die einen Teams lie­ber Scrum nut­zen und die ande­ren Kan­ban, oder ob die einen ein elek­tro­ni­sches Taskboard ver­wen­den, wäh­rend die ande­ren auf ihr phy­si­sches Board schwö­ren, wie sie ihren Team­raum deko­rie­ren oder mit wel­chen Werk­zeu­gen sie am pro­duk­tivs­ten arbei­ten, das und vie­les mehr berührt die Frei­heit der ande­ren Teams eher nicht oder nur wenig. Den Source-Code nicht zen­tral abzu­le­gen oder die Sta­bi­li­tät von ver­öf­fent­lich­ten Schnitt­stel­len zu ver­let­zen, berührt die Frei­heit der ande­ren sehr wohl, weil es dadurch unwei­ger­lich zu Stö­run­gen im Pro­zess des kon­ti­nu­ier­li­chen Bau­ens und Inte­grie­rens des gemein­sa­men Pro­dukts kommt. Und das ver­lang­samt dann alle.

Agi­le Soft­ware-Teams wol­len in ers­ter Linie eines: Ihr neu­es Fea­ture so schnell wie mög­lich aus­lie­fern und aus­pro­bie­ren. Dazu haben sie ihre hoch­gra­dig indi­vi­du­el­le Arbeits­wei­se im Team und das ist auch gut so. Dazu ver­las­sen sie sich aber auch auf Regeln der Zusam­men­ar­beit, die sich für alle als hilf­reich her­aus­ge­stellt haben. Agi­li­tät und Pro­zes­se und Stan­dards schlie­ßen sich also kei­nes­wegs aus. Im Gegen­teil, es braucht teil­wei­se sogar recht star­re Regeln, damit jedes Team sei­ne Agi­li­tät best­mög­lich im Ver­bund mit den ande­ren aus­le­ben kann.

Es bleibt also auch agil alles beim Alten? Nicht ganz. Die Pro­zes­se, Stan­dards und Regeln der gemein­sa­men Arbeit wer­den näm­lich nicht mehr an einer zen­tra­len Stel­le erar­bei­tet, beschrie­ben und dann für alle ver­pflich­tend aus­ge­rollt, sie ent­ste­hen viel­mehr aus der gemein­sa­men Arbeit und wer­den von den Teams gemein­sam wei­ter­ent­wi­ckelt. Der Haupt­un­ter­schied sind also nicht neue Pro­zes­se, Stan­dards und Regeln zur Zusam­men­ar­beit der agi­len Teams, son­dern viel mehr die Tat­sa­che, dass die­se aus der Zusam­men­ar­beit ent­ste­hen und alle gemein­sam dafür Ver­ant­wor­tung tra­gen anstatt sie als zen­tra­le Vor­ga­be auf­ge­zwun­gen zu bekom­men. Ein fei­ner, aber wesent­li­cher Unterschied.

Share This Post

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

2 Kommentare

Ob die einen Teams lie­ber Scrum nut­zen und die ande­ren Kan­ban, oder ob die einen ein elek­tro­ni­sches Taskboard ver­wen­den, wäh­rend die ande­ren auf ihr phy­si­sches Board schwö­ren, wie sie ihren Team­raum deko­rie­ren oder mit wel­chen Werk­zeu­gen sie am pro­duk­tivs­ten arbei­ten, das und vie­les mehr berührt die Frei­heit der ande­ren Teams eher nicht oder nur wenig.“

Ich gebe dir Recht, bei die­sem Satz, dass es die Teams nicht in der Frei­heit nicht ein­schränkt, wohl aber das Unter­neh­men, wel­ches viel­leicht Fea­tures ein­stellt, neue Teams bil­det, die sich dann an neue agi­le Metho­den gewöh­nen müs­sen oder die­se ganz neu ler­nen müs­sen. Über die Beweg­lich­keit und die Wand­lungs­fä­hig­keit von Ent­wick­lern hat Gun­ter Dueck gleich meh­re­re Bücher ver­fasst, inwie­weit unter­schied­li­che agi­le Arbeits­me­tho­den sich bei not­wen­di­gen Team-Inter­ak­tio­nen rei­ben, dazu fehlt mir die Erfahrung.

Lie­ber Hei­ko, unter­schied­li­che Metho­den füh­ren zu Rei­bung. Der Punkt ist, dass die Teams selbst da dann gemein­sam eine Lösung fin­den müs­sen und wer­den. Das Prin­zip der Selbst­or­ga­ni­sa­ti­on ist der Kern von Agilität.

Schreibe einen Kommentar