Wie komme ich zu dieser Aussage, und warum hat mich diese Erkenntnis sogar dazu bewogen, jetzt eine Blogserie zum Thema “Scrum Basics” zu starten?
Seit vielen Jahren bin ich, Anna Rudat, als Agile Coach, Trainer oder in einer der Scrum Verantwortlichkeiten (Product Owner, Scrum Master, Entwickler) unterwegs. In den letzten Jahren haben fast alle meine Einsätze mit skaliertem Scrum zu tun, d.h. es geht um mehr als ein Scrum Team bzw. das Scrum Team arbeitet mit anderen Scrum Teams gemeinsam an einem Produkt. Zum einen finde ich diese Entwicklung klasse und es zeigt, dass Scrum sich als Rahmenwerk durchsetzt. Zum anderen fällt mir dabei immer wieder auf, dass die meisten Skalierungen nicht richtig rund laufen, weil die Scrum Basics nicht sitzen.
Dies hat unterschiedliche Ursachen, von denen sich eine durchzieht wie ein roter Faden: Die einzelnen Scrum Teams haben Scrum für sich selbst, also auf Teamebene, noch nicht richtig zum Laufen gebracht. Trotzdem wird bereits mit einer Skalierung begonnen. Ich meine damit, dass viele Scrum Basics bereits in einem einzelnen Scrum Team nicht richtig funktionieren.
So geht es nicht
Lasst mich dies anhand einiger Beispiele verdeutlichen:
- Transparenz wird nur unvollständig gelebt, manchmal wird selbst dem Product Owner nicht alles transparent gemacht.
- Scrum Teams überprüfen ihr Handeln gar nicht richtig ehrlich in Sprint Retrospektiven, sondern nutzen diese als „Auskotz Meetings“
- Verbesserungsmaßnahmen aus einer Retro werden nicht auf ihre Wirksamkeit hin überprüft.
- Scrum Teams passen Dinge nur oberflächlich an, aber Kernprobleme bleiben bestehen, wie beispielsweise unzureichenden Testumgebungen/-Stationen.
- Es gibt in der Organisation nicht den Raum eine agile Kultur aufzubauen, sondern es werden lediglich Rollen und Meetings umbenannt.
- Die Verantwortlichkeiten in Scrum Teams sind nicht klar verstanden oder besetzt, es fehlt an Scrum Mastern oder es gibt Doppelverantwortlichkeiten.
- Sprints werden angepasst oder deren Länge übernommen, ohne auf die Umgebung des Teams zu achten.
- Sprint Plannings dauern Stunden, da sie nicht vorbereitet sind oder werden kurz gehalten, weil Themen aus dem letzten Sprint übernommen wurden, da sie nicht abgeschlossen wurden.
- Im Daily Scrum werden mechanisch drei Fragen runtergebetet, ohne darüber nachzudenken.
- Daily Scrum findet ohne das Sprint Backlog statt.
- An den Sprint Reviews nehmen keine Stakeholder teil, die wirklich Feedback geben können oder die Reviews finden intern ohne PO statt.
- Die Definition of Done wird nicht gelebt oder ist erst gar nicht vorhanden.
- …
Diese Liste ließe sich fast “endlos” fortsetzen. Ich muss mich selbst hier schon beim Schreiben bremsen.
Vielleicht kennt ihr auch solche Punkte?
Scrum Basics – Die Basis muss stimmen
Unter solchen Bedingungen in Bezug auf Scrum Basics ist es für die Scrum Teams fast unmöglich, reibungsfrei an einer Skalierung mitzuwirken. Im Gegenteil: häufig behindern diese unsauberen Basics sogar die Skalierung und somit weitere Scrum Teams.
In einer kleinen Blogserie zu den Scrum Basics möchte ich diese Teams unterstützen, indem ich ihnen Lösungsideen mitgebe.
Mit meiner Blogserie möchte ich das gesamte Scrum Framework einmal durchgehen. Dabei werde ich mich an der folgenden Illustration orientieren.
Den Anfang macht das Thema “Daily Scrum“, unser kleinstes Event in Scrum, das doch so viel über ein Scrum Team aussagt.
Welche Themen bewegen dich? Lass gern einen Kommentar da.
Eure Anna Rudat
