Agile Softwareentwicklung mit dem Scrum-Framework

8 Tipps zum effektiven Einsatz von Scrum: Agile in der Praxis

Dominik Unzicker

© Shutterstock.com / Trueffelpix

Scrum definiert klare Rollen, Zuständigkeiten und Events innerhalb eines Softwareprojekts. Ziel des Frameworks ist eine konstante Steigerung der Produktivität. Dies wird vor allem durch eine kontinuierliche und zielgerichtete Kommunikation erreicht. Bei der Umsetzung von Scrum im eigenen Unternehmen bieten diese acht praxisbezogenen Tipps eine gute Hilfestellung.

Scrum creates a good framework to organize teams, and provide transparency in order to improve and enhance communication“. In diesem Zitat steckt die Quintessenz einer Methodik, die zuerst die Softwareentwicklung und inzwischen viele weitere Unternehmensbereiche revolutioniert hat. Das Prinzip klingt einleuchtend: Arbeit in einem Team ist vor allem effizient bei vorhandener Transparenz der Aufgaben und Prozesse und guter Kommunikation zwischen den Teammitgliedern. Entscheidend ist es nun, Scrum im Team zu leben. Dafür reicht es nicht, dass jeder die Definition der Begriffe kennt. Es ist wichtig das Warum und Wieso zu verstehen und zu verinnerlichen. Im Folgenden werden daher die wichtigsten Grundprinzipien beleuchtet.

Heutzutage wird agiles Projektmanagement von vielen Unternehmen als Aushängeschild verwendet. Dabei gibt es verschiedenste Ausprägungen von Agilität, die nicht immer zum ersehnten Erfolg führen. Das Besondere an Scrum ist: es funktioniert sogar dann, wenn man es nicht perfekt anwendet. Wie Jeff Sutherland in seinem Buch „Scrum. The Art of Doing Twice the Work, in Half the Time“ zeigt, lassen sich bei richtiger Anwendung von Scrum Produktivitätssteigerungen von bis zu 400 Prozent erzielen [1]. Welchen Manager würde das nicht überzeugen?

Scrum: Das sind die Basics

Bevor wir jedoch in die vertiefte Materie einsteigen, rufen wir uns noch einmal die wichtigsten Bestandteile von Scrum ins Gedächtnis. Abbildung 1 visualisiert die Kernelemente des Scrum-Prozesses.

Abb. 1: Das Scrum-Framework [3]

Abb. 1: Das Scrum-Framework

In einem Projekt gibt es immer verschiedene Stakeholder. In Scrum geht es dabei vor allem um jene, die eine Produktvision definieren. Diese Vision wird durch den sogenannten Product Owner in einem Product Backlog in Form sogenannter User Stories festgehalten.

Scrum-Rollen

Scrum definiert grundlegend drei Rollen:

  • Das Entwicklerteam entscheidet über das “Wie”. Es hat die Hoheit darüber, wie die technische Struktur und Funktionsweise abgebildet wird.
  • Der Product Owner entscheidet über das “Was”. Er hat die Oberaufsicht über das Product Backlog, dessen Inhalte und Priorisierung. Er muss sicherstellen, dass das Team die richtigen Features zur richtigen Zeit entwickelt.
  • Der Scrum Master sichert die korrekte Ausführung des Scrum-Frameworks durch alle Projektbeteiligten. Er sorgt beispielsweise dafür, dass das Team seine Scrum-Meetings unter Einhaltung des vorgegebenen Zeitfensters abhält und der Sprint auch tatsächlich wie geplant realisiert wird. Er ist zudem Vermittler und Unterstützer, beseitigt Hindernisse, sorgt für Informationsfluss zwischen Product Owner und Team, und strebt maximalen Nutzen und ständige Optimierung an. Kurzum, er sorgt dafür, dass der Prozess zielgerichtet verläuft und aus Dynamik nicht Chaos wird.

Iteratives Vorgehen in Sprints

Das Produkt wird im Scrum-Framework iterativ und inkrementell entwickelt, im Rahmen sogenannter Sprints. Das bedeutet, Verbesserungen werden schrittweise durchgeführt und Produkte in Einzelteilen entwickelt und am Ende eines jeden Sprints ausgeliefert.

Die Scrum-Meetings

Am Anfang eines Sprints steht das Backlog Grooming. In diesem Meeting wird der priorisierte Backlog durchgegangen, Anforderungen durchgesprochen und Rückfragen geklärt, um sicherzustellen, dass eine Aufgabe bereit ist, vom Team umgesetzt zu werden. Darauf folgt das Sprint Planning, in dem sich das Team jene Aufgaben aus dem Backlog wählt, die im nächsten Sprint umzusetzen sind. Diese bilden dann das Sprint Backlog. Dabei ist es wichtig, dass das Team nur so viele Aufgaben wählt, wie es auch innerhalb eines Sprints schaffen kann. Während des Sprints findet das Daily Stand-up statt, ein tägliches sehr kurzes Meeting (maximal 15 Minuten), in dem sich das Team gegenseitig auf den aktuellen Stand bringt und Probleme angesprochen werden, die nach dem Zusammentreffen direkt zu lösen sind.

Am Ende eines Sprints stellt das Team in der Sprint Review die fertiggestellten Neuerungen am Produkt vor. Das ermöglicht sofortiges Feedback durch die Stakeholder, die nun eine funktionsfähige Version seines Produkts zur Verfügung haben. Ein wichtiges Ziel in Scrum ist die kontinuierliche Verbesserung der Prozesse. Daher wird in der Sprint-Retrospektive der vergangene Sprint beleuchtet und konkrete Verbesserungsvorschläge gemacht, die in den folgenden Sprints zu implementieren sind. Alle Meetings werden in festen Zeitfenster organisiert, um gefürchteten Endlosbesprechungen vorzubeugen.

Diese Tipps helfen jedem Scrum-Team

Scrum ist schnell verstanden und gleichzeitig schwer zu meistern, denn wie so oft steckt der Teufel im Detail. In der Praxis entstehen immer wieder bestimmte Muster, die mithilfe der folgenden acht Tipps beseitigt werden können.

1. Kommuniziere deine Scrum-Meetings

Scrum beinhaltet verschiedene Scrum-Meetings, die das Ziel haben, einen regelmäßigen und fokussierten Austausch sicherzustellen. Auch für erfahrene Scrum Master kann es eine Herausforderung sein, Scrum-Meetings mit dem notwendigen Fokus durchzuführen. In einem Sprint Planning sollte nämlich tatsächlich nur geplant und nicht erneut die Lösung präsentiert werden. In einem Backlog Grooming sollte tatsächlich nur das Backlog verfeinert und nicht der nächste Sprint geplant werden.

Um die Scrum-Meetings zu organisieren und einen klaren Fokus sicherzustellen, empfiehlt es sich, diese für alle Parteien transparent zu kommunizieren. Äußerst bewährt haben sich E-Mail-Einladungen, die feste Informationen enthalten, die in Tabelle 1 am Beispiel der Sprint-Review und des Daily Stand-up erklärt werden.

Name Beschreibung Zeitpunkt
Sprint Review Im heutigen Meeting wollen wir in den vorgegebenen 30 Minuten die Sprint Review durchführen.
Agenda:
Vorführen aller neuen oder im Sprint modifizierten Features;
Features identifizieren, die als Done deklariert werden können;
Unvollständige Features zurück ins Backlog überführen;
Kommunikation via: präferiertes Tool
Regelmäßig, einmal am Sprint-Ende
Daily Stand-up Im heutigen Meeting wollen wir in den vorgegebenen 15 Minuten unser Ziel für den heutigen Tag festsetzen.
Agenda:
Was habe ich seit dem letzten Stand-up erreicht?
Was will ich heute erreichen?
Was steht mir im Weg, um mein Ziel zu erreichen?
Kommunikation via: präferiertes Tool
Täglich

Tabelle 1: Beispielhafte Einladungen für ausgewählte Scrum-Meetings

Mithilfe dieser Termineinladungen per E-Mail erhalten alle Parteien einen Überblick: Wann, welches Meeting stattfindet und was darin behandelt wird. Sie ermöglichen, dass alle Teammitglieder pünktlich kommen können, da alle Informationen jederzeit offen und transparent sind. Bei Veränderungen des Teams werden neue Teammitglieder dem Event per Einladung hinzugefügt. Wichtig ist, dass die Meetings regelmäßig und zur gleichen Uhrzeit stattfinden, um Verwirrung zu vermeiden.

2. Setze eine „Definition of Ready“ fest

Eine Definition of Done kennen viele – oft vergessen wird aber die sogenannte Definition of Ready, also die „Fertig-zum-Entwickeln“-Definition. Das Konzept ist schnell verstanden, aber nicht immer so einfach umgesetzt. Dabei erscheint es einleuchtend, dass ein Entwicklerteam auch nur etwas umsetzen kann, wenn die entsprechende Vorarbeit zur Anforderung geleistet wurde. Die Kunst ist es tatsächlich, nur Aufgaben in einem Sprint zu planen, zu denen keine Abhängigkeiten bestehen. Ein klassisches Symptom einer unzureichend definierten oder nicht vorhandenen Definition of Ready sind nicht abgeschlossene und sich in Bearbeitung befindliche User Stories. Im schlimmsten Fall ziehen sich diese über diverse Sprints und werden niemals fertig.

Hier ist eine klare Definition of Ready entscheidend und deren Einhaltung auch konsequent sicherzustellen. Beginnt man einmal, eine Non-ready User-Story zu einzuplanen, ist die Hürde, das auch zukünftig zu wiederholen, nicht mehr sonderlich hoch. Dieser Umstand führt zu dauerhaft schlechten Sprint-Ergebnissen und einem schlechten Endprodukt.

Diese Situationen kriegt man wie folgt in den Griff:

  • User Stories in sinnvolle Größen unterteilen: Sie lassen sich dann nicht nur zuverlässiger umsetzen, es lassen sich auch Abhängigkeiten schneller und einfacher lösen und die kundenseitige Abnahme ist ebenfalls einfacher.
  • Blockierende Abhängigkeiten im Grooming aufdecken: Wenn eine User Story nicht umgesetzt werden kann, weil es Abhängigkeiten gibt, müssen diese zunächst erkannt und gelöst werden. Dazu sollte eine Liste der Abhängigkeiten pro User-Story geführt werden. Dabei sollte auch die im Team dafür zuständige Person aufgeführt sein. Sind diese Informationen vorhanden, können die blockierenden Abhängigkeiten besser identifiziert und beseitigt werden.
  • Abstand zwischen Sprint Planning und Backlog Grooming schaffen: Abhängigkeiten zu beseitigen kostet Zeit. Daher sollte darauf geachtet werden, dass ein Grooming immer einige Tage vor einem Planning stattfindet, um relevante Abhängigkeiten wie notwendige Wireframes und Designs oder fachliche Rückfragen bis dahin abzustellen.

Am Ende des Tages ist eine Definition of Ready das erste und wahrscheinlich wichtigste Quality Gate im Entwicklungsprozess. Arbeitet das Team konsequent an Ready User Stories, wird sich der Output signifikant steigern. Wenn das alle im Team verstanden haben, geht die Entwicklung deutlich einfacher und zielgerichteter.

3. Planning

„Plans are worthless, but planning is everything” – so formulierte es bereits Eisenhower in einer Rede im Jahre 1957 [2]. Ein knapper und berühmter Satz in dem viel Wahrheit steckt.

Im Sprint Planning liegt der Fokus darauf, das zu planen, was zum aktuellen Zeitpunkt die höchste Relevanz hat. Im Projektverlauf ändern sich Prioritäten. Die Aufgabe des Product Owners ist es, diese zu erkennen und sauber im Backlog abzubilden. Zum Zeitpunkt des Sprint Plannings werden dabei die relevantesten User Stories hinsichtlich ihrer Komplexität geschätzt und geplant. Die Schätzung muss dabei konsequent für alle User Stories ausgeführt werden, um auch das auszuliefern, was man geplant hat.

Klassische Symptome eines unzureichenden Plannings sind:

  • Die Schätzung wird in Zeit- statt in Komplexitäteinheiten durchgeführt.
  • Es wird gar keine Schätzung gemacht, sondern nach dem Pi-mal-Daumen-Prinzip gearbeitet.
  • In die geplanten Sprints werden Stories hineingezogen, obwohl das Team noch nicht fertig ist. Dies passiert vor Allem dann häufig, wenn spontane Stakeholder-Anfragen kommen. Ist dies häufiger der Fall, sollte mit Puffer geplant werden und das klar kommuniziert werden.

4. Setze eine Definition of Done fest

„Das ist fertig“ – das zu beurteilen ist nicht immer einfach und liegt oft im Auge des Betrachters. Und genau hier hilft eine Definition of Done.

Diese wird vom ganzen Team als zentrales Kriterium dafür genutzt, um entscheiden zu dürfen, ob etwas fertig ist oder nicht. Alle sind angehalten, sich um die Einhaltung der Definition of Done zu kümmern. Inhalte einer Definition of Done in einem Softwareteam sind beispielsweise:

  • ECT-Loop: Der Entwickler hat den Sourcecode einem Edit-Compile-Test-Loop unterzogen, was bedeutet: Er hat ihn entwickelt, er hat ihn kompiliert, er hat ihn getestet und für gut befunden.
  • Unit-Tests: Es wurden Unit-Tests für die Funktionen des jeweiligen Features geschrieben.
  • User-Acceptance-Tests: Die definierten Akzeptanzkriterien der User Story sind erfüllt. Vorzugsweise wurde dies von einem anderen Teammitglied abgenommen.
  • Code-Review: Es wurde eine Code-Review der relevanten Bestandteile durchgeführt und – ganz wichtig – die Verbesserungen wurden auch eingearbeitet.
  • Inbetriebnahme auf Staging: Das Feature wurde auf einer Umgebung, zum Beispiel dem Staging-System, in Betrieb genommen. Vorzugsweise wurden hier die User-Acceptance-Tests durchgeführt.

Eine große Herausforderung stellt die konsequente und dauerhafte Überprüfung der Definition of Done dar. Instabile und nicht robuste Systeme entstehen nämlich genau dann, wenn im Zeitverlauf nicht kontinuierlich gearbeitet wird.

5. Scrum-Rollen konsequent leben

Scrum sieht klare Rollen vor. Dahinter steckt vor allem die Grundidee, jeder Rolle einen klaren Tätigkeitsbereich im Projekt zuzuordnen, Interessenskonflikte zu vermeiden und Verantwortung zu definieren.

Grundsätzlich sollte daher darauf geachtet werden, dass die Rollen, wie sie im Abschnitt „Scrum: Das sind die Basics“ dieses Artikels dargelegt wurden, klar getrennt werden. In der Praxis ist es häufig der Fall, dass sich einzelne Rollen vermischen – vor allem dann, wenn die Teams etwas kleiner sind. Dadurch wird es umso wichtiger, eine klare Rollentrennung sicherzustellen. Der zentrale Grund wird über den Begriff Ownership verdeutlicht. Jede Rolle hat eine feste Zuständigkeit und trägt die Verantwortung für deren sinnvolle Umsetzung. Wird diese Trennung aufgebrochen, wird sich das Entwicklerteam beim nächsten Bug auf dem Produktionssystem schnell aus der Affäre ziehen, sollte der Product Owner oder ein Stakeholder vorgeschrieben haben, welche Bibliotheken oder Design Patterns einzusetzen sind.

Entscheidend ist es, als Scrum Master eine klare Linie bei der Beachtung der Rollenzuständigkeiten zu verfolgen.

6. Bilde Two-Pizza-Teams

Ein entscheidender Aspekt des Erfolgs moderner Softwareentwicklung ist die Teamgröße. Als CEO eines der erfolgreichsten Unternehmen unserer Zeit nutzte Amazon-Chef Jeff Bezos den Begriff Two-Pizza-Team als er mit dem Wall Street Journal über Teamorganisation sprach. Das bedeutet, dass Entwicklungsteams bei Amazon so groß sind, dass man sie mit zwei großen Pizzen satt bekommt. Die Teams bestehen daher in der Regel aus vier bis sechs Personen. Diese Größenordnung findet sich auch in der Forschung wieder, die den Wert von 4,6 Personen als die optimale Teamgröße herausgearbeitet hat [3]. Der Hauptgrund für diese Größe ist die Anzahl der Kommunikationswege, die mit jedem Teammitglied entstehen. Die Anzahl der Kommunikationswege lässt sich mit der Formel n(n-1)/2 ermitteln, wobei n für die Anzahl der Teammitglieder steht. Mit jedem weiteren Teammitglied steigt damit die Anzahl der Kommunikationswege ab einem Schwellwert signifikant an.

Ein weiterer wichtiger Faktor bei der Beachtung von Teamgrößen ist die sogenannte Ownership. Dieser Begriff meint, dass Personen und ein Team nur dann Verantwortung übernehmen, wenn sich die einzelnen Personen auch dafür verantwortlich fühlen. Dies ist ab einer gewissen Teamgröße nicht mehr gewährleistet.

7. Liefere früh und häufig

Ein Hauptziel für Scrum-Teams ist „liefere früh“ (Finish Early). Dieser Tipp mag leicht umsetzbar klingen, ist in der Praxis allerdings nicht immer so einfach zu realisieren. Oftmals ist der Sprint doch voller als angenommen und das Team schafft weniger als geplant.

Ein wichtiges Instrument, um dies in den Griff zu bekommen, ist das konsequente Schätzen von Aufwänden im Zusammenhang mit der jeweiligen Komplexität. Die Zeitkomponente kommt dann ins Spiel, sobald der erste Sprint absolviert wurde: Welche Komplexität hat das Team innerhalb des Sprints bewältigt? Wurde beispielsweise eine Komplexität von 30 Story Points abgearbeitet, ist die Wahrscheinlichkeit ziemlich hoch, diese 30 Story Points auch im nächsten Sprint zu schaffen. Vor allem dann, wenn man Erkenntnisse der Retrospektive mit in den Folge-Sprint einfließen lässt und umzusetzen vermag. Dieses Prinzip nennt sich Yesterday’s Weather und hat eine ziemlich hohe Wahrscheinlichkeit, zu funktionieren, sofern es konsequent angewendet wird.

Ein weiterer wichtiger Schritt, um Geschwindigkeit – und somit „liefere häufig“ („Deliver Often“) – im Entwicklerteam zu erreichen, ist die Automatisierung. Denn niemand möchte Tests händisch ausführen, einen Server immer und immer wieder in Betrieb nehmen und dem Kunden anschließend erzählen müssen, dass der Temp-Ordner auf dem Server nicht gelöscht wurde und er deshalb das neue Feature nicht testen konnte.

Unit-Tests laufen in Sekundenbruchteilen durch, CI-Tools wie Jenkins erstellen Codemetriken, führen Unit-Tests aus und deployen in definierten Umgebungen. Sicherlich ist das Aufsetzen einer individuellen Automatisierung nicht einfach, lohnt sicher aber auf lange Sicht, da es Tage an manueller Arbeit einspart und ein entscheidender Faktor der Qualitätssicherung ist. Durch die Nutzung von Yesterday’s Weather und Automatisierung kann das Team effektiver werden und verlässlicher liefern.

8. Keep Going

Ähnlich wie Finish Early, ist Keep Going für Scrum-Teams einer der entscheidendsten Tipps, der zum Erfolg führen kann. Es ist wichtig zu verstehen, dass die konsequente Einhaltung der Scrum-Regeln und deren Überwachung harte Arbeit für den Scrum Master ist. Gerade am Anfang, etwa dem ersten Scrum-Projekt in einem Unternehmen, wird man – vor allem in etablierten Strukturen – verstärkt auf Widerstand stoßen. Scrum hat die Eigenschaft, in kurzer Zeit eine hohe Transparenz zu erzeugen, was nicht immer ein beliebter Effekt ist, da die Leistungsfähigkeit schnell bewertbar und messbar wird. Dabei sollte man nicht vergessen, dass Scrum das Ziel verfolgt, die bestmögliche Produktivität eines Team sicherzustellen und nicht Einzelne bloßzustellen. Der Scrum Master muss konstant sicherstellen, dass die Scrum-Regeln befolgt werden und darf sich bei deren Einhaltung nicht nachlässig zeigen.

Warum sollte man beim Daily Stand-up des Folgetages pünktlich sein, wenn der Kollege auch nicht rechtzeitig erschienen ist? Warum sollte man sich bemühen, eine User Story auf Ready setzen zu dürfen, wenn die Stories im letzten Sprint auch alle nicht Ready waren? Gute Scrum Master werden dem Team eine Richtung und klare Richtlinien aufzeigen, um sich agil zu entfalten. Gelingt das, wird Scrum zu einem mächtigen Werkzeug, bei dem jede Rolle weiß, was von ihr wann, wo und in welcher Form erwartet wird. Dieses Erwartungsmanagement kann die Projektarbeit nicht nur erfolgreich machen, sondern zudem auch Spaß an der Sache mit sich bringen.

Fazit

Am Ende des Tages ist Scrum ein gutes Framework zur Koordination von Aufgaben, Teams und Erwartungen. Die Kunst liegt darin, die Scrum-Definitionen nicht nur zu verstehen, sondern vor allem die Kernelemente konstant und kontinuierlich auszuführen.

Wem das gelingt, der erkennt die großartige Macht von Scrum und kann sie für sich nutzen: Kontinuierliche und zielgerichtete Kommunikation bei maximaler Transparenz.

Verwandte Themen:

Geschrieben von
Dominik Unzicker

Dominik Unzicker ist Gründer und Geschäftsführer der UHP Software GmbH. Das Frankfurter Unternehmen implementiert digitale Produkte und Services für den Mittelstand, Hidden Champions sowie internationale Blue Chips. Als Referent zum Thema agile Softwareentwicklung spricht er bei internationalen Konferenzen und in Gastvorlesungen an Universitäten.

Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "8 Tipps zum effektiven Einsatz von Scrum: Agile in der Praxis"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Burt+Parkers
Gast

Wieder ein Artikel über Pseudo-Probleme abgeschrieben aus einem x-beliebigen Lehrbuch, eine Aufarbeitung echter Probleme ist nicht zu sehen. Hier mal ein paar Dinge die ich erlebt habe:
– Endprodukt aus den Augen verloren durch Lieferdruck der Sprints
– Zuweisung der Stories im Planning
– Teammitglieder arbeiten immer an den gleichen Komponenten
– Bloßstellen im Review
mehr passt leider nicht rein