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.

Agile Toolbox
Scrum
Team
bgloger-redakteur
October 21, 2013

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen