Letzte Woche wurde ich gebeten, kurzfristig ein weiteres Projekt zu unterstützen.
Da meine Zeit begrenzt war, stellte ich in der Auftragsklärung nur drei Fragen:
- Welches Problem soll gelöst werden?
- Wie lange arbeitet ihr bereits daran?
- Was wurde bisher geliefert?
Nach dem Lesen der Antwort dachte ich mir im Stillen:
„Habt ihr schon einmal darüber nachgedacht, euren Scrum Master zu feuern? Sechs Sprints Arbeit. Für Stakeholder nutzbar: ein Design-Mock-up. Überschlagen lag der Preis dafür bei rund 300.000 Euro.“
Das klingt hart. Aber seien wir ehrlich: Wenn ich mein Auto in die Werkstatt bringe, erwarte ich Professionalität. Eine klare Diagnose. Auskünfte darüber, was dazu führen kann, dass die Reparatur länger dauert. Und regelmäßige Fortschrittsmeldungen.
Warum akzeptieren wir bei Scrum Mastern oft deutlich weniger?
Die folgenden zehn Warnsignale helfen Führungskräften zu erkennen, ob sie in einen professionellen Scrum Master investieren – oder 100.000 Euro im Jahr für einen gut bezahlten Team-Sekretär ausgeben.
Los geht’s:
Warnsignal #1: Es gibt keine ersichtlichen Business-Cases
Warum arbeitet dieses Team eigentlich an genau diesem Produkt?
Bevor Unternehmen Zeit, Geld und Menschen binden, sollte eine Frage beantwortet sein:
Warum lohnt sich diese Initiative?
Die Antwort muss nicht die Form eines Business-Case haben. Es reicht auch
- ein Produktziel,
- ein Geschäftsproblem,
- eine Vision oder
- ein Business-Model-Canvas.
Dass es gar kein „Warum“ gibt, ist selten. Viel häufiger ist es vorhanden, aber nicht transparent für Entwickler, Stakeholder oder Kunden. Genau hier beginnt die Verantwortung des Scrum Masters. Im Scrum Guide heißt es dazu ausdrücklich:
„Der Scrum Master dient dem Product Owner [] bei der Etablierung einer empirischen Produktplanung für ein komplexes Umfeld zu helfen.“
Ohne Ziel kann nicht empirisch geplant werden.
Führungskräfte, die dieses Warnsignal ignorieren, riskieren, „planlos“ Budget zu investieren.
Warnsignal #2: Produktrisiken werden nicht sichtbar gemacht
Welche Risiken gehen wir hier eigentlich ein?
Nachdem wir das „Warum“ einer Initiative geklärt haben, sollten wir deshalb fragen:
Wo kann dieses Produkt scheitern?
Bei der Produktentwicklung gibt es immer vier Risiken:
- Wertrisiko: Erkennt der Kunde den Nutzen und zahlt dafür?
- Verwendbarkeitsrisiko: Können Nutzer das Produkt verstehen und effektiv einsetzen?
- Umsetzbarkeitsrisiko: Sind Technik, Wissen und Ressourcen ausreichend vorhanden?
- Unternehmensrisiko: Passt das Produkt zum Geschäftsmodell, zum Markt und zum regulatorischen Rahmen?
In Scrum werden Risiken nicht durch mehr Planung eliminiert, sondern durch frühes Sichtbarmachen.
Genau dafür trägt der Scrum Master Verantwortung. Er sorgt dafür, dass Product-Backlog, Verantwortlichkeiten und Definition-of-Done gezielt genutzt werden, um Risiken offenzulegen. So kann das Team diese sofort adressieren.
Bleiben diese Risiken verborgen, sollte das ein Warnsignal für Führungskräfte sein. Sie investieren mehr und mehr Geld in eine Initiative, die sich am Ende doch noch zu einem großen Flop entwickeln kann.
Warnsignal #3: Das Product-Backlog ist ungeordnet
Ein Product-Backlog ist keine To-do-Liste.
Es dokumentiert Entscheidungen. Seine Ordnung zeigt, welcher Eintrag vor einem anderen kommt.
Diese Ordnung kann durch unterschiedliche Prioritäten begründet sein:
- größtes Risiko für das Unternehmen,
- größter erwarteter Kundennutzen,
- höchste technische Unsicherheit oder
- eine bewusste Kombination daraus.
Welche Priorität gewählt wird, entscheidet der Product-Owner.
Kritisch wird es, wenn diese Entscheidung fehlt oder nicht erklärt werden kann. Genau hier liegt die Verantwortung des Scrum Masters. Im Scrum Guide heißt es deshalb:
„Der Scrum Master dient dem Product Owner [...] bei der Suche nach Techniken zur effektiven Definition des Produktziels und zum Product-Backlog-Management zu helfen.“
Ohne begründete Ordnung arbeitet das Team zwar viel, aber nicht zielgerichtet. Führungskräfte, die dieses Warnsignal ignorieren, bezahlen dafür, dass das Team Arbeit erledigt. Aber ist diese auch wertvoll für das Unternehmen?
Warnsignal #4: Die Definition-of-Done beschreibt nicht die Lieferfähigkeit
Ist dieses Produkt wirklich fertig – oder nur entwickelt?
Hinter jedem Eintrag im Product-Backlog stecken Annahmen. Viele davon bleiben unsichtbar, solange sie nicht überprüft werden.
Typische Annahmen sind:
- Nutzer verstehen die neue Funktion sofort.
- Die Bedienung ist intuitiv genug.
- Die technische Lösung skaliert unter Last.
- Tests decken reale Nutzung ab.
- Das Produkt kann tatsächlich ausgeliefert werden.
Diese Annahmen sind Risiken. Und nicht alle Risiken verschwinden durch reine Entwicklung. Viele verschwinden erst dann, wenn Nutzer das Produkt verwenden, – oder werden erst dann sichtbar.
Hierfür gibt es in Scrum die Definition-of-Done.
Die Verantwortung des Scrum Masters ist es, sicherzustellen, dass sie beschreibt, was es heißt, lieferfähig zu sein – nicht nur „fertig programmiert“.
Bleibt die Definition-of-Done vage, existiert nicht oder beschreibt nur „fertig programmiert“, dann sollten Führungskräfte gewarnt sein. Es könnten teure Korrekturen anfallen, wenn das Produkt endlich in den Händen echter Kunden ist.
Warnsignal #5: Es fehlen Working-Agreements
Wie trifft dieses Team eigentlich Entscheidungen?
Der Scrum Guide beschreibt lediglich Aufgaben und Verantwortlichkeiten. Er sagt nicht, wie Entwickler entscheiden, welches technische Framework verwendet werden soll, wer den Urlaubsantrag absegnet, wer den Test-Case formulieren soll und wer den Code schreibt.
Fehlen hier klare Regeln, sind endlose Diskussionen vorprogrammiert.
Genau dafür gibt es Working-Agreements. Sie beschreiben, wie ein Team zusammenarbeitet. Typische Entscheidungsregeln, die dort festgehalten sein sollten, sind:
- Einzelentscheidung durch eine benannte Person,
- Mehrheitsentscheidung im Team,
- Konsensentscheidung aller Beteiligten,
- Konsententscheidung ohne begründete Einwände.
Ohne solche Regeln entscheidet meist die lauteste Stimme. Die Verantwortung des Scrum Masters ist es, sicherzustellen, dass diese Arbeitsvereinbarungen existieren, weiterentwickelt und umgesetzt werden.
Fehlen Working-Agreements, bezahlen Führungskräfte schnell für endlose Diskussionen.
Warnsignal #6: Refinements leiden unter Ideenarmut
Das Product-Backlog-Refinement legt die Grundlage für ein gutes Produkt.
Wenn Refinement-Sessions nur eine Idee hervorbringen, fehlt dem Team Entscheidungsqualität. Denn Studien belegen:
- Die erste Idee ist selten die beste.
- Weniger Ideen bedeuten schlechtere Ideen.
Gute Refinements erzeugen bewusst Optionen,
- damit mehrere fachliche Alternativen entstehen,
- unterschiedliche technische Lösungswege diskutiert werden,
- verschiedene Perspektiven gehört werden,
- Ideen zunächst ohne Bewertung gesammelt werden.
Erst danach wird verdichtet, priorisiert und entschieden.
Wir können uns das wie einen Diamanten vorstellen:
Genau diesen „Diamanten“ herzustellen, ist die Verantwortung des Scrum Masters. Fehlt es an Ideenvielfalt, setzt das Team zwangsläufig die erstbeste Lösung um. Führungskräfte sollten dieses Warnsignal nicht übersehen, sonst droht schnell ein mittelmäßiges Produkt.
Warnsignal #7: Konflikte bleiben ungelöst
Warum lösen sich Teams auf?
Wo mehrere gute Ideen entstehen, entstehen zwangsläufig unterschiedliche Ansichten. Das ist normal. Gefährlich wird es, wenn Konflikte nicht erkannt werden. Etwa im Refinement: In der Phase zwischen Ideenvielfalt und Entscheidung geraten Teams in eine kritische Zone. Dort knirscht es schon mal.
Typische Warnzeichen für ungelöste Konflikte sind:
- Diskussionen werden persönlich statt sachlich.
- Entscheidungen werden vertagt oder erzwungen.
- Gespräche verlagern sich nach dem Meeting in die Kaffeeküche.
- Beteiligte schalten ihre Kamera aus.
- Spannungen werden mit Schweigen „ausgesessen“.
Konflikte verschwinden nicht von selbst.
Im Gegenteil: Sie verschärfen sich. Die Verantwortung des Scrum Masters ist es, Konflikte früh sichtbar zu machen, zu navigieren und nach Lösungen zu suchen. Gelingt das nicht, verlangsamen sie die Zusammenarbeit, blockieren Entscheidungen oder führen zum Zerfall des Teams.
Führungskräfte, die dieses Warnsignal ignorieren, riskieren schleichenden Produktivitätsverlust.
Warnsignal #8: Teammitglieder entwickeln sich fachlich nicht weiter
Warum stagniert das Team?
Produktentwicklung verändert sich ständig. Technologien, Werkzeuge und Erwartungen der Nutzer entwickeln sich weiter. Teams müssen mithalten.
Wenn sich Teammitglieder fachlich nicht weiterentwickeln, entsteht ebenfalls ein schleichender Produktivitätsverlust.
Typische Anzeichen dafür sind:
- Wissen konzentriert sich auf wenige Personen.
- Neue Aufgaben überfordern das Team.
- Technische Schulden nehmen zu.
- Lernzeit findet nur „nebenbei“ statt.
Weiterentwicklung sollte nicht dem Zufall überlassen werden.
Im Scrum Guide heißt es dazu klar:
„Der Scrum Master dient dem Scrum Team unter anderem dadurch, Hindernisse für den Fortschritt zu beseitigen.“
Fehlende Kompetenz ist genau so ein Hindernis. Die Verantwortung des Scrum Masters ist es, Lernen systematisch zu ermöglichen – durch Formate wie Pair-Programming, Peer-Mentoring oder gezielte Weiterentwicklung durch Schulungen.
Führungskräfte, die dieses Warnsignal ignorieren, riskieren abermals einen schleichenden Produktivitätsverlust.
Warnsignal # 9: Der Einsatz des Budgets wird nicht hinterfragt
Wofür gibt das Unternehmen hier eigentlich Geld aus?
Scrum Teams kosten Geld – jeden Sprint. Umso wichtiger ist die Frage, welchen Nutzen dieses Budget erzeugt.
Ein naheliegender, aber kurzsichtiger Ansatz ist es, Leistung so zu messen:
- verfügbare Entwicklerzeit im Sprint,
- produzierte Features oder Velocity,
- daraus abgeleitete Kosten pro Feature.
Das kann nur der Startpunkt sein. Anhand dieser Zahlen lässt sich nicht entscheiden, ob ein Produkt erfolgreich ist oder ob es die Entwickler nur beschäftigt. Genau hier liegt die Verantwortung des Scrum Masters. Er sorgt dafür, dass Budgeteinsatz und Wirkung miteinander verknüpft werden, etwa über kürzere Entwicklungszeiten, tatsächlichen Kundennutzen oder reale Nutzung.
Im Scrum Guide heißt es dazu:
„Der Scrum Master ist ergebnisverantwortlich für die Effektivität des Scrum Teams.“
Im „Professional Agile Leadership – Evidence-Based Management“-Training zeige ich deshalb Führungskräften, wie sie Kennzahlen und Dashboards erstellen, die Wirkung statt Auslastung messbar machen.
Denn es geht um nicht weniger als um die Wirtschaftlichkeit des Unternehmens, die sonst auf dem Spiel steht.
Warnsignal #10: Der Scrum Master versteht sich nicht als Risikomanager
Was haben alle bisherigen Warnsignale gemeinsam?
Sie sind Risiken, die jedes Unternehmen betreffen. Diese lassen sich grob in drei Kategorien einordnen:
- technische Risiken, die Qualität und Lieferfähigkeit gefährden,
- wirtschaftliche Risiken, die Budget und Wirkung entkoppeln,
- gruppendynamische Risiken, die Zusammenarbeit und Entscheidungen lähmen.
Scrum ist ein Vorgehen, um Produkte unter Unsicherheit erfolgreich zu entwickeln, zu liefern und zu betreiben.
Genau hier liegt die Verantwortung des Scrum Masters.
Scrum Master sind Risikomanager: Sie sorgen dafür, dass diese Risiken sichtbar werden, verstanden wurden und aktiv bearbeitet werden – über Backlog, Definition-of-Done, Arbeitsweisen und Entscheidungsregeln.
Sieht ein Scrum Master seine Aufgabe eher als Team-Sekretär, der nur Retrospektiven plant, Jira-Tickets aktualisiert und das Daily moderiert, dann sollte das Führungskräften ein Warnsignal sein.
Allerdings:
Viele Unternehmen wissen nicht, was sie von einem Scrum Master erwarten können. Daran sind nicht nur schlechte Scrum Master schuld, sondern meist die Unternehmen selbst – etwa daran, wie sie die Rollen beschreiben:
Was kann ich denn von einem Agile Master, Scrum Jedi oder Agile Hero erwarten?