Standards setzen in agilen Organisationen

Agili­tät braucht Ori­en­tie­rung. Erst eine gemein­sa­me Aus­rich­tung ermög­licht effek­ti­ve Auto­no­mie und dezen­tra­le Ent­schei­dun­gen, wodurch agi­le Orga­ni­sa­tio­nen so anpas­sungs­fä­hig wer­den. Agi­li­tät braucht aber auch gemein­sa­me Stan­dards und Kon­ven­tio­nen, damit trotz aller Unab­hän­gig­keit die Zusam­men­ar­beit gut gelingt. Die span­nen­de Fra­ge ist also nicht, ob es sol­che Stan­dards in agi­len Orga­ni­sa­tio­nen braucht, son­dern wie sie sinn­vol­ler­wei­se ent­ste­hen und durch­ge­setzt werden.

Die Ant­wort auf die­se Fra­ge ist in tra­di­tio­nell funk­tio­nal auf­ge­teil­ten Orga­ni­sa­tio­nen nahe­lie­gend und leid­lich bekannt: Eine Orga­ni­sa­ti­ons­ein­heit von Spe­zia­lis­ten wird gebil­det mit dem Auf­trag, Richt­li­ni­en, Stan­dards, Pro­zess­mo­del­le, Vor­ge­hens­mo­del­le, etc. aus­zu­ar­bei­ten, aus­zu­rol­len und dann wei­ter­zu­ent­wi­ckeln. Weni­ge Spe­zia­lis­ten erdenken mehr oder weni­ger im Elfen­bein­turm Stan­dards für den Rest. Den­ken und Han­deln ist damit genau­so streng getrennt wie noch zu Zei­ten von Hen­ry Ford (wo das Den­ken in die­sem Sin­ne zwar noch eher beim Mana­ger und nicht bei einer spe­zia­li­sier­ten Ein­heit lag, was aber am Prin­zip nichts ändert).

Stan­dards should not be forced down from abo­ve but rather set by the pro­duc­tion workers themselves.

Tai­i­chi Ōno

Eine wesent­li­che und ent­schei­den­de Neue­rung des Toyo­ta-Pro­duk­ti­ons­sys­tem, das Tai­i­chi Ōno maß­geb­lich gestal­te­te, war es, Den­ken und Han­deln wie­der am Ort der Wert­schöp­fung zusam­men­zu­füh­ren. Toyo­ta gelang es dadurch, die Pro­duk­ti­vi­tät deut­lich zu stei­gern und nicht nur aus abge­schla­ge­ner Posi­ti­on zur ame­ri­ka­ni­schen Kon­kur­renz aus Detroit auf­zu­schlie­ßen, son­dern sie sogar zu über­run­den. Die Kon­zep­te und Metho­den ver­brei­te­ten sich von der pro­du­zie­ren­den Indus­trie aus­ge­hend als Lean Manu­fac­tu­ring in vie­le wei­te­re Bran­chen in der Ver­all­ge­mei­ne­rung als Lean Manage­ment – auch in die IT, wo das Agi­le Mani­fest his­to­risch und inhalt­lich als Anwen­dung von Lean Prin­zi­pi­en auf den Pro­zess der Soft­ware­ent­wick­lung gele­sen wer­den kann.

Some­thing is wrong if workers do not look around each day, find things that are tedious or bor­ing, and then rewri­te the pro­ce­du­res. Even last month’s manu­al should be out of date.

Tai­i­chi Ōno

Besitzen statt mieten

Für Tai­i­chi Ōno waren Stan­dards die Grund­la­ge jeder kon­ti­nu­ier­li­chen Ver­bes­se­rung („Wit­hout stan­dards, the­re can be no impro­ve­ment.”). Ihm war aber auch klar, dass die ein­zi­gen, die die­se Stan­dards und Pro­zes­se ent­wi­ckeln und wei­ter­ent­wi­ckeln dür­fen, die­je­ni­gen sind, die sie auch täg­lich leben. Die Rol­le der Füh­rungs­kraft ist dabei eine unter­stüt­zen­de: Es geht dar­um, die Mit­ar­bei­ter genau dazu zu befä­hi­gen anstatt sie zu beleh­ren.

Genau die­se Erkennt­nis­se aus dem Lean Manage­ment geben den ent­schei­de­nen Hin­weis zur Beant­wor­tung der ein­gangs gestell­ten Fra­ge, wie Stan­dards, Richt­li­ni­en, Pro­zes­se, etc. in agi­len Orga­ni­sa­tio­nen ent­ste­hen und wei­ter­ent­wi­ckelt wer­den. All das gehört ein­deu­tig in die Hän­de und Ver­ant­wor­tung der­je­ni­gen, die damit täg­lich arbei­ten müs­sen. Die Devi­se lau­tet: Besit­zen statt mieten. 

Wie die Auf­ga­be des Mana­gers im Lean Manage­ment ändert sich mit die­sem Grund­satz auch die Auf­ga­be der ehe­ma­li­gen Zen­tral­stel­len für Stan­dards, Pro­zes­se, etc. Anstatt vor­zu­ge­ben und zu kon­trol­lie­ren geht es jetzt dar­um, alle direkt Betrof­fe­nen zu die­ser Arbeit an den gemein­sa­men Stan­dards zu befä­hi­gen. Durch Aus­bil­dung und Coa­ching einer­seits und durch ein gutes Com­mu­ni­ty-Manage­ment andererseits.



Share This Post

2 Kommentare

Andrea Heck 23. Mai 2019 Antworten

Hal­lo Marcus, 

Ja!

Das ist genau auch mei­ne lang­jäh­ri­ge Erfah­rung aus agi­len Orga­ni­sa­tio­nen, dass es so funk­tio­niert, dass so auch Owner­ship an den Stan­dards ent­steht: Men­schen aus ver­schie­de­nen Teams oder eben eine Com­mu­ni­ty of Prac­ti­ce setzt sich zusam­men und schreibt den ers­ten Ent­wurf der Stan­dards, ob das jetzt z.B. eine Coding Gui­de­line ist, oder eine grund­le­gen­de Defi­ni­ti­on of Done für alle Teams und Pro­duk­te. Dann wen­den alle die­se Gui­de­line an, und von Zeit zu Zeit wer­den neue Erkennt­nis­se dis­ku­tiert, auf­ge­nom­men, und wie­der in den Teams verbreitet.

Was ich auch schon erlebt habe: 

Wenn Ent­wick­ler sich wei­gern, mit­ein­an­der Stan­dards zu set­zen, dann geschieht das, wenn sie kei­ne Spiel­räu­me in der Orga­ni­sa­ti­on haben, die­se auch umzu­set­zen. Wenn sie bei­spiels­wei­se bestimm­te Arten von Test­au­to­ma­ti­sie­rung für wich­tig hal­ten, aber kei­ne Zeit bekom­men, um sie auch zu imple­men­tie­ren, weil sie das „wie“ nicht wirk­lich in der Hand haben. 

Das The­ma dei­nes Arti­kels geht natür­lich noch weit über sol­che ent­wick­lungs­in­ter­nen Stan­dards hin­aus. Es geht ja um Gover­nan­ce, Risi­ko und Com­pli­ance-Pro­zes­se, die auch in vie­len Fir­men, wo sich die Ent­wick­lung oder IT für rela­tiv agil/lean hält, noch bei ganz zen­tra­len Ein­hei­ten lie­gen. Da ist es beson­ders wich­tig, dass The­men wie IT-Sicher­heit, Daten­schutz usw. Teil des agi­len Pro­zes­ses und Teil der Ver­ant­wor­tung der Pro­dukt­teams wer­den, und die zen­tra­len Ein­hei­ten sie nur dabei unter­stüt­zen, die Anfor­de­run­gen zu ver­ste­hen. Wenn sie dage­gen detail­liert das „Wie“ der Umsat­zung vor­schrei­ben, kos­tet das oft Mona­te auf der Time­line, ohne dass dadurch bereits neu­es­te tech­ni­sche Erkennt­nis­se oder Lösun­gen zu dem The­ma ein­ge­flos­sen wären.

Marcus Raitner 23. Mai 2019 Antworten

Vie­len Dank für dei­ne aus­führ­li­chen Ergän­zun­gen! Je bes­ser die­ses „owning“ pas­siert des­to Ver­ant­wort­li­cher wer­den die Teams und des­to bes­ser wird die Qua­li­tät. Den­noch tun sich gro­ße Orga­ni­sa­tio­nen mit die­sem schein­ba­ren Kon­troll­ver­lust sehr schwer.

Schreibe einen Kommentar