Das Humpty Dumpty Syndrom

"Humpty Dumpty saß auf dem Eck, Humpty Dumpty fiel in den Dreck und auch der König mit seinem Heer, rettete Humpty Dumpty nicht mehr."

Quelle: https://de.wikipedia.org/wiki/Humpty_Dumpty

Der moderne Humpty Dumpty

924px-Denslow's_Humpty_Dumpty_1904.jpg

Kennt ihr das? Ihr merkt früh, dass in eurer Entwicklung etwas in Schieflage gerät und eigentlich muss man jetzt etwas verändern. Ihr sprecht es an und bekommt die Rückmeldung: "Keine Panik, das wird nicht passieren und wenn es passiert, dann hau' ich euch mit Manpower raus!" Eventuell setzt man noch eins drauf: "Bitte behalte deine Gedanken bzgl. dieses Problems für dich, sonst machen sich die Leute nur sorgen."

So in der Art geht es dem guten Humpty Dumpty von Alice im Wunderland auch. Er weiß zwar, dass er auf einer dünnen Mauer sitzt und für ihn als Ei das mehr als gefährlich ist, aber er verdrängt es. Zudem ist er der Meinung: Mein König haut mich da schon wieder raus.

Jetzt sitzt ihr also sprichwörtlich auf einem schmalen Grat mit der Hoffnung, dass euch euer König raushaut, wie Humpty Dumpty. Auch wenn das manchmal gut gehen kann, wird doch viel zu oft der Grat auf dem ihr sitzt schmaler und schmaler.

Der Sturz

Wer spät in der Entwicklung reagiert, der verursacht meist mehr Schaden als Nutzen (vgl. B. Brooks Law). Das Problem mit dem man oft konfrontiert ist, ist laut Gerald M. Weinberg und Brooks:

"Managers are often foolishly optimistic about things going well. Moreover, when thing do go poorly, manager imagine that they will get better by themeselves."

Das Problem wird nicht erkannt und selbst wenn es erkannt wird, dann fehlt das Wissen damit umzugehen. Sie verfallen in das Humpty Dumpty Syndrome. Abwarten, verzögern und auf Wunschdenken spielen.

Wenn dann letztlich anerkannt wird, dass ein Problem existiert, dann wird massiv gerudert. Was das System durch nicht-lineare Effekte aus den Fugen brechen lässt. Weinberg dazu:

"Instead of merely making the project late, a sufficiently foolish manager can make the project collapse."

Das Problem wird mitunter dadurch verstärkt, dass die erzeugten Änderungen sowohl die Arbeitslast erhöhen als auch die Effektivität der Arbeitenden verringern. Zudem führt ein zu langes Abwarten dazu, dass Änderungen kaum mehr Effekt haben, außer man macht sie groß, was dazu führt, dass jede Menge nicht-lineare Seiteneffekte auftreten.

Früh mit kleinen Schritten

Arbeitet man früh mit dem Feedback aus dem System, indem man die Signale der Menschen wahrnimmt, so lässt sich schnell und leicht entgegen arbeiten und man hat sogar noch Zeit zum Experimentieren. Mit frühen Änderungen lassen sich insbesondere positive Feedback-Zyklen durchbrechen, sodass diese keinen größeren Schaden anrichten können.

Ein Beispiel

Zwei Abteilungen arbeiten zusammen: Frontend und Backend. Das Frontend-Team muss das Backend stetig integrieren und ist stark vom Wissen über deren Schnittstelle abhängig. Die Integration läuft schleppend bis gar nicht, ein echter Test kann nicht stattfinden. Ein kleiner Schritt wäre jetzt das Komponenten-Team Frontend zu einem echten Feature-Team zu machen, indem man eine Person aus dem Backend-Team hinzufügt. Integration, Done und die Lieferfähigkeit wären gestärkt durch eine kleine Änderung des Team-Setups hin zu Cross-Funktionalität.

Unterlässt man das und verschleppt sich die Integration weiter und damit die fertiggestellten Features (partially done == waste), so steigt die Tendenz eine große Änderung vor Schluss zu tätigen. Beispielsweise erkennt man die Not der Integration und setzt weitere Teams (z. B. Integration, Test) auf. Oft explodieren an der Stelle dann nicht nur die Kosten, sondern das gesamte System. 

SVNWNK

Literatur