Kein Allheilmittel?

Wenn ich mit Kollegen rede oder auch Veröffentlichungen lese, habe ich sehr oft den Eindruck, dass die einen Scrum als Allheilmittel darstellen (oder herbei reden), während die andere Seite es in Grund und Boden verteufelt. Vermutlich haben beide unrecht.

Auch wenn das jetzt wie die übliche Schwarz-Weiß-Denke klingt, ein wenig polarisieren muss man schon. „Machen Sie sich erst einmal unbeliebt, dann werden Sie auch ernst genommen!“ soll Konrad Adenauer mal gesagt haben. Man könnte natürlich auch sachlich diskutieren, aber das beinhaltet das Risiko, sich von einer gegenteiligen Meinung überzeugen lassen zu müssen …

Also gut, bleiben wir mal sachlich. Was macht denn den Unterschied zwischen den neumodischen agilen Methoden und dem klassischen Projektmanagement aus? Zumindest bei den Zielen sind sie sich wohl noch einig: „Ich will ein bestimmtes Ergebnis haben, möglichst schnell, möglichst gut und möglichst billig!“ Nur den Weg dorthin gehen beide auf unterschiedliche Weise. Ich will das mal aus meiner Sicht darstellen, und damit keineswegs behaupten, dass dies die allein seligmachende Ansicht sei. Ja, ich bin ein Fan von agilen Methoden wie z.B. Scrum.

Das Problem

Für mich ist das entscheidende Problem der klassischen Methode, dass hier vorab ein Plan gemacht wird, wie das Projekt abzulaufen hat. Das erinnert mich stets an den 5-Jahres-Plan, der für uns im Westen eine der wenigen Sachen war, die wir über die DDR wussten. Dort werde, so die Legende, alles geplant, was volkswirtschaftlich in den kommenden 5 Jahren zu passieren habe. Ebenso wurde erzählt, dass das alles nicht wirklich funktioniert hatte. Die DDR gibt es nicht mehr, aber China, Indien und Vietnam halten es laut Wikipedia noch heute so.

Projektpläne

Die viel gepriesenen oder — je nach Sichtweise — viel geschmähten Projektpläne haben in der Regel eine kürzere Laufzeit, kranken aber meiner Ansicht nach an dem selben Problem: „Wesentlicher Kritikpunkt an Plänen ist, (…) dass es grundsätzlich unmöglich ist, die Komplexität einer gesamten Volkswirtschaft zu erfassen und auf Jahre hinaus zu planen.“ (Zitat aus dem oben verlinktem Artikel). Nun ist nicht nur die Volkswirtschaft komplex, auch ein Projekt ist nicht unbedingt so trivial, wie man es gern hätte.

Aus meiner Sicht als Softwareentwickler zeigt sich dies besonders dann, wenn ein Problem gelöst werden soll, und die Verfahrensweise, die ich mir ausgedacht habe, einfach nicht funktionieren will. Doch wie kann das sein? Wie kommt es, dass ein Softwareentwickler Fehler macht bei der Einschätzung, wo er das doch jeden Tag macht, und das seit 20 Jahren? Aber ist das wirklich so, dass ein Programmierer jeden Tag das selbe macht?

Um der Sache die Krone aufzusetzen, wird anstelle von ein paar Eckdaten gern versucht, jede Kleinigkeit einzuplanen. Und da fängt es an, in’s Absurde abzugleiten.

Software ist anders

Bei der Softwareentwicklung wird es nur höchst selten vorkommen, dass ich heute genau dieselbe Funktion wie vor einer Woche programmiere. Bitte genau hinhören; ich habe nicht gesagt „dieselbe Funktion benötige“, sondern „dieselbe Funktion programmiere“! Das ist ein entscheidender Unterschied. Warum?

Dass Software leicht zu kopieren ist, weiß inzwischen wohl jedes Kind. Das gilt selbstverständlich auch für die kleinen Teile von Software, die Funktionen, Methoden, Klassen, etc. Wer also einmal eine Klasse geschrieben hat und erneut vor derselben Aufgabe  steht (meistens als Teil einer größeren Aufgabe), der kann diese Klasse ohne Schwierigkeiten aus einem anderen Projekt in das aktuelle hinüber kopieren. Dazu wird in der Regel nur ein Bruchteil der Zeit benötigt, die für das Programmieren aufgewendet wurde. Das wissen Programmierer, und die meisten werden sich wohl auch so verhalten. Das ist also nicht das, was immer so viel Zeit kostet.

Ganz anders sieht die Sache aus, wenn ich eine Aufgabe lösen muss, die ich noch nicht (oder noch nicht so) gelöst habe. Dann muss ich nachdenken, recherchieren, probieren, testen, refaktorieren … füge hier einfach alle gängigen Schlagworte ein, die du je von einem Programmierer gehört hast. Man sieht schon: Sowas dauert!

Wenn ich diese „neue Sache“ also noch nie gemacht habe, woher soll ich dann die Erfahrung haben, wie lange es dauert? Und dann stellen wir uns vor, dass mein Projekt aus einer Vielzahl solcher neuen kleinen und mittelgroßen Aufgaben besteht.

Zeitabschätzungen

Jede Zeitabschätzung, das geht schon aus dem Wort hervor, ist eine Schätzung, eine Prognose. Sie kann stimmen, aber viel wahrscheinlicher werde ich mehr oder weniger stark daneben liegen. Werden viele Aufgaben auf diese Weise geschätzt, summiert sich der Fehler auf, bis am Ende vielleicht eine ganz erhebliche Abweichung vom tatsächlichen Zeitbedarf entsteht. Und dann geht der Ärger los.

Sie haben doch gesagt, Sie brauchen eine Woche. Und jetzt sind es schon doppelt so viel! — Der Chef so.

Dabei hat er sich die Suppe eigentlich selbst eingebrockt. So wenig Sinn es hat, einen Meteorologen nach dem optimalen Standort für den Grill zu fragen (weil der Mensch ja wissen muss, wann und wo der Blitz einschlagen wird, der hat das ja studiert), so sinnlos ist es auch, einen Mitarbeiter um eine hochgenaue Zeitschätzung einer Arbeit zu bitten, die er noch nie gemacht hat. (Respektive „sie“, „Chefinnen“, „Mitarbeiterinnen“ und natürlich „Meteorologinnen“. Die politisch korrekten Varianten lasse ich der Einfachheit halber mal weg, du weißt sicher auch so, was ich meine.)

Wer also unbedingt eine Schätzung haben will, der kann genauso gut nach einem Würfelbecher fragen, das ist billiger und geht erheblich schneller als ein Meeting. Und wer allen Ernstes eine verlässliche Schätzung (was für sich genommen ja schon ein Oxymoron ist) verlangt, den sollte man vielleicht mal zum Psychiater schicken. Nicht einmal die Deutsche Bahn schafft das, und das, obwohl sie die Strecken täglich ein Dutzend mal abfährt. Es ist immer die selbe Strecke, da werden die doch wohl langsam wissen, wie lange das dauert!

Stimmt, im Grunde wissen sie das ja auch; sehr genau sogar, denn die Belegung der Streckenabschnitte wird perfekt aufeinander abgestimmt. Das geht bis zu der klaren Vorgabe, welcher Zug auf welchem Streckenabschnitt wie schnell fahren darf. Aber wehe, es kommt etwas dazwischen. Da kann eine Verspätung an einer Stelle sich schnell auf mehrere andere Strecken auswirken. Und auf dem Weg von München nach Hamburg kann eine Menge passieren!

Zwischenfälle

Auch bei Projekten kommt mal was dazwischen. Sei es ein Marketingmitarbeiter, dem im allerletzten Moment noch einfällt, dass er ja ein ganz wichtiges Feature vergessen hat zu erwähnen. Der Kunde hat aber nur unter der Voraussetzung bestellt, dass dieses Feature drin ist, und jetzt droht der ganze Auftrag zu platzen. Man kann sich vorstellen, dass sich in diesem Moment der schöne Plan in Luft auflöst. Nichts stimmt mehr, keine Zahl ist noch verlässlich. Das wäre selbst dann so, wenn die Mitarbeiter exakt korrekte Abschätzungen abgeliefert hätten. Und hier kommt Scrum in’s Spiel.

Anstelle eines riesigen Planes vorab werden bei Scrum lediglich überschaubare Streckenabschnitte geplant, in der Regel maximal 4 Wochen. Der zweite Punkt, der mindestens ebenso wichtig ist, ist der Verzicht auf den einen oder anderen Teil der Software, wenn man es doch nicht ganz schafft. Aber was drin ist, ist fertig, und das heißt programmiert, dokumentiert, getestet und für gut befunden. Und wenn der eine „Sprint“ (so nennt man so einen Abschnitt) fertig ist, geht es mit dem nächsten los. Für den wird wieder nur das geplant, was in Frage kommt.

Der Nachteil ist sicher, dass niemand weiß, wo wir am Jahresende stehen werden (bestenfalls kann zu Quartalsende eine halbwegs verlässliche Aussage getroffen werden). Streng genommen weiß das auch im klassischen Projektmanagement niemand. Aber durch die ganz vielen mit sauberem Stift und Lineal geschriebenen und gemalten Zahlen und Diagramme sieht es so aus, als ob das alles haarklein geplant wäre.

Und genau das ist es auch: Ein Plan. Mehr nicht.

Die Scrummies wissen das.


SmallInvoice Logo

Ähnliche Artikel:

AuthorChristoph Jüngling

Selbständiger Softwareentwickler und Seminarleiter

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

7 − vier =