Dieser Satz aus dem Scrum Guide hat mich zum Nachdenken gebracht:
„Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, sodass Verbesserungen vorgenommen werden können.“
Seit etwa 10 Jahren nutze ich Scrum. Ich habe verschiedene Verantwortungen im Rahmen von Scrum innegehabt und Scrum in Unternehmen aus unterschiedlichsten Branchen eingeführt. Ich habe die Erfolge erlebt, die Teams damit erzielen konnten, aber auch erfahren, wie Unternehmen damit gescheitert sind.
Besonders zum Nachdenken gebracht hat mich die Wirksamkeit von Management, Umgebung und Arbeitstechnik, die durch Scrum sichtbar gemacht wird.
Hier meine drei Erkenntnisse:
Erkenntnis #1: Nicht schätzen, sondern verkleinern
An keiner Frage wird die Wirksamkeit des bisherigen Managements sichtbarer. Auch die Fortschritte bei der Einführung von Scrum werden hier deutlich:
„Wie können die Entwickler ihre Arbeit genauer schätzen?“
Je nachdem, von wem die Frage gestellt wird und wie häufig sie gestellt wird, liefert sie mir einen Hinweis darauf, wie gewinnbringend agiles Produktmanagement bereits genutzt wird. In den Unternehmen, in denen ich gearbeitet habe und die agiles Produktmanagement erfolgreich nutzen, wird eine andere Frage gestellt:
„Wie können wir die Arbeit kleiner schneiden?“
Menschen sind erstaunlich schlecht darin, den Aufwand von Arbeit zu schätzen. Und im Kern ist das doch der Grund, warum Projektmanagement bei Software versagt hat und warum Scrum so populär geworden ist. Der Fokus liegt nicht mehr darauf, wann etwas fertig sein wird. Stattdessen geht es darum, wie wir es in kleinere Teile aufteilen können. So wird sichergestellt, dass der wichtigste Teil im nächsten Sprint geliefert wird. Damit wir schneller als unsere Konkurrenz lernen können, was wir übersehen haben, damit unsere Kunden und Nutzer erfolgreich sind.
Erkenntnis #2: Mehr Entscheidungen bedeuten mehr Fortschritt
Häufig wird Scrum als Prozessrahmenwerk beschrieben.
Was nicht ganz stimmt, oder? Besser wäre, es als Rahmenwerk zu bezeichnen, mithilfe dessen Prozesse überprüft und angepasst werden. Prozesse sollten niemals dem Selbstzweck dienen. Wir sollten uns also fragen, welchem Zweck die Prozesse dienen, die wir mit Scrum steuern wollen.
Aus meiner Sicht gibt es hierfür nur eine Antwort:
Risikominimierung in der Produktentwicklung. Produktentwicklung ist hochgradig risikobehaftet. Dieses Risiko zu minimieren, ist überlebenswichtig für Unternehmen. Und genau das ist der wahre Zweck von Scrum. Wie hilft es uns dabei?
Die Nutzung von Scrum beschleunigt Entscheidungen.
Hier drei Beispiele, wie Scrum schnelle Entscheidungen forciert:
- Die Verantwortung des Product-Owners: Eine einzelne Person – kein Komitee – trifft schneller Entscheidungen.
- Sprintlänge: Alle 30 Tage müssen wir erneut entscheiden, was das nächste lohnenswerte Ziel sein soll.
- Timeboxen: Spätestens nach 3 Stunden muss eine Entscheidung getroffen sein, wie das Scrum Team im nächsten Sprint besser zusammenarbeiten kann.
Erkenntnis #3: Unternehmen sind keine Tanker, sondern Schneebälle
Wusstest du, dass Supertanker bis zu 6 Kilometer brauchen, bis sie zum Stillstand kommen, und einen Wendekreis von 2 Kilometern haben?
Ich auch nicht. Musste ich googeln. Die Analogie, dass Unternehmen wie Tanker sind, hinkt. Wird diese Analogie genutzt, um Unternehmen zu beschreiben, dann drückt sie aus, dass sie viel Masse haben, die sich schwer manövrieren lässt. Das Problem daran? Es suggeriert, das wäre immer so und wir könnten es nicht ändern. In vielen Unternehmen mag das zutreffen. Aber Unternehmen sind nicht wie Tanker, sondern wie Schneebälle, die wir durch den Schnee rollen. Was passiert dabei? Sie werden größer und schwerer. Und immer schwieriger zu bewegen.
Je länger ich mit Scrum arbeite, desto mehr glaube ich das. Die Aufgabe eines Scrum Masters besteht darin, genau das zu verhindern. Um beweglich zu bleiben, müssen Unternehmen schlank bleiben. Das ist der beste Grund für Agilität.
Die Aufgabe eines Scrum Masters ist also, einen Weg zu finden, den Schneeball zu rollen, ohne dass er größer wird.
Drei Beispiele, wie wir damit beginnen können:
- Warum nicht das Product-Backlog auf eine gewisse Länge beschränken? Sagen wir: 30 Einträge. Soll ein neuer Eintrag hinzugefügt werden, müssen wir oder die Stakeholder die Frage stellen, welcher stattdessen gelöscht werden soll.
- Warum nicht in der Sprint-Retrospektive fragen, wie wir einen Prozessschritt in der Entwicklung im nächsten Sprint weglassen und trotzdem dieselbe Qualität liefern können?
- Wenn die Stimmen laut werden, dass wir nicht genug Mitglieder im Team haben, sollten wir handeln. Warum nicht die Frage stellen, welche Aufgaben sich automatisieren lassen? Oder wir überlegen, wie wir gemeinsam Aufgaben effektiver erledigen können.
Fällt dir noch eine weitere Idee ein, wie Scrum Master dieses Paradoxon beherrschen können? Dann schreibe sie in die Kommentare. Damit unterstützt du andere Scrum Master bei der Beseitigung von Hindernissen. Alle Unwirksamkeiten des aktuellen Managements, der Umgebung und der Arbeitstechniken werden durch Scrum aufgezeigt. Diese Unwirksamkeiten sind Hindernisse. Diese Hindernisse gilt es, schrittweise aufzulösen.