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. Buurt­z­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.

Teile diesen Beitrag

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.

Schreibe einen Kommentar