7 Tipps für einen erfolgreichen (Re‑)Start mit Scrum

Max Winkler

Sie stellen Ihre Entwicklungsteams in ihrem Unternehmen auf den Scrum Prozess um oder einzelne Teams haben Probleme mit Scrum?

Daran erkennen Sie, dass der Scrum Prozess nicht eingehalten wird:

  • nicht alle Rollen sind besetzt
  • nicht alle Scrum Events finden statt
  • verschiedene Scrum Events werden kombiniert abgehalten
  • EntwicklerInnen sind bei der Implementierung von Anforderungen oft blockiert
  • Die Entwicklung von Arbeitspaketen geht über eine Sprintlänge hinaus
  • es ist nicht klar, wann Stories als “Done” gelten
  • die Kunden partizipieren nicht an den für sie relevanten Scrum Events

Starten Sie gleich richtig, oder verbessern Sie die Situation, indem Sie folgende Punkte mit Ihren Teams umsetzen:

1. ShuHaRi - Üben Sie sich in Disziplin

Implementieren Sie den Scrum-Prozess wie im Scrum Guide beschrieben. In der japanischen Kampfkunst werden drei Stufen des Lernens hin zur Mastery beschrieben, Shu-Ha-Ri. Shu ist die Stufe der totalen Disziplin. Formen werden wiederholt, es gibt keine Abweichung vom Konzept. In der zweiten Stufe Ha werden Formen und Bewegungen gebrochen, Neuerungen werden implementiert. Die Stufe Ri eröffnet die Tür zur Kreativität, Formen und Bewegungen werden den konkreten Bedürfnissen angepasst. Starten Sie mit der Stufe Shu!

2. Besetzen Sie alle drei Rollen

Ein Scrum Team besteht aus den EntwicklerInnen, dem Product Owner und einem Scrum Master. Jede der drei Rollen trägt ihren Teil für das Gelingen zum Gesamterfolg bei. Vermeiden Sie zudem Doppelrollen. Context-Switching in der Wissensarbeit reduziert die Performance signifikant. Außerdem sind die Anforderungen an jede der drei Rollen höchst unterschiedlich und nur selten gut kombinierbar.

3. Nutzen Sie die Kraft der Scrum Events

Die fünf Scrum Events haben konkrete Ziele und klar abgesteckte Zeitrahmen. Sie geben Ihren Teams alles was sie brauchen, um gemeinsam ein hervorragendes Produkt zu liefern. Lassen Sie daher ihre Scrum Team Mitglieder alle “alten” Meetings aus ihrem Kalender entfernen. Übrigens, auch der Sprint stellt ein Event dar. Das Refinement gehört offiziell nicht zu den Scrum Events, dieses Meeting sollte aber mindestens einmal pro Woche abgehalten werden.

Der Sprint

Der Sprint stellt das Herzstück des Scrum Frameworks dar. Hier werden Ideen in Werte umgewandelt. Die Länge eines Sprints reicht von einer bis zu vier Wochen,.Während eines Projekts sollte die Länge immer gleich bleiben. Kürzere Sprints haben den Vorteil der geringeren Komplexität, die Feedback-Zyklen sind kürzer. Alles was dem Produktziel dienlich ist, ist im Sprint inkludiert. Die “Definition of Done” präzisiert, welche technischen Voraussetzungen das Stück Software am Ende des Sprints haben muss, damit es als erledigt gilt.

Sprint Planning 1 & 2

Im Sprint Planning 1 wird das WAS, der Arbeitsumfang, für den nächsten Sprint geplant und ein gemeinsames Sprint Ziel wird formuliert. Das Scrum Team verantwortet selbst, wie viele Aufgaben es im nächsten Sprint erledigen wird. Mit Einhaltung dieses sogenannten “Pull-Prinzips” wird sichergestellt, dass das Team eine nachhaltige Geschwindigkeit aufnehmen kann und die Qualität nicht unter zu vielen Aufgaben leidet. Im Sprint Planning II erarbeitet das Team gemeinsam WIE die Aufgaben erledigt werden sollen. Dieses Event stellt den Startschuss für den Sprint dar.

Daily Scrum

Auch bekannt unter Daily Standup findet täglich für 15 Minuten im stehen statt. Die Teammitglieder halten sich gegenseitig auf dem laufenden, wer woran arbeitet. Dabei kann nach Synergien gesucht werden, Blocker besprochen oder aufkommende Termine oder Events besprochen werden.

Sprint Review

Am letzten Tag des Sprints demonstriert das Team den Kunden, Stakeholdern oder Interessierten das im Sprint entwickelte “Potentially Shippable Product Increment”, ein Stück “working software”. Die Teilnehmer geben Feedback, jetzt kann das Team zeitnah gewünschte Änderungen einarbeiten, im Besten Fall kann diese Arbeit daanach abgeschlossen werden.

Sprint Retrospektive?

Dieses Scrum Event deckt die drei Pfeiler des Scrum Frameworks ab - “Inspect, Adapt, Transparency” und ist ein sehr wichtiges Scrum Event. Die Retrospektive kann als Abschluss eines Sprints angesehen werden und findet nach dem Review statt. Gemeinsam analysiert das Team, was erfolgreiche Sprints zu solchen gemacht haben und wo es noch Optimierungspotenziale gibt.

Refinement

Das Refinement ist kein offizielles Event im Scrum Framework. Es muss auch nicht unbedingt ein Event sein. Auf jeden Fall handelt es sich beim Refinement um einen fortwährenden Prozess über alle Scrum Zyklen hinweg. Die im “Product Backlog”, das ist die Liste in der sich die zukünftigen Aufgaben für das Entwicklungsteam befinden, am höchsten priorisierten Aufgaben für kommende Sprints werden von den Mitgliedern eines Teams gemeinsam besprochen und wenn notwendig in sinnvollere kleinere Einheiten geteilt. Informationen von Kunden oder Stakeholdern werden eingeholt, technische Anforderungen konkretisiert. Die Arbeitspakete daraus entstehenden Arbeitspakete müssen einen Kundenwert generieren und innerhalb eines Sprint fertig gestellt werden können, sowie der “Definition of Ready” entsprechen.

4. Die Artefakte - Garant für Qualität

Product Backlog, Sprint Backlog und Working Software sind die Artefakte eines Scrum Teams. Fundamental und mit den Artefakten einhergehend sind die “Definition of Ready”, die “Definition of Done” und die dazugehörigen “Akzeptanzkriterien” (ACCs). Sie regeln die “Kommunikation” des Scrum Teams mit der Außenwelt. Die Effektivität eines Scrum Teams und die Qualität des Produktes korreliert mit dem Vorhandensein und der korrekten Implementierung.

5. Binden Sie ihre Kunden in die Prozesse ein

Scrum stellt den Kunden in den Mittelpunkt. Laden Sie ihn zu den Refinements und zu den Reviews ein. So stellen Sie sicher, dass sie die Bedürfnisse und Ziele ihres Kunden verstehen und treffen. Diese können und dürfen sich im Prozess auch verändern. Vermeiden Sie Stille Post, bringen Sie lieber Ihre EntwicklerInnen und Kunden zusammen.

6. Definieren Sie Ziele

Produktvision, Teamvision, Sprint Ziel dienen der Koordinierung aller Beteiligten und helfen den Fokus richtig zu legen. Mit guten und messbaren Zielen vermeiden Sie unnötige Diskussionen und Arbeit im Planungsprozess, aber auch in der Umsetzung der Ideen in Working Software.

7. Pull-Prinzip und Selbst-Management

Die Einführung des Pull-Prinzips stellt in vielen Unternehmen den Paradigmenwechsel schlechthin dar. Das Pull-Prinzip adressiert das Ziel der nachhaltigen Geschwindigkeit in der Arbeit bei gleichzeitiger Erhöhung der Qualität. Die EntwicklerInnen bestimmen nach ihren Kapazitäten selbst, wann sie mit der nächsten Aufgabe starten. Multitasking und Kontext Switching kostet viel Zeit und damit Geld. Das Team der Zukunft managt sich selbst.

Sind Sie bereit loszulegen?

Erfahren Sie, wie ilirion Sie unterstützen kann, Ihre Agilitätsziele zu erreichen. Kontaktieren Sie uns noch heute.

Über den Autor


Max Winkler

Max Winkler

Max ist Head of Agile bei ilirion und schreibt auch zu diesem Thema. Über die letzten Jahre hat er als Scrum Master und Agile Coach Unternehmen bei der Einführung, Transformation und Optimierung (agiler) Prozesse begleitet. Er ist Experte in Sachen Scrum, Kanban und lateraler Teamführung.