Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Scrum – wider die Methodenfixierung

Je öfter ich agile Implementationen begleite, desto deutlicher wird für mich: Es geht nicht um Scrum. Oder anders gesagt: Das Reden über Scrum lenkt die Aufmerksamkeit von den eigentlichen Themen ab.

In meinem ersten Job war ich ScrumMaster eines neu geformten Scrum-Teams. Ich weiß noch genau, wie viel Zeit ich damals darauf verwandt habe, von Anfang an alles richtig zu machen. Vom Storywriting über das Schätzen bis hin zum Commitment – mein Team hinterfragte beinahe alles – und ich setzte meine gesamte Energie ein, um ihnen zu erklären, warum man das „mit Scrum“ nun so machen muss. Auf diese Weise haben wir es geschafft, die ersten Sprints über nichts anderes als Scrum zu diskutieren. Gibt es eine bessere Form, unproduktiv zu sein?

Viele behaupten immer noch, Scrum sei eine Methode oder ein Prozess. Typischerweise geht damit die Forderung einher, man müsse, gerade am Anfang, Scrum „by the book“ machen, um erfolgreich zu sein. Zugegeben: Das Befolgen von eng gesteckten Regeln schafft Sicherheit, indem es unerfahrenen Teams einen Rahmen gibt. So diskutieren wir nicht lange, ob fünfzehn Minuten Daily oder eine Sprint-Retrospektive Sinn machen –  wir tun es einfach.

Problematisch wird dieser Ansatz dann, wenn Scrum zum Zweck an sich verkehrt und dadurch zum unhinterfragbaren Dogma erhoben wird. Kritik des Teams wird dann mit der Begründung abgeschmettert, Scrum erlaube das nicht. Was dann passiert, ist leicht auszumalen: Das Team beginnt, Scrum in Frage zu stellen und es als Grund ihrer Unzufriedenheit zu betrachten.

Anstatt mit Scrum wie mit einem roten Tuch vor den Augen unserer Teams hin und her zu wedeln, sollten wir uns viel intensiver mit ihren Problemen auseinander setzen. Woran krankt die Produktentwicklung gerade? Was kann mein Team schon richtig gut? Und wo braucht es jetzt Hilfe? Wenn wir bei solchen Fragen starten, werden wir Scrum einsetzen können, ohne wirklich über Scrum reden zu müssen.

Ich habe kürzlich mit meinem neuen Team ein Backlog Grooming durchgeführt, ohne davon zu erzählen. Es hat einfach gerade gepasst. Mein Team wollte die nächsten Schritte besprechen und wäre – ganz klassisch – eine Excel-Tabelle mit dem Projektleiter durchgegangen. Im Backlog Grooming geht es darum, das Product Backlog so zu überarbeiten und zu pflegen, dass es aussagekräftig und handlungsweisend bleibt. Doch anstatt das zu erklären, habe ich die Teammitglieder gebeten, die aktuellen Themen auf einem Flipchart in ihren eigenen Worten zu formulieren, sie dann gemeinsam zu besprechen und schließlich zu priorisieren.

Meine Hypothese: Wenn es uns gelingt, Scrum besser mit dem Bedarf der Teams zu verknüpfen, dann erschließt sich der Sinn der Artefakte, Meetings und Rolle von selbst. Scrum wird dann nicht mehr als vorgeschriebener Overhead, sondern als Stärkung, als passendes Mittel zur passenden Zeit wahrgenommen. Wenn uns das gelingt, dann können Teams Scrum dafür nutzen, wofür es eigentlich gedacht ist: Als Rahmenwerk, mit dessen Hilfe Ballast abgeworfen und die regelmäßige Weiterentwicklung von Produkten endlich in Mittelpunkt allen Tuns steht.

Ein Tipp zum Schluss: Skizziere auf einem Blatt Papier, wo dein Team gerade steht und welches eine Ziel du mit deinem Team nächste Woche erreichen möchtest. Achtung: Deine Ziele dürfen nicht astronomisch sein, sondern müssen den Möglichkeiten deines Systems entsprechen. Ich kann 100 Meter in 11 Sekunden laufen – 10 Sekunden sind für mich außer Reichweite. Unter dem Stichwort SMART verbergen sich fünf Eigenschaften guter Ziele: Spezifisch, messbar, erreichbar, relevant, zeitlich terminiert.

Wie sieht dein Ziel aus? Vielleicht geht es um eine bessere Einbindung von Teammitgliedern, vielleicht geht es um mehr Zuverlässigkeit in der Lieferung oder um mehr Qualitätsbewusstsein. Egal, was es ist: Überlege dir dann in einem zweiten Schritt, wie du dieses Ziel gemeinsam mit deinem Team erreichen kannst, ohne ein Wort über Scrum zu verlieren. Überlege dir nach Bedarf auch ein Alternativszenario, einen Plan B: Was mache ich, falls mein ursprünglicher Plan nicht funktioniert?

Lass Scrum ruhig im Hintergrund, als Prinzip, vom dem du überzeugt bist, wirken. Nutze Scrum, um dir bei deinen Entscheidungen zu helfen. Ziehe die Inspiration für dein Tun aus Scrum. Aber belästige dein Team nicht damit. Es hat vermutlich andere Sorgen. Setz dich statt dessen mit deinem Team zusammen, sag ihnen offen und ehrlich, wo genau du momentan Handlungsbedarf siehst, was du mit ihnen erreichen möchtest, und arbeiten dann mit ihnen, so lange es nötig ist, an der Erreichung des Ziels. Du wirst dich wundern, wie schnell das Arbeiten nach Scrum zu einer Banalität wird, die keiner mehr hinterfragt.