Methoden-„Frankensteining“

Mary Shel­ley ließ Vik­tor Fran­ken­stein in ihrem gleich­na­mi­gen Roman ver­gleichs­wei­se wahl­los sein bei der Zusam­men­stel­lung der „Zuta­ten“ sei­ner Schöp­fung – dem (eben die­ser Wahl­lo­sig­keit wegen) spä­te­ren „Mons­ter“. Der Name „Fran­ken­stein“ steht seit­her für mons­trös-wahl­lo­se Schöp­fun­gen aller Art​¹; im Eng­li­schen hat gar das Verb „fran­ken­stei­ning“ eine gewis­se Ver­brei­tung erlangt​². „Mons­ter“ durch mehr oder min­der wahl­lo­ses Kom­bi­nie­ren zu erschaf­fen, scheint ein aus­rei­chend häu­fi­ges Phä­no­men zu sein, um eines dedi­zier­ten Begriffs zu bedür­fen. Gera­de im Umgang mit [[Projekt-]Management-]Methoden​³ und ande­ren Vor­ge­hens­mo­del­len scheint mir „Fran­ken­stei­ning“ schon immer und zudem in letz­ter Zeit zuneh­mend ver­brei­tet. „Mons­trö­ses“ ent­steht dabei m. E. auf (min­des­tens) vier ver­schie­de­ne Arten, die ich im Fol­gen­den näher betrach­ten möchte:

• Rosi­nen, …
• … Chi­mä­ren, …
• … Mutan­ten und …
• … unauf­ge­schla­ge­ne Eier.

Allen vier Vari­an­ten ist gemein, dass sie zwar auf ein­schlä­gi­gen Metho­den zu beru­hen schei­nen, meist aber eher einen „Abklatsch“ des­sen dar­stel­len, die Metho­de durch die Modi­fi­ka­ti­on oft in erheb­li­chem Umfang ihrer Wir­kung beraubt wur­de. Schlimms­ten­falls – und lei­der gar nicht so sel­ten – ent­steht des­we­gen auch noch ein aus­ge­spro­chen nega­ti­ver Ein­druck; die Metho­de kommt (völ­lig schuld­los) gleich­sam in Verruf.

Rosinen[picken]

Kennt­nis­se unter­schied­li­cher Metho­den als einen gut gefüll­ten Werk­zeug­kas­ten zu betrach­ten, aus dem man bei Bedarf ein geeig­ne­tes Werk­zeug her­vor­ho­len und mit einer gewis­sen Erfah­rung und Übung benut­zen kann, erscheint mir nicht ver­werf­lich. Geht man damit aber um wie ein werk­zeug­be­geis­ter­ter Fünf­jäh­ri­ger – greift man mehr oder min­der wahl­los Ein­zel­tei­le her­aus und ver­wen­det sie zumeist sowie­so nur ähn­lich einem Hammer​⁴ – kann von effek­ti­vem Werk­zeug­ein­satz meist nicht die Rede sein. Zudem sind vie­le Werk­zeu­ge für sich allein gar nicht sinn­voll nutz­bar: Eine Bohr­ma­schi­ne ohne Boh­rer hat eben­so wenig Sinn wie ein Boh­rer ohne Bohr­ma­schi­ne – aber natür­lich kann man mit bei­dem auf irgend­et­was her­um­klop­fen und anneh­men, man täte etwas Sinn­vol­les. Als ein ein­fa­ches Bei­spiel kann hier das Dai­ly und das Time­boxing als „Rosi­nen“ im Kuchen „Scrum“ dienen:

• Time­boxing für Mee­tings außer­halb des Kon­texts von z. B. Scrum ein­zu­füh­ren, ist m. E. meist pro­blem­los iso­liert mög­lich (vgl. hier) – und die meis­ten Teil­neh­mer fast jedes Mee­tings wer­den es Ihnen danken!
• Ein „Dai­ly“ unab­hän­gig von Scrum (oder ande­ren ein sol­ches Mee­ting nut­zen­den Vor­ge­hens­mo­del­len) ein­zu­füh­ren, kann aller­dings durch­aus extrem kon­tra­pro­duk­tiv sein: Haben die Mit­glie­der des Teams sich womög­lich gar nicht täg­lich etwas zu sagen – han­delt es sich z. B. über­haupt nicht um ein Team, in dem Men­schen gemein­sam und zusam­men arbei­ten, son­dern viel­mehr um eine Grup­pe von Men­schen, die rela­tiv unab­hän­gig von­ein­an­der arbei­ten und nur vom Orga­ni­gramm zusam­men­ge­fasst wur­den –, hat ein „Dai­ly“ kei­ne wirk­li­che Exis­tenz­be­rech­ti­gung und macht auch nicht „agi­ler“. Glei­ches gilt, wenn rele­van­te Ergeb­nis­se und Ver­än­de­run­gen nur alle paar Tage oder gar Wochen vor­lie­gen. Fin­det den­noch ein Mee­ting statt, ist mei­ner Erfah­rung nach die Wahr­schein­lich­keit hoch, dass es trotz­dem erstaun­lich lan­ge dau­ert – und womög­lich täg­lich gan­ze Per­so­nen­ta­ge mit Wie­der­ho­lun­gen oder mit für (vie­le) Teil­neh­mer Irrele­van­tem ver­bracht werden.
• Wird nun ein „Dai­ly“ ohne Time­boxing ein­ge­führt, ist die Wahr­schein­lich­keit für aus­ufern­de „Kaf­fee­kränz­chen“ (gera­de unter den o. g. Umstän­den) extrem hoch.

Inter­es­san­ter­wei­se erle­be ich den hier nur bei­spiel­haft ange­führ­ten Fall des „Dai­ly“ ohne wirk­li­che Exis­tenz­be­rech­ti­gung in letz­ter Zeit häu­fi­ger – und oft­mals tat­säch­lich als m. E. unzu­rei­chen­den Ver­such, „Agi­li­tät“ auch noch in die klas­sischs­te Organisationsform​⁵ zu brin­gen. „Das machen jetzt alle“ – das Mot­to hin­ter der Ent­ste­hung aller MeTooden​⁶ – ist ein Schein-Argu­ment, das uns bei der Betrach­tung des Metho­den-Fran­ken­stei­nings noch öfter unter­kom­men wird.

Chimären

„Mons­trö­ses“ ent­steht aller­dings oft­mals nicht, weil die ein­zel­nen „Zuta­ten“ jeweils für sich man­gel­haft sind, son­dern viel häu­fi­ger, indem wohl­mei­nend die ver­meint­lich bes­ten oder zumin­dest auf­fäl­ligs­ten Bestand­tei­le unter­schied­li­cher Din­ge mit­ein­an­der zu etwas Neu­em ver­mischt wer­den – und das eben lei­der, ohne dass sie wirk­lich zuein­an­der passen.

Die Idee, „das Bes­te aus zwei Wel­ten“ durch eine ent­spre­chen­de Mischung zu erhal­ten, ist uralt – mani­fest bei­spiels­wei­se in der Idee des Pegasos, einer Mischung aus Pferd und Vogel. Es braucht wohl kei­ner umfang­rei­chen phy­si­ka­li­schen Berech­nun­gen, um zu kon­sta­tie­ren, dass ein Pegasos (so es ihn denn gäbe) zwei­fel­los flug­un­fä­hig wäre – und die wei­test­ge­hend nutz­lo­sen Flü­gel wür­den am Boden ver­mut­lich stö­ren. Ande­re Chi­mä­ren hin­ge­gen exis­tie­ren real und sind ver­gleichs­wei­se erfolg­reich – der Maul­esel​⁷ bei­spiels­wei­se ist seit der Anti­ke und vie­ler­or­ten auch heut­zu­ta­ge ein wich­ti­ges Nutztier.

Es kommt also auf die Mischung an – nur wor­auf genau? Von Kan­bil​⁸, einer „Mischung“ aus Kan­ban und ITIL, z. B. hört man fast gar nichts mehr (Goog­le-Suche), Scrum­ban hin­ge­gen erfreut sich durch­aus einer gewis­sen Beliebt­heit. Nach mei­nem Ein­druck kommt es beim „Zusam­men­mi­schen“ der Metho­den-Chi­mä­ren bzw. ‑Hybri­den vor allem auf zwei Din­ge an:

• Indem man zwei in sich geschlos­se­ne, eini­ger­ma­ßen wider­spruchs­freie Gedan­ken­ge­bil­de ver­mischt, ent­steht nicht zwangs­läu­fig und auto­ma­tisch ein neu­es in sich geschlos­se­nes, wider­spruchs­frei­es Gedan­ken­ge­bil­de. Im Gegen­teil: Das sinn­vol­le Mischen scheint mir erstaun­lich har­te Arbeit zu sein, gera­de in Bezug auf die Wider­spruchs­frei­heit. Betrach­tet man „Hybri­den“ wie PRINCE2 Agi­le​⁹, wird schnell deut­lich, dass es nicht mit dem blo­ßen Mischen der Metho­den getan ist – weder bei der Ent­wick­lung noch beim Einsatz.
• Lie­gen den Bestand­tei­len der Chi­mä­ren völ­lig unter­schied­li­che Hal­tun­gen zugrun­de, wird das Mischen ungleich schwe­rer – viel­leicht eine Erklä­rung für die Stil­le, die um Kan­bil herrscht: Die meist doch recht umfang­rei­chen Ver­än­de­run­gen und das in der Pra­xis beob­acht­ba­re Vor­ge­hen bei einer ITIL-Ein­füh­rung pas­sen m. E. nur sehr bedingt zum Kan­ban-Prin­zip „Begin­ne mit dem, was du gera­de tust“ – die Unter­schied­lich­keit tritt also recht früh zutage.

Mutanten

Chi­mä­ren bzw. Hybri­den ent­ste­hen durch das Mischen von Metho­den. Ver­än­dert man eine Metho­de ein­fach so, ent­steht ein Methoden-„Mutant“. Der Über­gang zwi­schen die­sen bei­den Vari­an­ten ist dabei oft flie­ßend: Schaut man genau hin, erweist sich die „Muta­ti­on“ doch oft als einer ande­ren Metho­de ent­lie­hen, das Ergeb­nis also doch als chi­mä­ren­haf­te „Mischung“. Das ändert aber nichts am Pro­blem: Ver­än­de­run­gen an in sich geschlos­se­nen, mehr oder min­der durch­dach­ten Metho­den soll­ten mit Bedacht erfol­gen, möch­te man nicht aus Ver­se­hen die Metho­de ihres Kerns ent­klei­den, womög­lich ihrer Wirk­sam­keit berau­ben. Der Scrum-Gui­de warnt nicht ohne Grund ein­dring­lich „[…] Die Rol­len, Arte­fak­te, Ereig­nis­se und Regeln von Scrum sind unver­än­der­lich. Es ist zwar mög­lich, nur Tei­le von Scrum ein­zu­set­zen – das Ergeb­nis ist dann aber nicht Scrum. Scrum exis­tiert nur in sei­ner Gesamt­heit […]“​¹⁰. Das Wort „Scrum“ in die­sem Zitat lie­ße sich m. E. pro­blem­los durch die Bezeich­nung fast jedes Metho­den-Frame­works erset­zen – der Satz blie­be sinn­voll, die War­nung blie­be ange­mes­sen: Modi­fi­ziert man eine Metho­de, ent­steht etwas völ­lig Neu­es, das einer neu­en Bezeich­nung bedarf – nicht zuletzt übri­gens auch, um im Fal­le einer dys­funk­tio­na­len Modi­fi­ka­ti­on nicht den Namen des „Ori­gi­nals“ zu beschä­di­gen. Der „Muta­ti­on“ einen neu­en Namen zu geben, zeigt aber vor allem, dass man etwas Neu­es erschaf­fen hat; der neue Name dient als Mah­nung, das neue Kon­strukt in Gän­ze kri­tisch zu durch­den­ken und sich nicht ein­fach nur auf die ursprüng­li­che Metho­de zu beru­fen. „Nur ein biss­chen modi­fi­ziert“ gibt es nicht – mit jeder Ver­än­de­rung über­nimmt man auto­ma­tisch die Ver­ant­wor­tung für die Funk­ti­ons­fä­hig­keit des neu­en Kon­strukts als Ganzes.

Unaufgeschlagene Eier

Die „unauf­ge­schla­ge­nen Eier“ könn­ten eben­so gut die „tro­cke­nen Pel­ze“ hei­ßen – „You can’t make an ome­lette wit­hout brea­king eggs.“ fin­det sein Äqui­va­lent im Deut­schen in „Wasch´ mir den Pelz, aber mach´ mich nicht nass.“. Es gibt ver­mut­lich in jeder Spra­che ein ver­gleich­ba­res Sprich­wort – und das wohl auch aus gutem Grund.

Wohl kaum jemand käme auf die Idee, Fuß­ball ohne die Abseits-Regel zu spie­len, weil die­se zu kom­pli­ziert sei, die Über­wa­chung schwie­rig sei (sie bedarf zusätz­li­chen Per­so­nals in Form eines Lini­en­rich­ters) und sie sowie­so kei­ner ver­ste­he: Das Spiel wäre eines sehr wesent­li­chen Ele­ments beraubt, ein deut­lich ande­res Spiel und ver­mut­lich deut­lich weni­ger span­nend, womög­lich gar langweilig.

Ist etwas zu teu­er oder zu kom­pli­ziert oder gar unver­stan­den, wird in der Welt der Metho­den und Vor­ge­hens­mo­del­le oft deut­lich weni­ger bedacht vor­ge­gan­gen. Was nicht passt, wird pas­send gemacht – Haupt­sa­che, die MeToode (Ver­zei­hung: „Metho­de“) kommt zum Ein­satz! Auf die­sem Weg ent­ste­hen jede Men­ge „unauf­ge­schla­ge­ner Eier“ – eini­ge Bei­spie­le aus der Praxis:

• Scrum ohne einen (teu­ren) Scrum Mas­ter oder mit Scrum Mas­ter und Pro­duct Owner in einer Per­son („So heißt jetzt neu­er­dings der Projektmanager“)
• ITIL ohne die „anstren­gen­de­ren“ Pro­zes­se (oft ver­bleibt am Ende nur das Inci­dent Manage­ment)
• PRINCE2 ohne expli­zier­ten Busi­ness Case und dem­entspre­chend auch ohne die fort­lau­fen­de geschäft­li­che Recht­fer­ti­gung („Con­tin­ued Busi­ness Justification“)
• Kan­ban ohne WIP-Limits (vgl. hier und hier)

Die­se Auf­zäh­lung der „unauf­ge­schla­ge­nen Eier“ lässt sich ver­mut­lich belie­big fort­set­zen – offen­kun­dig auch in Zusam­men­hang mit nicht-agi­len Metho­den. Allen die­sen Mons­tro­si­tä­ten gemein­sam ist: Es wur­de etwas weg­ge­las­sen, des­sen Feh­len die Metho­de als eigent­lich in sich geschlos­se­nes Gedan­ken­ge­bil­de ihres Kerns beraubt. Übrig bleibt womög­lich nur ein ske­lett­haf­ter „Metho­den-Rest“ – und natür­lich der begehr­te Name der Methode.

Was weg­ge­las­sen wird, hat m. E. übri­gens meist sehr viel mit der hin­ter der Metho­de ste­hen­den Hal­tung zu tun – die eige­ne Hal­tung der Metho­de ange­mes­sen zu ver­än­dern, ist nun ein­mal oft­mals das Schwierigste.

Egal, auf wel­che Wei­se Sie eine Metho­de modi­fi­zie­ren oder sich etwas „her­aus­pi­cken“:

• Muss die Metho­de an die eige­ne Hal­tung ange­passt wer­den, geht die Modi­fi­ka­ti­on meist schief. Hal­tung und Metho­de sind m. E. meist extrem eng mit­ein­an­der ver­wo­ben und i. d. R. nicht zu trennen.
• Pickt man sich ein Ein­zel­teil her­aus, muss es auch wirk­lich iso­liert funktionieren. 
• Modi­fi­ziert man eine Metho­de, schafft man etwas Neu­es – und ist für die Funk­ti­ons­fä­hig­keit voll und ganz verantwortlich.