Erste Schritte mit Minimum Scrum

Der Einstieg in Scrum mit einem Team kann seine eigenen Herausforderungen mit sich bringen. Das Wissen über Scrum als agiles Framework ist nur ein kleiner Teil der Herausforderung. Die größeren Probleme bestehen darin, sich von den traditionellen Methoden zu lösen und sich an die agile Denkweise zu gewöhnen.

Eine Gruppe von Entwicklern, die bisher Produkte in konventionellen Softwareentwicklungszyklen geliefert haben, würde Vertrauen in das System haben, was sie möglicherweise resistent gegen Veränderungen macht. Es mag verlockend klingen, alles vom ersten Tag an zu beginnen. Aber als Scrum-Master oder Scrum-Coach für ein solches Team ist es von entscheidender Bedeutung, diesen Transformationsprozess zu durchbrechen.  

Ein Konzept, das bei diesen Bemühungen helfen kann, ist Minimum Scrum. Hier geht es darum, das Team in kleinen Schritten an die neuen Gegebenheiten anzupassen, bevor es zu einer vollständigen Einführung kommt. Solange das Team nicht anfängt, darauf zu vertrauen, dass die neue Arbeitsweise Ergebnisse für es bringt, können wir ein Team nicht erfolgreich umgestalten.  
Wie der Name schon sagt, bezieht sich Minimum Scrum auf die Mindestanforderungen, die ein kleines Team erfüllen muss, um sich auf den Weg zu Scrum zu machen. Es kann in vier Teile unterteilt werden:

Ermächtigte Rollen: Das Team darf keine Rollen nur um der Rollen willen haben. Alle Scrum-Verantwortlichen (Scrum-Team - Entwickler, Product Owner und Scrum Master) müssen befugt sein, Entscheidungen zu treffen. Das Scrum Team soll sich selbst verwalten und selbst organisieren. Das Management muss zu den Entscheidungen des Scrum-Teams stehen. Das bedeutet zwar nicht, dass das Team keine Anleitung braucht, aber die Entscheidungsbefugnis muss dezentralisiert sein. Eine ausfallsichere Umgebung ist ein Muss für das Gedeihen und den Erfolg von Scrum in einem Team oder einer Organisation.

Veranstaltungen mit der Intention: Menschen, die sich auf Scrum umstellen, tragen oft den Mythos mit sich herum, dass es bei Scrum (oder jedem anderen agilen Framework) um eine Menge von Meetings geht. Das Team muss sich auf die fünf Scrum-Zeremonien beschränken - Sprint, Sprint Planning, Daily Scrum, Review und Retrospective. Durch die Erstellung von Kapazitätsplänen wird sichergestellt, dass die Zeit für diese Veranstaltungen von der Kapazität des Teams abgezogen wird. Alle anderen Meetings (technisch oder funktional) müssen im Voraus geplant werden, vorzugsweise während der Sprintplanung. Das Team sollte für all diese Ereignisse einen Zeitplan festlegen und diesen auch gewissenhaft einhalten.

Wenn diese Ereignisse nicht dem Zweck dienen, sind sie so gut wie nicht durchgeführt. Das gesamte Scrum-Team muss alle seine Verantwortlichkeiten kennen und beabsichtigen, seine Verpflichtung gegenüber dem Sprint-Ziel durch diese Ereignisse zu erfüllen.

Gut anfangen, besser aufhören: Wir können und müssen nicht alles fertig haben, bevor wir mit einem Sprint beginnen. Um jedoch anzufangen, muss der Product Owner die INVEST-Kriterien verwenden, um das Product Backlog zu erstellen. Außerdem muss das Scrum-Team sicherstellen, dass die DoR (Definition of Ready) eingehalten wird, bevor die Issues in den Sprint gezogen werden.  
Das Sprint-Ziel muss klar sein, von allen verstanden werden und innerhalb des für den Sprint festgelegten Zeitrahmens erreichbar sein. Wie der griechische Philosoph Aristoteles sagte: "Gut begonnen ist halb getan".

Bei der Fertigstellung muss das Scrum-Team sicherstellen, dass das erstellte Inkrement dem Geschäftsziel entspricht. Die Erfüllung der DoD-Kriterien (Definition of Done) ist eine Voraussetzung für den Abschluss jedes Problems im Sprint. Die bloße Erfüllung des DoD darf jedoch nicht als Erfolg gewertet werden. Die Qualifizierung der Akzeptanzkriterien ist das Wichtigste, damit das Issue als akzeptiert und abgeschlossen erklärt werden kann, da dies den Geschäftszweck des Issue bestätigt, also den Grund, warum es überhaupt erstellt wurde.

Umgang mit Veränderungen: Geht es bei agilem Arbeiten nicht vor allem um die Akzeptanz von Veränderungen? Die Antwort lautet sowohl Ja als auch Nein. Ja, weil Flexibilität das Herzstück aller agilen Frameworks ist, und Nein, weil wir für diese Änderungen Grenzen setzen müssen. Das bedeutet jedoch nicht, dass wir Änderungen ablehnen. Es bedeutet, dass wir einen Zeitrahmen haben, um Änderungen für die Ausführung jeder Anforderung zu akzeptieren. Alle Änderungen, die darüber hinausgehen, müssen entweder als Änderungsanfrage behandelt oder im nächsten Sprint oder Programminkrement berücksichtigt werden. Das Team muss lernen, dass Änderungen akzeptabel sind, wenn sie das Sprint-Ziel nicht behindern oder beeinträchtigen.

Das Team trifft sich zu einem Daily Scrum und bespricht, was das Sprint Goal blockiert. Dies ist eine der besten Plattformen zur Überprüfung und Anpassung. Das Team passt sich an die aktuelle Situation an und macht weiter. Die Sprint-Retrospektive ist eine weitere nützliche Veranstaltung, die das Team durchführen muss, um seine Arbeitsweise zu überprüfen und an die neuen Anforderungen anzupassen oder die Dinge aufzugeben, die nicht mehr funktionieren.

Minimum Scrum ist nur ein Ausgangspunkt, um Teams bei der Einführung von Scrum den richtigen Start zu ermöglichen. Eine wirklich agile Denkweise entwickelt sich jedoch mit der Zeit und durch die erfolgreiche Demonstration von Minimum Scrum. Außerdem wird dieses Modell, wie jedes andere agile Framework, nicht funktionieren, wenn nur das Scrum Team es annimmt. Die Beteiligten, einschließlich der Kunden und des Managements, müssen diese vier Dinge verinnerlichen und sich bemühen, dafür zu sorgen, dass dies mit echter Absicht geschieht.