Das Team, das Produkt und der ganze Rest

Rund um Agi­li­tät gibt es ein grund­le­gen­des Miss­ver­ständ­nis. Die­ses Miss­ver­ständ­nis beginnt im Titel des Mani­fests für agi­le Soft­ware­ent­wick­lung. Unter Soft­ware­ent­wick­lung ver­stan­den vie­le über zu lan­ge Zeit das Über­set­zen von Spe­zi­fi­ka­tio­nen in Code durch aus­tausch­ba­re Pro­gram­mie­rer, die dadurch (und oft ver­stärkt durch Ver­trags­ver­hält­nis­se) kom­plett den Kon­takt zu ihren Kun­den und ihrem Pro­dukt ver­lo­ren hat­ten. Und vie­le ver­ste­hen unter Soft­ware­ent­wick­lung genau das heu­te noch. Nur in kür­ze­ren Zyklen. Agil eben. Den Autoren des Mani­fests, die alle­samt lei­den­schaft­li­che Soft­ware­ent­wick­ler waren, ging es aber um etwas ande­res. Ihnen ging es dar­um, die Soft­ware­ent­wick­lung wie­der als Zen­trum der Wert­schöp­fung zu begrei­fen und die gan­ze in schwer­ge­wich­ti­ge Pro­zes­se gegos­se­ne und in Orga­ni­sa­ti­ons­struk­tu­ren erstarr­te Ver­schwen­dung um die­ses Zen­trum her­um zu eli­mi­nie­ren. Es ging ihnen dar­um, als lang­le­bi­ges Team in gemein­sa­mer Ver­ant­wor­tung erfolg­rei­che Pro­duk­te zu ent­wi­ckeln. Und dazu darf es kei­ne Mit­tels­män­ner zwi­schen Team und Kun­den mit ent­spre­chen­den Arte­fak­ten und Über­ga­ben geben. Statt­des­sen müs­sen Fach­ex­per­ten und Ent­wick­ler täg­lich zusam­men­ar­bei­ten, um den Markt, das Pro­dukt und den Lösungs­raum gemein­sam zu erforschen.

Das Miss­ver­ständ­nis die­ser eigent­li­chen Absicht des Mani­fests für agi­le Soft­ware­ent­wick­lung schlägt sich in vie­len Scrum-Adap­tio­nen im Rol­len­ver­ständ­nis des Pro­duct-Owners nie­der. Wo die­ser sich im bes­ten Sin­ne als Pro­duct-Mana­ger oder wie der CEO des Pro­dukts ver­ste­hen soll­te, nimmt er oft­mals nur Anfor­de­run­gen ent­ge­gen und spe­zi­fi­ziert sie für das Deve­lo­p­ment-Team aus, damit sich die Ent­wick­ler auf das Ent­wi­ckeln kon­zen­trie­ren kön­nen. Kann man agil nen­nen, ist es aber nicht im Sin­ne der Autoren des Manifests.

Becau­se mem­bers of the pro­ject team stay in clo­se touch with out­side sources of infor­ma­ti­on, they can respond quick­ly to chan­ging mar­ket con­di­ti­ons. Team mem­bers enga­ge in a con­ti­nu­al pro­cess of tri­al and error to nar­row down the num­ber of alter­na­ti­ves that they must con­si­der. They also acqui­re broad know­ledge and diver­se skills, which help them crea­te a ver­sa­ti­le team capa­ble of sol­ving an array of pro­blems fast.
Hirotaka Takeu­chi und Iku­ji­ro Nona­ka in The New New Pro­duct Deve­lo­p­ment Game

Der Arti­kel von Takeu­chi und Nona­ka aus dem Jahr 1986 gilt als der Ursprung von Scrum. Wie das Zitat zeigt, erkann­ten sie aus ihren Unter­su­chun­gen schon damals, also 15 Jah­re vor dem Mani­fest für agi­le Soft­ware­ent­wick­lung, dass es eine kon­stan­te und inten­si­ve Ver­bin­dung zwi­schen Team und Außen­welt braucht, um in einem kon­ti­nu­ier­li­chen Pro­zess des Aus­pro­bie­rens und Ler­nens gemein­sam neue Erkennt­nis­se zu gewin­nen. Die­ses gemein­sa­me Erkun­den der Pro­blem­do­mä­ne ist eine Facet­te von dem was Tackeu­chi und Nona­ka „mul­ti­lear­ning“ nann­ten. Die ande­re Facet­te davon ist eine Lern­kul­tur in der alle stän­dig dar­um bemüht sind, Wis­sen wei­ter­zu­ge­gen, ihre Fer­tig­kei­ten zu ver­brei­tern und Exper­ten in meh­re­ren unter­schied­li­chen Dis­zi­pli­nen zu wer­den. Genau das macht inter­dis­zi­pli­nä­re Teams schnell und effektiv.

A bad sys­tem will beat a good per­son every time.
W. Edwards Deming

Neben einem Pro­duct-Owner als CEO des Pro­dukt und Soft­ware­ent­wick­lern mit Fer­tig­kei­ten in unter­schied­li­chen Dis­zi­pli­nen braucht es aber noch einen drit­te Grup­pe. Es braucht Men­schen, die die Dyna­mik kom­ple­xer Orga­ni­sa­tio­nen ana­ly­sie­ren und aus sys­te­mi­scher Sicht ganz­heit­lich opti­mie­ren kön­nen und auch die Macht dazu haben. Die­ses Sys­tem­den­ken ist also obers­te Auf­ga­be der Füh­rung. Es gehört aber auch zur Aus­bil­dung jedes ein­zel­nen Scrum-Mas­ters, der also – und das ist das zwei­te gro­ße Miss­ver­ständ­nis in vie­len Scrum-Adap­tio­nen – nicht nur Mode­ra­tor und Pro­to­kol­lant der Scrum-Events ist, son­dern die Pro­duk­ti­vi­tät des Teams in sei­ner Ein­bet­tung in die Orga­ni­sa­ti­on aus sys­te­mi­scher Sicht ana­ly­siert und verbessert.

Teile diesen Beitrag

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.

6 Kommentare

Dem ist inhalt­lich nichts hin­zu­zu­fü­gen, ver­weist es doch auf den fun­da­men­ta­len Unter­schied des agi­len Manage­ment-Modells zum tylo­ris­ti­schen: Im Mit­tel­punkt der Orga­ni­sa­ti­on steht das pro­duk­ti­ve Team und nicht die Orga­ni­sa­ti­on. Neben der Team­dienlich­keit muss das Orga­ni­sa­ti­ons­ziel sei­ne eige­ne Reduk­ti­on sein – immer wieder.

Ich kann dem bei Soft­ware im enge­ren Sin­ne noch zustim­men, aber spä­tes­tens wenn Sys­te­me ent­wi­ckelt wer­den, wel­che aus ganz unter­schied­li­chen Tei­len bestehen wie Ver­fah­rens­tech­nik, Mecha­nik, Leit­sys­tem, ein­ge­bet­te­ten Steue­run­gen, usw. kann das Team (wel­ches über­haupt der betei­lig­ten) das so nicht leis­ten. In die­sem Fal­le ist eines ange­sagt: Dekom­po­si­ti­on. Und damit haben wir wie­der Schnitt­stel­len zwi­schen den Gewer­ken. Das Prin­zip muss dann hier­ar­chisch auf ver­schie­den Ebe­nen ange­wen­det wer­den. Mal ganz abge­sehn von Din­gen wie Kon­for­mi­tät mit den EU Richt­li­ni­en und Funk­tio­na­le Sicherheit.

Das sehe ich anders. Die Teams die die Hirotaka Takeu­chi und Iku­ji­ro Nona­ka, The New New Pro­duct Deve­lo­p­ment Game, beschrie­ben sind waren genau durch eine mas­si­ve Inter­dis­zi­pli­na­ri­tät gekenn­zeich­net. Ich wür­de Dekom­po­si­ti­on immer soweit wie mög­lich ver­mei­den, das führt zu Über­ga­ben und Zwi­schen­er­geb­nis­sen und damit per Defi­ni­ti­on zu Verschwendung.

Schreibe einen Kommentar