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 erfor­schen.

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 Mani­fests.

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 effek­tiv.

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 ver­bes­sert.

Du willst keinen Artikel mehr verpassen?

Mit mei­nem News­let­ter bekommst du ein­mal wöchent­lich die neu­es­ten Arti­kel direkt in dei­nen Ein­gangs­korb.

7 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 wie­der.

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 Sicher­heit.

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 Ver­schwen­dung.

Schreibe einen Kommentar