Die Scrum Probleme Teil 1: Scrum allein reicht nicht aus

Wenn Sie sich sehr gut mit Agilen Methoden auskennen, dann wissen Sie schon längst, dass diese Dinge weder der Heilige Gral noch der allein selig machende Weg sind. Sowohl Kanban als auch XP als auch Scrum haben Schwächen. Sie können nicht alle Fragen beantworten, und sie sind nicht die Lösung für jedes Problem. Ich möchte nach und nach ein paar der Schwächen oder Ungereimtheiten ansprechen und Ihnen vielleicht auch hier und da den einen oder anderen Weg aus der Krise zeigen.

Beginnen wir mit dem für mich vielleicht größten Problem bei Scrum: Es lässt Sie in vielen Detailfragen im Regen stehen. Da es sich um ein Projektmanagement-Framework handelt, das Sie selbst mit Leben füllen müssen, wird Ihnen lediglich ein grober Rahmen vorgegeben, in dessen Grenzen Sie agieren müssen. Wie Sie das tun, bleibt komplett Ihnen überlassen.

Die Scrum-Regeln passen auf einen Bierdeckel (wenn Sie sehr klein schreiben), daher scheint es sehr einfach zu sein, aber der Teufel steckt im Detail. Kleines Beispiel gefällig?

Scrum spricht von einem priorisierten Backlog, in dem Sie Ihr Projekt planen. Mehr sagt es nicht. Wie das auszusehen hat, und wie zur Hölle Sie die Einträge sinnvoll priorisieren können, bleibt vollkommen Ihnen überlassen. In der Praxis haben sich User Stories weitestgehend durchgesetzt, dass Sie zu einem Quasi-Standard geworden sind. Wussten Sie überhaupt, dass man ein Backlog z.B. auch mit Use Cases füllen kann?

Für die Priorisierung finden Sie in einigen Büchern die Nutzen-Risiko-Matrix. Vielleicht funktioniert für Sie das Kano-Modell aber besser. Vielleicht ist eine Matrix für Sie und Ihr Projekt ein vollkommen ungeeignetes Mittel, eine sinnvolle Priorisierung zu erarbeiten.

Was diese Dinge betrifft, finden Sie einige bewährte Praktiken in der Literatur. Wenn es um die Frage der Softwareentwicklung geht, müssen Sie sowieso über den Tellerrand hinaus blicken und sich ggf. bei XP bedienen. Pair Programming lässt sich auch im Rahmen von Scrum wunderbar einsetzen.

Das Problem ist nicht, dass es sich bei Scrum um ein Framework handelt. Das wird klar kommuniziert. Das Problem tritt auf, wenn man annimmt, dass Scrum allein ausreichen würde, alle Fragen zu beantworten, oder wenn man die Quasi-Standards für echte Standards hält und versucht diese auf das eigene Projekt anzuwenden, obwohl sie darauf kaum anwendbar sind.

Gehen wir einfach mal einige Ungenauigkeiten durch.

1. Scrum spricht von priorisierten Product- und Sprint Backlogs, verliert aber kein Wort darüber, wie diese auszusehen haben. Ich kann Ihnen nur dazu raten, sich nicht sklavisch an User Stories zu halten. Refactorings können Sie damit nur äußerst schwer ausdrücken (auch wenn die Versuche sehr lustig sein können). Behalten Sie einfach im Hinterkopf, dass jeder Eintrag entweder dem Nutzer oder dem Projekt selbst Nutzen bringen muss.
2. Scrum sagt nichts darüber, wie ein Daily auszusehen hat, außer dass es vorzugsweise am Scrum-Board stattzufinden hat, worüber es aber ebenso wenig sagt. Das Daily Scrum muss nicht zwingend ein 15 minuten Standup Meeting sein. Auch hier gibt es andere Möglichkeiten. ich habe auch schon gesehen, dass die Entwickler jeden Morgen gemeinsam gefrühstückt und dabei ihre Besprechung abgehalten haben.
3. Dei Retrospektive dient laut Scrum dazu, den Prozess zu verbessern. Scrum Master und Team setzen sich zusammen, um den letzten Sprint zu besprechen. Und dann? Wie man innerhalb eines solchen Meetings überhaupt zu sinnvollen Ergebnissen kommt, und wie man vermeidet, dass die ganze Sache eines dieser üblen Labermeetings wird, bleibt völlig im Dunkeln. Der einfachste Weg ist, sich einfach an den Fragen »Was war gut?«, »Was war schlecht?« und »Wie können wir es besser machen?« entlang zu hangeln. Wie man da zu sinnvollen Ergebnissen kommt, und wie man auch die stilleren Mitglieder des Teams zum Mitmachen bekommt, bleibt Sache des Scrum Masters. Diesem ist nur dringend dazu zu raten, eine Menge über Moderation zu lernen.

Das sind nur einige Beispiele für die Ungenauigkeiten. Sowohl Scrum als auch Kanban und XP haben eine ganze Reihe von Schwächen und Problemen. Ich werde im Rahmen dieses Blogs in den nächsten Wochen auf einige genauer eingehen, z.B. die Sache mit dem Testen oder die Frage der Skalierung.