Auto, Software oder Hochzeit? – mach’s mit Scrum
Agiles Framework für Arbeitsprozesse: Das klingt erst einmal unglaublich theoretisch – aber Scrum hat praktisch, ausgehend von der Software-Branche, die gesamte Unternehmens- und Arbeitskultur revolutioniert. Doch wie genau läuft so ein Scrum-Prozess ab, wer ist daran beteiligt und was sind die Vorteile gegenüber klassischer Produktentwicklung?
Das Scrum-Framework geht auf die japanischen Ökonomen Ikujirō Nonaka und Hirotaka Takeuchizurück und stellt mithilfe optimierter Zusammenarbeit die verbesserte Wertschöpfung von Unternehmen in den Fokus. Den Begriff Scrum entliehen sie dem Rugby, da aus ihrer Sicht das Gedränge der Spieler als Analogie für effektive Entwicklungsteams steht. Auf dieser Grundlage entwickelten Jeff Suherland und Ken Schwaber ein Framework für Software-Unternehmen. Die Scrum-Masterin Sara Benner, die bereits mehrere Jahre für das Software-Unternehmen Datev in Nürnberg arbeitet, vergleicht den Scrum-Prozess mit dem Bau eines Autos: „Statt das komplette Auto auf einmal zu entwickeln, werden in kleinen Teams Teile, wie Motor, Fahrwerk und Getriebe entwickelt, die noch bevor das Auto fertig ist, vom Kunden getestet werden können. Das Feedback auf die kleineren Teile hilft, das ganze Auto iterativ nach Vorstellung des Kunden zu gestalten.“
Um einen Scrum-Prozess zu starten, braucht es zunächst einmal die Idee eines Produkts. Das kann nicht nur der Bau eines Autos, sondern auch eine verbesserte Rezepte-App, ein Software-Programm für Wirtschaftsprüfer*innen oder, wenn du willst, sogar die Planung einer Hochzeit sein.
Das gesamte Scrum-Team besteht aus dem*der Product-Owner*in, den Developern, und dem*der Scrum-Master*in. Der*die Product Owner*in ist ergebnisverantwortlich und vertritt die Interessen der Auftragsgebenden. Die Person, die diese Position einnimmt, steht im Austausch mit den Stakeholdern (Management oder Kunden), die zwar kein aktiver Part des Prozesses sind, aber ein Interesse an dem bestmöglichen Ergebnis haben und auch das Budget beeinflussen. Der*die Scrum-Master*in, im englischen auch Serveant Leader genannt, ist für die korrekte methodische Umsetzung und die Effektivität des Scrum-Prozesses verantwortlich. Das umfasst sowohl Moderations- und Coaching-Aufgaben, die den Product-Owner unterstützen, das Team zu interdisziplinärer Zusammenarbeit motivieren und Barrieren zwischen Management oder Kunden und dem Scrum-Team abbauen. Die Developer wiederum kümmern sich um die technische Umsetzung. Hier arbeiten je nach Produkt Menschen aus den verschiedensten Bereichen zusammen. Gemeinsam kann das Team nun bereits erste Merkmale und Funktionen ableiten, die das Produkt oder eine Lösung besitzen soll. Diese sogenannte User Story wird auf einer User Card festgehalten, einem Medium der Wahl. Hier zeichnet sich zum ersten Mal ab, welche Ressourcen das Projekt benötigen wird. Die Kombination aus den Ansprüchen des*der Product-Owner*in und den User Storys ergeben sogenannte Backlog-Items, die nach Prioritäten sortiert werden und das Product-Backlog bilden.
Mit diesen Voraussetzungen kann der praktische Entwicklungs-Prozess eines Produkts starten: Der Sprint. Dieser besteht aus verschiedenen Events, wie dem Planning, den Daily Scrums, der Review, und der Retrospective. Im Planning werden drei zentrale Fragen gestelllt: 1. Warum ist dieser Sprint von Wert? 2. Was kann mit dem Sprint erreicht werden? Und 3. Wie wird die gestellte Aufgabe erledigt? Daraus ergibt sich der Sprint-Backlog, entwickelt von und für die Developer. Dieser dient ihnen zur Übersicht über den Sprint-Prozess. Die Daily Scrums reflektieren darauf aufbauend den Fortschritt des Prozesses, um gegebenenfalls Anpassungen vorzunehmen. Das Ergebnis eines Sprints ist dann meist ein Teil-Produkt oder auch sogenanntes Inkrement, welches in der Review den Stakeholdern vorgestellt wird. Darauf aufbauend können weitere zukünftige Änderungen geplant werden.
Im abschließenden Schritt eines Sprints, der Retrospective, wird der Prozess in seiner Gesamtheit reflektiert, fehlerhafte Annahmen untersucht und wie und ob aufgekommene Probleme gelöst wurden. Übergeordnetes Ziel dabei ist eine Verbesserung der Effektivität des gesamten Scrum-Teams.
Während im klassischen Projektmanagement die Verantwortung in erster Linie auf dem Management liegt, wird die Veantwortung auf alle Team-Mitglieder aufgeteilt. Das schafft sowohl Identifizierung mit einem Projekt als auch, infolgedessen, Commitment. Zudem werden Unternehmenshierarchien abgebaut, da alle für das Gelingen eines Projekts gleichermaßen wichtig sind. Das Schöne an dieser etwas trockenen Theorie ist außerdem, dass sie auf jedes praktische Beispiel angewendet werden kann, bei dem ein Produkt oder eine Problemlösung gefragt ist – das Verhältnis zwischen Bedürfnissen, Budget und Effektivität wurde hier wirklich perfektioniert. Als nächstes werden wir euch Lean Thinking vorstellen, das sowohl aufbauend auf Design Thinking als auch Scrum eigesetzt werden kann. Stay tuned!
Herunterladen