Scrum

Scrum ist ein Framework zur Entwicklung komplexer Produkte, das sich durch wenige Rollen, Ereignisse und Artefakte in einem festen Rhythmus auszeichnet. Es definiert drei Verantwortlichkeiten: den Product Owner, der für die Wertmaximierung der Arbeit verantwortlich ist, den Scrum Master, der die Effektivität des Prozesses sicherstellt, und die Entwickler, die das Inkrement erstellen. Zu den Ereignissen gehören der Sprint selbst, die Sprintplanung, das Daily Scrum, die Sprint Review und die Sprint Retrospektive.

Das Framework ist bewusst minimalistisch gehalten und beschreibt, was geschehen muss, ohne vorzuschreiben, wie. Es stellt keine Methodik dar, die technische Vorgehensweisen, Schätztechniken oder Anforderungsformate vorgibt; diese werden dem Team überlassen. Dieser Minimalismus ist beabsichtigt, da das Framework davon ausgeht, dass die Teams, die am nächsten an der Arbeit sind, ihre eigenen Methoden festlegen. Dies bedeutet aber auch, dass ein Team, das Scrum ohne ergänzende technische Vorgehensweisen anwendet, zwar eine Koordinationsstruktur, aber keine technische Disziplin besitzt.

Jedes Ereignis hat seinen Sinn, der oft in Vergessenheit gerät. Die Planung legt fest, was versucht werden soll und warum. Das tägliche Scrum dient der Koordination der Entwickler und dem Aufdecken von Hindernissen, nicht der Statusberichterstattung an den Manager. Die Review dient der Überprüfung des Inkrements mit den Stakeholdern und der Anpassung der Richtung, nicht der Präsentation. Die Retrospektive dient der Verbesserung der Teamarbeit. Wenn diese Meetings zu rituellen Abläufen verkommen und ihren ursprünglichen Zweck vergessen, verschwenden sie Zeit und bringen nichts – die häufigste Kritik an diesem Framework.

Die Verantwortlichkeit des Product Owners ist der häufigste Schwachpunkt bei Implementierungen. Diese Rolle erfordert echte Befugnisse zur Prioritätensetzung und die Fähigkeit, kontinuierlich Entscheidungen zu treffen. Oftmals wird jedoch jemand ernannt, der beides nicht besitzt und daher jede wichtige Entscheidung eskalieren muss. Ein Product Owner ohne diese Befugnisse verwandelt das Framework in eine Art Warteschlangenverarbeitung, in der das Team Entscheidungen von anderer Stelle umsetzt und so die ursprünglich beabsichtigte Flexibilität verliert.

Die feste Sprintlänge erfüllt einen Zweck, den es zu verstehen gilt, bevor man sie aufgibt. Ein gleichmäßiger Rhythmus schafft Struktur für Planung, Überprüfung und Anpassung und zwingt dazu, Arbeit in überschaubare und bewertbare Abschnitte zu unterteilen. Teams, die Sprints verlängern, wenn die Arbeit nicht mehr hineinpasst, beseitigen die Einschränkung, die diese Aufteilung überhaupt erst verursacht hat, und tendieren typischerweise zu längeren Zyklen mit weniger häufigem Feedback.

Die Retrospektive ist gleichzeitig das wertvollste und das erste, das vernachlässigt wird. Sie ist der Mechanismus, mit dem ein Team seine eigenen Prozesse verbessert; ohne sie wiederholt ein Team dieselben Hindernisse auf unbestimmte Zeit. Retrospektiven, die keine Verhaltensänderung bewirken, sind schlimmer als gar keine, denn sie zeigen, dass das Ansprechen von Problemen nichts bringt. Daher ist es die Überprüfung, ob die identifizierten Maßnahmen tatsächlich umgesetzt werden, die die Retrospektive sinnvoll macht.

Das Framework eignet sich für manche Aufgaben deutlich besser als für andere. Es ist ideal für die Produktentwicklung mit echter Unsicherheit, einem stabilen Team und einem realen Kunden, von dem man lernen kann. Für ungeplante operative Arbeiten, Wartungsarbeiten mit unvorhersehbarem Eintreffen und stark störungsgetriebene Kontexte ist es wesentlich weniger geeignet. Teams in solchen Situationen erzielen häufig bessere Ergebnisse mit einem flussbasierten Ansatz, der keine Festlegung auf einen festen Arbeitsablauf erfordert.

Da die Effektivität eher von Autorität, Teamstabilität und organisatorischer Unterstützung als von der Einhaltung von Zeremonien abhängt, sollte die Bewertung die Ergebnisse und nicht die Einhaltung untersuchen. In der Praxis wird der Umsetzungsansatz innerhalb von ,Die Entscheidungen des Produktverantwortlichen basieren auf Erkenntnissen aus Produktforschung, und für a kleine oder mittlere Unternehmen Der Aufwand für das Framework lässt sich häufig reduzieren, um eine schlankere Lösung zu finden, die besser für ein einzelnes kleines Team geeignet ist.