Der vergangene Blog Artikel unter der Rubrik “Agile“, enthielt eine Einführung in Kanban sowie unser (Harald’s und meins) Fazit zum Vorgehensmodell “Kanban in der Softwareentwicklung“. Wie dort bereits angesprochen, erfreut sich auch Scrum als ein Vertreter der agilen Methoden immer größerer Beliebtheit. Auch ich bin ein großer Anhänger des Frameworks und würde euch gerne einen Einstieg in Scrum vermitteln.

Scrum ist ein Rahmenwerk, mit dessen Hilfe Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.” Dieser Definition stammt aus der offiziellen deutschen Übersetzung des Scrum Guides, welcher als Regelwerk für Scrum verstanden wird. Wichtig hierbei ist, dass es sich bei Scrum um ein Framework handelt und nicht um eine formale Prozessbeschreibung. Scrum wendet weiterhin das Agile Manifest an, dessen vier Grundfeste und zwölf Prinzipien sich immer wieder im Scrum Prozess wiederfinden.

Aus der Definition von Scrum haben wir entnommen, dass Scrum den Anspruch hat “Produkte mit höchstmöglichem Wert auszuliefern”. Um diesen höchstmöglichen Geschäftswert für ein Produkt zu erreichen bedient sich Scrum der empirischen Prozessteuerung. Der Kern dieser ist die kontinuierliche Inspektion und Adaption, die im Scrum Prozess zum Tragen kommt und gelebt wird. Die Voraussetzung hierfür ist Transparenz, welche durch verschiedene Artefakte und Meetings in Scrum gefordert und gefördert wird, sowie Vertrauen und Courage. Denn nur durch Vertrauen und Courage kann wiederum Transparenz erzeugt werden.

An dieser Stelle kurz der Überblick über die erforderlichen Rollen und den Prozess in Scrum.

Der Product Owner

Er ist für die Maximierung des Wertes des Produktes und damit für die Einträge (“Product Backlog Items”) im Product Backlog verantwortlich und hat das letzte Wort über die Priorität der umzusetzenden Anforderungen. Des Weiteren steht er dem restlichen Team jederzeit Rede und Antwort, wenn es Klärungsbedarf bezüglich der Product Backlog Items gibt. Speziell sei hier darauf hingewiesen, dass es sich beim Product Owner um eine Einzelperson handelt – nicht um einen Ausschuss oder ein Gremium.

Das Entwicklungsteam

Das Entwicklungsteam besteht aus 3 bis 9 Fachleuten, die die Einträge aus dem Produkt Backlog selbst organisiert in ein Produkt umsetzen. Es ist interdisziplinär besetzt und muss in der Lage sein, alle notwendigen Arbeiten zur Umsetzung der Product Backlog Items durchzuführen. Daher bedarf es keiner Subteams wie “Tester” oder “Analysten”, welche für Teile der Arbeit zuständig sind. Das Entwicklungsteam ist stets als Ganzes für das Arbeitsergebnis verantwortlich.

Der Scrum Master

Der Scrum Master ist als dienende Führungskraft dafür verantwortlich, dass Scrum verstanden und korrekt angewandt wird. Er dient dem Product Owner, dem Entwicklungsteam als auch der Organisation. Für den Product Owner etabliert er z.B. Techniken, um das Product Backlog effektiv verwalten zu können. Dem Entwicklungsteam hilft er unter anderem dadurch, dass er Hindernisse (im Scrum-Jargon “Impediments” genannt) entfernt, die das Entwicklungsteam am idealen Vorankommen hindern. Die gesamte Organisation unterstützt er auch dadurch, dass er sie bei der Umsetzung von Scrum führt und anleitet, um somit den Nutzen aus Scrum zu maximieren.

Der Scrum Prozess

Der Scrum Prozess

Der Scrum Prozess im Überblick (Bildquelle: NovaTec Consulting GmbH)

Der Scrum Prozess startet mit der Vorstellung der Anforderungen durch den Product Owner gegenüber dem Entwicklungsteam. Das Event hierzu ist das “Sprint Planning Meeting”, welches  in zwei Teile unterteilt ist. Innerhalb des ersten Teils des Meetings werden die Anforderungen durch den Product Owner vorgestellt und so detailliert erklärt, dass ein gemeinsames Verständnis über die Product Backlog Items herrscht. Am Ende des Sprint Planning Meeting 1 kann das Entwicklungsteam eine Vorhersage abgeben, welche Product Backlog Items es innerhalb der nächsten Iteration entwickeln kann. Eine Iteration dauert gemäß Scrum Guide 30 Tage oder weniger und wird “Sprint” genannt. Im zweiten Teil des Sprint Planning Meetings bespricht das Entwicklungsteam, wie es die Anforderungen in ein potentiell auslieferbares Produkt Inkrement umzusetzen vermag. Hierzu werden die Anforderungen in Tasks, die in einem Tag oder weniger umsetzbar sind, herunter gebrochen und deren Aufwand absolut in Stunden abgeschätzt. Die so extrahierte Arbeit wird auf dem Sprint Backlog visualisiert. Das Entwicklungsteam arbeitet nun für die Dauer eines Sprints (in der Praxis häufig 2 bis 3 Wochen) ungestört an den ausgewählten Anforderungen.

Während des Sprints findet täglich ein 15 minütiges Standup Meeting – das “Daily Scrum” – statt. Der Zweck des Daily Scrums ist der Informationsaustausch zwischen den Teammitgliedern und sich einen Überblick über den aktuellen Stand der Arbeiten zu verschaffen. Als notwendige Kommunikationsplattform während der Entwicklung macht das Daily Scrum Probleme frühzeitig transparent und beantwortet auch maßgeblich die Frage, ob das Team noch im Plan ist oder der Product Owner gegebenenfalls über Abweichungen vom Plan zu informieren ist.

Am Ende eines Sprints findet das “Sprint Review Meeting” statt. In diesem Meeting stellt das Entwicklungsteam das in diesem Sprint fertiggestellte potentiell auslieferbare Produktinkrement (auch PSI genannt) allen Stakeholdern (insbesondere auch den Kunden) vor. Über die direkte Präsentation des PSI vor allen unter der Einbeziehung der Stakeholder erhält das Scrum Team unmittelbar Feedback sowie neue Ideen. Das Product Backlog kann somit umgehend an eventuell neue oder geänderte Anforderungen angepasst werden, welche direkt in den nächsten Sprint einfließen können.

Als Abschluss eines Sprints findet eine Reflexion des vergangenen Sprints statt. Als “Retrospektive” dient dieses Meeting vor allem der kontinuierlichen Inspektion und Adaption aus der empirischen Prozesssteuerung.

Fazit

Der Artikel hat die Scrum Rollen sowie die wesentlichen Bestandteile des Scrum Prozesses beschrieben. Hieraus läßt sich ableiten, dass die Einführung von Scrum – im Gegensatz zu Kanban – weitreichende Änderungen in einem Unternehmen erfordern kann. Es müssen beispielsweise oft organisatorische Hürden aus dem Weg geräumt werden oder Personalrotationen stattfinden, um die erforderlichen Rollen für den Scrum Prozess geeignet zu besetzen. Das Ausmaß an notwendigen Veränderungen ist abhängig von der aktuellen Situation des Unternehmens und von der Art und Weise, wie Scrum eingeführt werden soll. Ist beispielsweise nur ein Projekt oder Team betroffen oder soll das ganze Unternehmen nach Scrum arbeiten? Je nach gewünschtem “Zielzustand” gibt es unterschiedliche Wege, diesen zu erreichen.

Scrum macht es möglich, Produkte zu entwickeln, die schneller am Markt sind (Time to Market) und im Verhältnis zur aufgewendeten Zeit einen hohen Geschäftswert bieten (Return on Investment). Durch die inkrementelle Produktentwicklung sind Ergebnisse schneller sichtbar, das Risiko bei der Produktentwicklung sinkt durch frühe Korrekturmöglichkeiten und die kurzen Iterations- und Feedbackzyklen sorgen für ein hohes Maß an Transparenz.

Beide Frameworks – Kanban und Scrum – leisten in der Praxis wertvolle Dienste. Eine genauere Betrachtung ist erforderlich, um deren jeweilige Einsatzschwerpunkte zu diskutieren und herauszufinden, unter welchen Gegebenheiten welches Modell geeigneter ist.

~ Pascal Naujoks

Leave a Comment

1 comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close