Methoden-„Frankensteining“

Tim Themann

vor 6 Jahren

Mary Shelley ließ Viktor Frankenstein in ihrem gleichnamigen Roman vergleichsweise wahllos sein bei der Zusammenstellung der „Zutaten“ seiner Schöpfung – dem (eben dieser Wahllosigkeit wegen) späteren „Monster“. Der Name „Frankenstein“ steht seither für monströs-wahllose Schöpfungen aller Art¹; im Englischen hat gar das Verb „frankensteining“ eine gewisse Verbreitung erlangt². „Monster“ durch mehr oder minder wahlloses Kombinieren zu erschaffen, scheint ein ausreichend häufiges Phänomen zu sein, um eines dedizierten Begriffs zu bedürfen. Gerade im Umgang mit [[Projekt-]Management-]Methoden³ und anderen Vorgehensmodellen scheint mir „Frankensteining“ schon immer und zudem in letzter Zeit zunehmend verbreitet. „Monströses“ entsteht dabei m. E. auf (mindestens) vier verschiedene Arten, die ich im Folgenden näher betrachten möchte:

Allen vier Varianten ist gemein, dass sie zwar auf einschlägigen Methoden zu beruhen scheinen, meist aber eher einen „Abklatsch“ dessen darstellen, die Methode durch die Modifikation oft in erheblichem Umfang ihrer Wirkung beraubt wurde. Schlimmstenfalls – und leider gar nicht so selten – entsteht deswegen auch noch ein ausgesprochen negativer Eindruck; die Methode kommt (völlig schuldlos) gleichsam in Verruf.

Rosinen[picken]

Kenntnisse unterschiedlicher Methoden als einen gut gefüllten Werkzeugkasten zu betrachten, aus dem man bei Bedarf ein geeignetes Werkzeug hervorholen und mit einer gewissen Erfahrung und Übung benutzen kann, erscheint mir nicht verwerflich. Geht man damit aber um wie ein werkzeugbegeisterter Fünfjähriger – greift man mehr oder minder wahllos Einzelteile heraus und verwendet sie zumeist sowieso nur ähnlich einem Hammer⁴ – kann von effektivem Werkzeugeinsatz meist nicht die Rede sein. Zudem sind viele Werkzeuge für sich allein gar nicht sinnvoll nutzbar: Eine Bohrmaschine ohne Bohrer hat ebenso wenig Sinn wie ein Bohrer ohne Bohrmaschine – aber natürlich kann man mit beidem auf irgendetwas herumklopfen und annehmen, man täte etwas Sinnvolles. Als ein einfaches Beispiel kann hier das Daily und das Timeboxing als „Rosinen“ im Kuchen „Scrum“ dienen:

Timeboxing für Meetings außerhalb des Kontexts von z. B. Scrum einzuführen, ist m. E. meist problemlos isoliert möglich (vgl. hier) – und die meisten Teilnehmer fast jedes Meetings werden es Ihnen danken!
Ein „Daily“ unabhängig von Scrum (oder anderen ein solches Meeting nutzenden Vorgehensmodellen) einzuführen, kann allerdings durchaus extrem kontraproduktiv sein: Haben die Mitglieder des Teams sich womöglich gar nicht täglich etwas zu sagen – handelt es sich z. B. überhaupt nicht um ein Team, in dem Menschen gemeinsam und zusammen arbeiten, sondern vielmehr um eine Gruppe von Menschen, die relativ unabhängig voneinander arbeiten und nur vom Organigramm zusammengefasst wurden –, hat ein „Daily“ keine wirkliche Existenzberechtigung und macht auch nicht „agiler“. Gleiches gilt, wenn relevante Ergebnisse und Veränderungen nur alle paar Tage oder gar Wochen vorliegen. Findet dennoch ein Meeting statt, ist meiner Erfahrung nach die Wahrscheinlichkeit hoch, dass es trotzdem erstaunlich lange dauert – und womöglich täglich ganze Personentage mit Wiederholungen oder mit für (viele) Teilnehmer Irrelevantem verbracht werden.
Wird nun ein „Daily“ ohne Timeboxing eingeführt, ist die Wahrscheinlichkeit für ausufernde „Kaffeekränzchen“ (gerade unter den o. g. Umständen) extrem hoch.

Interessanterweise erlebe ich den hier nur beispielhaft angeführten Fall des „Daily“ ohne wirkliche Existenzberechtigung in letzter Zeit häufiger – und oftmals tatsächlich als m. E. unzureichenden Versuch, „Agilität“ auch noch in die klassischste Organisationsform⁵ zu bringen. „Das machen jetzt alle“ – das Motto hinter der Entstehung aller MeTooden⁶ – ist ein Schein-Argument, das uns bei der Betrachtung des Methoden-Frankensteinings noch öfter unterkommen wird.

Chimären

„Monströses“ entsteht allerdings oftmals nicht, weil die einzelnen „Zutaten“ jeweils für sich mangelhaft sind, sondern viel häufiger, indem wohlmeinend die vermeintlich besten oder zumindest auffälligsten Bestandteile unterschiedlicher Dinge miteinander zu etwas Neuem vermischt werden – und das eben leider, ohne dass sie wirklich zueinander passen.

Die Idee, „das Beste aus zwei Welten“ durch eine entsprechende Mischung zu erhalten, ist uralt – manifest beispielsweise in der Idee des Pegasos, einer Mischung aus Pferd und Vogel. Es braucht wohl keiner umfangreichen physikalischen Berechnungen, um zu konstatieren, dass ein Pegasos (so es ihn denn gäbe) zweifellos flugunfähig wäre – und die weitestgehend nutzlosen Flügel würden am Boden vermutlich stören. Andere Chimären hingegen existieren real und sind vergleichsweise erfolgreich – der Maulesel⁷ beispielsweise ist seit der Antike und vielerorten auch heutzutage ein wichtiges Nutztier.

Es kommt also auf die Mischung an – nur worauf genau? Von Kanbil⁸, einer „Mischung“ aus Kanban und ITIL, z. B. hört man fast gar nichts mehr (Google-Suche), Scrumban hingegen erfreut sich durchaus einer gewissen Beliebtheit. Nach meinem Eindruck kommt es beim „Zusammenmischen“ der Methoden-Chimären bzw. ‑Hybriden vor allem auf zwei Dinge an:

Indem man zwei in sich geschlossene, einigermaßen widerspruchsfreie Gedankengebilde vermischt, entsteht nicht zwangsläufig und automatisch ein neues in sich geschlossenes, widerspruchsfreies Gedankengebilde. Im Gegenteil: Das sinnvolle Mischen scheint mir erstaunlich harte Arbeit zu sein, gerade in Bezug auf die Widerspruchsfreiheit. Betrachtet man „Hybriden“ wie PRINCE2 Agile⁹, wird schnell deutlich, dass es nicht mit dem bloßen Mischen der Methoden getan ist – weder bei der Entwicklung noch beim Einsatz.
Liegen den Bestandteilen der Chimären völlig unterschiedliche Haltungen zugrunde, wird das Mischen ungleich schwerer – vielleicht eine Erklärung für die Stille, die um Kanbil herrscht: Die meist doch recht umfangreichen Veränderungen und das in der Praxis beobachtbare Vorgehen bei einer ITIL-Einführung passen m. E. nur sehr bedingt zum Kanban-Prinzip „Beginne mit dem, was du gerade tust“ – die Unterschiedlichkeit tritt also recht früh zutage.

Mutanten

Chimären bzw. Hybriden entstehen durch das Mischen von Methoden. Verändert man eine Methode einfach so, entsteht ein Methoden-„Mutant“. Der Übergang zwischen diesen beiden Varianten ist dabei oft fließend: Schaut man genau hin, erweist sich die „Mutation“ doch oft als einer anderen Methode entliehen, das Ergebnis also doch als chimärenhafte „Mischung“. Das ändert aber nichts am Problem: Veränderungen an in sich geschlossenen, mehr oder minder durchdachten Methoden sollten mit Bedacht erfolgen, möchte man nicht aus Versehen die Methode ihres Kerns entkleiden, womöglich ihrer Wirksamkeit berauben. Der Scrum-Guide warnt nicht ohne Grund eindringlich „[…] Die Rollen, Artefakte, Ereignisse und Regeln von Scrum sind unveränderlich. Es ist zwar möglich, nur Teile von Scrum einzusetzen – das Ergebnis ist dann aber nicht Scrum. Scrum existiert nur in seiner Gesamtheit […]“¹⁰. Das Wort „Scrum“ in diesem Zitat ließe sich m. E. problemlos durch die Bezeichnung fast jedes Methoden-Frameworks ersetzen – der Satz bliebe sinnvoll, die Warnung bliebe angemessen: Modifiziert man eine Methode, entsteht etwas völlig Neues, das einer neuen Bezeichnung bedarf – nicht zuletzt übrigens auch, um im Falle einer dysfunktionalen Modifikation nicht den Namen des „Originals“ zu beschädigen. Der „Mutation“ einen neuen Namen zu geben, zeigt aber vor allem, dass man etwas Neues erschaffen hat; der neue Name dient als Mahnung, das neue Konstrukt in Gänze kritisch zu durchdenken und sich nicht einfach nur auf die ursprüngliche Methode zu berufen. „Nur ein bisschen modifiziert“ gibt es nicht – mit jeder Veränderung übernimmt man automatisch die Verantwortung für die Funktionsfähigkeit des neuen Konstrukts als Ganzes.

Unaufgeschlagene Eier

Die „unaufgeschlagenen Eier“ könnten ebenso gut die „trockenen Pelze“ heißen – „You can’t make an omelette without breaking eggs.“ findet sein Äquivalent im Deutschen in „Wasch´ mir den Pelz, aber mach´ mich nicht nass.“. Es gibt vermutlich in jeder Sprache ein vergleichbares Sprichwort – und das wohl auch aus gutem Grund.

Wohl kaum jemand käme auf die Idee, Fußball ohne die Abseits-Regel zu spielen, weil diese zu kompliziert sei, die Überwachung schwierig sei (sie bedarf zusätzlichen Personals in Form eines Linienrichters) und sie sowieso keiner verstehe: Das Spiel wäre eines sehr wesentlichen Elements beraubt, ein deutlich anderes Spiel und vermutlich deutlich weniger spannend, womöglich gar langweilig.

Ist etwas zu teuer oder zu kompliziert oder gar unverstanden, wird in der Welt der Methoden und Vorgehensmodelle oft deutlich weniger bedacht vorgegangen. Was nicht passt, wird passend gemacht – Hauptsache, die MeToode (Verzeihung: „Methode“) kommt zum Einsatz! Auf diesem Weg entstehen jede Menge „unaufgeschlagener Eier“ – einige Beispiele aus der Praxis:

Scrum ohne einen (teuren) Scrum Master oder mit Scrum Master und Product Owner in einer Person („So heißt jetzt neuerdings der Projektmanager“)
ITIL ohne die „anstrengenderen“ Prozesse (oft verbleibt am Ende nur das Incident Management)
PRINCE2 ohne explizierten Business Case und dementsprechend auch ohne die fortlaufende geschäftliche Rechtfertigung („Continued Business Justification“)
Kanban ohne WIP-Limits (vgl. hier und hier)

Diese Aufzählung der „unaufgeschlagenen Eier“ lässt sich vermutlich beliebig fortsetzen – offenkundig auch in Zusammenhang mit nicht-agilen Methoden. Allen diesen Monstrositäten gemeinsam ist: Es wurde etwas weggelassen, dessen Fehlen die Methode als eigentlich in sich geschlossenes Gedankengebilde ihres Kerns beraubt. Übrig bleibt womöglich nur ein skeletthafter „Methoden-Rest“ – und natürlich der begehrte Name der Methode.

Was weggelassen wird, hat m. E. übrigens meist sehr viel mit der hinter der Methode stehenden Haltung zu tun – die eigene Haltung der Methode angemessen zu verändern, ist nun einmal oftmals das Schwierigste.

Egal, auf welche Weise Sie eine Methode modifizieren oder sich etwas „herauspicken“:

Muss die Methode an die eigene Haltung angepasst werden, geht die Modifikation meist schief. Haltung und Methode sind m. E. meist extrem eng miteinander verwoben und i. d. R. nicht zu trennen.
Pickt man sich ein Einzelteil heraus, muss es auch wirklich isoliert funktionieren.
Modifiziert man eine Methode, schafft man etwas Neues – und ist für die Funktionsfähigkeit voll und ganz verantwortlich.

Footnotes:

↑ Und das, obgleich in Shelleys Roman gar nicht das „Monster“, sondern vielmehr sein Schöpfer „Frankenstein“ hieß.
↑ Vgl. <https://www.urbandictionary.com/define.php?term=Frankensteining#6260001> (18.02.2019).
↑ Ja, die Klammern sind tatsächlich mit Bedacht gesetzt.
↑ Abraham Maslow kam nicht von ungefähr zu seiner Metapher.
↑ Die m. E. ja nicht per se schlecht sein muss.
↑ Ja, den Begriff verwende ich schon seit Jahren. Und: Nein, er ist mir nicht erst Ende 2017 eingefallen.
↑ Biologisch exakt übrigens eine Hybride, keine Chimäre.
↑ Vgl. <https://www.cio.de/a/neue-methode-aus-kanban-und-itil-wird-kanbil,2891953> (25.02.2019).
↑ Vgl. bspw. <http://prince2agile.wiki/An_Overview_of_PRINCE2_Agile> (27.02.2019).
↑ Schwaber, Ken und Sutherland, Jeff: Der Scrum Guide. Der gültige Leitfaden für Scrum: Die Spielregeln. Deutsche Ausgabe. 2017. S. 19. Download unter <https://www.scrumguides.org> (18.03.2019).