Durch Sieg über das Symptom dem Wurzelproblem unterlegen

In seinem Buch “Scrum A revolutionary approach to building teams” schreibt Jeff Sutherland von einem Kunden, dem er geholfen hat. Natürlich war dort großes Drama und Scrum hat es am Ende gerichtet. Schön zu lesen – dennoch bliebt bei mir ein unschöner Nachgeschmack.

Die Situation

So wird die Situation beschrieben:

“The people who would actually make [the software] happen only found out about [the deadline] after their president had promised Wall Street that the new system would be put in place on July 7, 2007. Come hell or high water.”

Es lag also ein klassisches “Fremdversprechen” vor: ein Manager hatte ein Ergebnisversprechen abgegeben, aber nicht für sich, sondern für andere, ohne die zu konsultieren. Wo Ergebnisversprechen allemal dieser Größenordnung ohnehin schon hochriskant sind, da hat er das Risiko noch gesteigert, indem er es ohne Rücksprache mit den eigentlichen Leistungserbringern abgegeben hat. Ich kann es nicht beschönigen: Das ist nicht nur dumm, das ist respektlos und gefährlich.

Natürlich wird diese Dummheit im Text begründet:

“Making the deadline was especially important to Medco, because  while they’d been the first to start automated mail-order pharmacies, they weren’t the only ones, and their competitors were hungry.”

Achso, klar, jetzt verstehen wir das. Es musste sein. So wie Eis von der Waffel nach unten tropfen muss. Wegen der Schwerkraft. Oder wie die Kompassnadel nach Norden zeigen muss. Wegen des Magnetismus.

Bullshit.

An der Deadline ist nichts, aber auch gar nichts Zwingendes. Sie ist völlig willkürlich.

Wie wäre es als Alternative gewesen, wenn Medco das System gebaut hätte, ohne es anzukündigen – und es hätte es dann mit einem Paukenschlag vorgestellt. Alle Wettbewerber wären doch aus den Latschen gekippt, oder? Warum denen überhaupt verraten, dass man an etwas Neuem arbeitet?

Oder wie wäre es gewesen, die Deadline mit den eigentlich darunter leidenden vorher mal abzusprechen? Das wäre mindestens in puncto Menschenführung sicherlich verträglicher gewesen.

Oder wie wäre es gewesen, mit dem Projekt 6 Monate früher zu beginnen? Solche strategisch wichtigen Themen sind ja gewöhnlich so überraschend wie Weihnachten. Wer sich davon überfahren fühlt, hat also wahrscheinlich irgendeinen Teil seines Jobs nicht richtig gemacht. Das könnte die Marktbeobachtung gewesen sein, das könnte aber auch plattes Zeitmanagement gewesen sein. Dass der Kommunikationsjob nicht gemacht wurde, steht ja außer Frage angesichts des Dramas.

So weit, so schlimm.

Aber jetzt die Krönung. Da bin ich lang hingeschlagen:

Die Symptomkur

Jeff Sutherland übernimmt. Es wird hin und her und her und hin überlegt, Männer raufen sich das Brusthaar, Frauen weinen… aber am Ende ist das Entwicklungsteam so mit der Velocity eingestellt und der Scope so zusammengestrichen, dass man auf Monate voraussagen kann, dass der Termin doch gehalten wird.

Darauf ruft der Senior Vide President aus:

“Let’s declare victory!”

Jeff Sutherland strahlt und berichtet davon stolz in seinem Buch.

WTF!

Da wird doch der Bock zum Gärtner gemacht. Was für eine verkehrte Welt!

Dass Medco hier einen Sieg sieht, verstehe ich. Von denen erwarte ich nichts anderes. Aber dass Jeff Sutherland das so berichten mag, dass er keine Kritik an der grundlegenden Praktik übt… nein, dafür habe ich kein Verständnis.

Scrum wird dargestellt als ein Werkzeug, mit dem man schlicht jeden Irrsinn gangbar machen kann.

Klar, es ist schön zu lesen, wie die einzelnen Scrum-Praktiken zusammengespielt haben, um das Team schneller zu machen. Da ist natürlich etwas dran. Das ist von zeitlosem Wert. Super!

Doch hier wird the power of Scrum eingesetzt, ohne das grundlegende Problem zu beleuchten. Da kann man in Scrum noch so viel reflektieren, wenn man das nicht angeht, dann ist am Ende nichts gewonnen.

In der Situation mit schon gestellten Weichen und auf die Wand zu rasendem Zug muss erst gehandelt werden. Bremse ziehen, Desaster verhindern. Doch die Reflexion muss dann alsbald einsetzen. Natürlich eine mit den Verantwortlichen. Die glauben doch nun, dass sie morgen noch irrsinnigere Versprechen machen können. Scrum ist doch eine Wunderwaffe, oder? Das liegt das Wurzelproblem: im Management. Astronautenmanagement, das über den Entwickler schwebt und Entscheidungen trifft, die alle anderen nur schmerzen. Das ist teuer, das ist gefährlich.

Fazit der Geschichte aus “Scrum A revolutionary approach”

Nein, sorry, damit bin ich gar nicht zufrieden, Jeff Sutherland. Hier wurde das Symptom mit Scrum erfolgreich behandelt. Dem Wurzelproblem wurde hingegen nicht nachgespürt. Wenn dennoch von victory gesprochen wird, ist das eine Irreführung, die nicht der Scrum-Sache dient.

Scrum soll transformativ sein in Bezug auf Unternehmen? Davon ist in diesem Beispiel leider nichts zu spüren. Eher das Gegenteil wird gezeigt: Scrum hilft, alte Praktiken zu erhalten, die riskant sind und Menschen unter enormen Druck setzen.

Der Einsatz von Scrum ersetzt einfach nicht gute Führung und echtes Bewusstsein für Verlässlichkeit.

Posted in Deutsche Beiträge and tagged , .

5 Comments

  1. Pingback: Weshalb schwache Einzelleistung ein Symptom für ein schwaches System darstellt? | Patrick Koglin

  2. Bzgl,. Rücksprache bin ich ganz bei dir. Das ist natürlich fatal.

    Aber nicht bzgl. der Timeline. Warum? Na, die Begründung lieferst du doch selbst: Man kann nicht sinnvoll schätzen! Folglich kann man eine völlig beliebige Deadline festlegen. Eine Deadline ist so gut und so unpräzise wie jede andere, und wenn die Deadline (welche auch immer) Priorität hat und feststeht, hat man – ceteris paribus – nur noch zwei Freiheitsgrade: Man kann die Qualität nach unten schrauben oder das Feature-Set kürzen. Welche Option würdest Du wählen?

    Das eigentliche Problem ist, daß du geschäftliche, nach Außen gerichtete Aspekte und Entscheidungen mit innerbetrieblichen, entwicklerseitigen Aspekten vermengst. Das ist m.E. nicht in Ordnung. Man kann über die Sinnhaftigkeit der Führungsentscheidung und die Art und Weise der Kommunikation wahrlich diskutieren, aber das ist definitiv eine andere Baustelle. Als Entwickler würde ich nicht behaupten wollen, daß ich immer alle Aspekte sachkundig beurteilen kann, die zu solchen Entscheidungen geführt haben. Das ist auch gar nicht meine Aufgabe als Entwickler, Product Owner, etc.

    Als Entwickler mag mur die Entscheidung nicht gefallen und ich werde auch meine Kritik in sinnvoller Art und Weise formulieren, aber es ist zuallererst meine Aufgabe, daraus etwas Sinnvolles zu machen. Immerhin habe ich auch die Möglichkeit, die entsprechenden Zahlen und Prognosen (die ich ja nicht abschätzen kann) zu kommunizieren, um damit auf die Auswirkungen der Entscheidung hinzuweisen. Das kann man aber auch konstruktiv machen.

    Man kann natürlich auch den Kopf einziehen und wie verordnet eine Logik in die Abgasanlage einbauen, damit die geplanten Werte auch “erreicht” werden … sollte man aber nicht. Denn das löst weder das aktuelle noch zukünftige Probleme und ist auch nicht im Sinne des Unternehmens. Ähnlichkeiten mit realen Ereignissen sind übrigens rein zufällig.

    • Da haben wir leider wohl unterschiedliche Ansichten. Eine Deadline ist nicht egal, weil sie quasi immer falsch ist. Das schiere Vorhandensein einer Deadline ist kontraproduktiv, wenn damit ein bestimmter Scope verknüpft ist. Denn das Erreichen von Deadlines hat immer höherer Priorität als das, was schwerer zu messen ist, als der Scope. Das ist bei Software z.B. die Wandlungsfähigkeit oder ganz allgemein Motivation, Freude, Nachhaltigkeit.

      Und wenn dann Agilität nach Sutherland auftritt, um grundlegend Organisationen zu verändern… dann finde ich es in die Tasche gelogen, dass “Sieg!” gerufen wird, wenn sich kranke Gewohnheiten eben nicht durch Scrum verändert haben – sondern sogar das Gegenteil eintritt.

      Als Entwickler bin ich aufgerufen (vgl. Robert C. Martin’s Programmer’s Oath, http://blog.cleancoder.com/uncle-bob/2015/11/18/TheProgrammersOath.html), nicht dem Business beliebig zu Willen zu sein. Missstände nur aufzeigen, reicht nicht. Wer mit dem Aufzeigen zufrieden ist, wäscht nur seine Weste rein. Am Ende, wenn alles schief gelaufen ist, meint er sagen zu können, “Ich hab’s gesagt und ansonsten nur Befehle ausgeführt.”

      Andererseits: So kann man natürlich auch leben. Ist ne freie Entscheidung. Nur darf man sich nicht wundern, wenn nichts besser, sondern eher alles schlimmer wird.

      • Moment mal.

        Deine Beschwerde war, dass die Deadline verordnet wurde, ohne Rücksprache zu halten, weil das Team ja hätte eine bessere Deadline vereinbaren können. Deine eigene Argumentation geht aber – zu recht – dahin, dass der reale Termin nicht schätzbar ist, weil sich der Korridor der Unsicherheit erst zu dem Zeitpunkt auf genua einen Wert verengt, wenn es wirklich geschafft ist. Die auf den ersten Blick merkwürdige, tatsächlich aber völlig logische Konsequenz daraus ist aber eben genau die, daß jeder (!) einzelne denkbare Endtermin einer Wahrscheinlichkeit unterliegt. Rein sachlich, also ohne die menschliche Komponente betrachtet: Welchen besseren (!) Termin hätte das Team also vorschlagen wollen?

        Scrum ist witzigerweise ja auch gerade dazu entwickelt worden, Features in festen, letztendlich willkürlich gewählten Timeboxes auszuliefern. Auch insofern kann ich die Kritik an der fixen Deadline nicht so ganz nachvollziehen. Wenn überhaupt, dann sehe ich in den Timeboxes eine empirische Bestätigung für Parkinsons Law .

        Wenn sich z.B. der Kunde seinerseits öffentlich committed, dass zum Zeitpunkt X die neue Anwendung online geht, dann ist das Gesetz. Ob der sich vorher auch rückgesprochen hat oder nicht, ist sicherlich diskutabel, aber ab diesem Zeitpunkt (!) eben nicht mehr wichtig – dann gilt es nur noch, den Termin zu halten. Wenn Du den Termin nicht halten willst, weil Onkel Bob was anderes sagt … genau, dann ist das deine Entscheidung. Das nächste Projekt wirst du dann aber nicht mehr machen, denn das Business, dem du nicht zu Willen sein willst, bekommt dann ein anderer.

        Es gibt – wieder ceteris paribus – eben genau diese drei Variablen: Zeit, Qualität und Feature-Set. Das ist genau wie bei CAP. Wenn ich eines davon festnagele, kann ich noch genau an einer anderen Schraube drehen um den Projektfortschritt zu steuern. Alles andere wird nicht funktionieren. Wenn uns das nicht gefällt, können wir das zwar ignorieren und probieren, ob wir die Velocity nicht doch noch schnell verdoppeln können, ohne dass die Qualität darunter leidet, die Realität wird sich aber deswegen nicht ändern.

        Natürlich ist eine geforderte Deadline UND ein geforderter Scope (UND die oft nicht erwähnte, aber implizit immer erwartete Qualität) kontraproduktiv, ich habe auch nie was anderes behauptet. Die Lösung besteht ja eben gerade darin, den Scope anzupassen, indem Features verkleinert, in das nächste Release verschoben oder auch ganz gestrichen werden. Wer Versprechen abgibt, die gegen diese vergleichsweise simple Erkenntnis verstoßen, handelt – mindestens – fahrlässig. Leider lassen sich aber eben viele Entwickler nicht nur meiner Erfahrung nach dazu zu leicht überreden, Und auch hier greift Scrum wieder, indem es klar kommuniziert, daß das Team eben im Zeitraum X nur soundsoviele Storypoints schaffen wird.

        Und wenn das Business zu dir kommt und verlangt “wir brauchen aber alle drei”, dann sollte und muß man ihnen eben beibringen, dass sie /das/ nicht bekommen werden – nicht von dir und auch von sonst keinem, weil es nicht geht. Das ist genau so sinnfrei wie die prioritätenlose und völlig unreflektierte Forderung “bei uns ist alles gleich wichtig”. Hier sollte man tatsächlich protestieren, meinetwegen auch mit dem Onkel im Schlepptau, den dass ist das sprichwörtliche “recipe for disaster” – oder für den Burnout. Je nachdem, wer zuerst fertig ist.

        • Nein, ich behaupte nicht, dass das Team eine bessere Deadline hätte nennen können.

          Wenn ich davon spreche, dass das Team hätte konsultiert werden sollen, dann deshalb weil es genau das gesagt hätte. Es hätte das Ergebnisversprechen verweigert und stattdessen ein Verhaltensversprechen gegeben (s. dazu ausführlich http://ich-verspreche.org).

          Und wenn der Kunde wie ein 3jähriger eine Deadline für Unmögliches setzt… nun, dann sehe ich es tatsächlich als Option, ihn eben nicht zu bedienen, sondern das Desaster anderen zu überlassen. Wer diese Freiheit sich im Leben nicht bemüht zu erarbeiten, der verliert die Fähigkeit zu ethischem Handeln. “Aber es war doch Befehl…” oder “Das war alternativlos…” sind genau die Sätze, die dann hinterher fallen, wenn es den Bach runtergegangen ist.

          Aber es steht jedem frei, solche Freiheit sich nicht zu erarbeiten – mit den jeweiligen Konsequenzen.

          Nassim Taleb meint, reich sei der, der sich über Geld, dass er nicht verdient, mehr freut, als über Geld, das er verdient. Ich stimme zu. Das ist die Art Reichtum, die ich anstrebe. Die bedeutet aber nicht, dass man Millionen auf dem Konto hat. Sie bedeutet nur, dass man sich eben erlauben kann, nach Grundsätzen zu handeln, statt nach Geldgesichtspunkten.

Comments are closed.