Agile neue Welt

Was sich in kleinen und mittelständischen Unternehmen schon seit längerem bewährt hat, hält nun auch in großen Konzernen Einzug: Agiles Arbeiten mit Scrum hat seinen Exotenstatus verloren. Nicht nur bei der Softwareentwicklung sondern auch bei klassischen Projekten, die bisher streng nach Wasserfallmethode geplant wurden, wird Scrum sehr erfolgreich eingesetzt. Der Bericht aus der Praxis des Web-Dienstleisters AOE zeigt deutlich die Vorteile des agilen Arbeitens – sofern sich alle an gewisse Spielregeln halten.
Die Genialität von Scrum liegt in seiner Einfachheit. Mit wenigen Regeln und Rahmenbedingungen gelingt es, komplexe Aufgaben in kleine, überschaubare Teile zu zerlegen, die übersichtlich, klar strukturiert und schnell umsetzbar sind. Erfolge sind somit schon während der Entwicklung ersichtlich und überprüfbar. Ständige Kommunikation zwischen allen Beteiligten stellt sicher, dass es nicht zu Missverständnissen und falschen Erwartungen kommt. Und: Bei Bedarf können jederzeit während des laufenden Projektes Änderungen an Ziel und Inhalt vorgenommen werden.
Klare Rollen und reger Austausch sorgen für Transparenz
Wer mit Scrum beginnt, braucht vor allem das absolute Commitment aller Beteiligten: vom obersten Management bis zum Umsetzungsteam muss jeder an Bord sein, denn Scrum stellt die klassischen Rollen auf den Kopf. Der Gedanke „Vertrauen ist gut, Kontrolle ist besser“ hat bei der agilen Web-Entwicklung ausgedient. Führungskräfte verlieren zunehmend ihre Kontrollfunktion und dienen mehr denn je als Coaches, die ihre Mitarbeiter darin unterstützen, ihre Ziele aus sich selbst heraus zu erreichen. Die Verantwortung des Projekts liegt alleine beim Product Owner. Die Autorität beim Umsetzungsteam. Dieses muss interdisziplinär aufgebaut sein und über alle Kompetenzen verfügen, um ein Produktinkrement zu erzeugen, ohne auf Zuarbeit von außen angewiesen zu sein. Die Mitglieder bringen unterschiedliche Fähigkeiten ein und ergänzen sich gegenseitig, um anstehende Aufgaben zu lösen und Innovationen durch gegenseitigen Austausch voranzutreiben. Wie eingangs erwähnt, hat Scrum wenige Regeln – diese gilt es aber möglichst genau zu befolgen, um die positiven Effekte der Methodik nicht zu verlieren. Über die Einhaltung von Meetings, Zeiten und Vereinbarungen wacht der Scrum Master. Er schützt das Team gegen Störungen von außen, räumt Hindernisse, sogenannte „Impediments“, aus dem Weg und sorgt dafür, dass der Scrum-Prozess von allen verstanden wird und sich das Team kontinuierlich weiterentwickeln kann.
Die Rollen im Scrum
- Neben dem Auftraggeber gibt es in Scrum drei zentrale Rollen: den Product Owner, den Scrum Master und das Umsetzungsteam.
- Der Product Owner (PO) ist für den Erfolg des Projektes und den Return on Invest verantwortlich. Er erstellt das Product Backlog, eine priorisierte Aufgabenliste für das Team, das in einzelnen Stories aus der Kundensicht heraus klare Wünsche beschreibt: „Wenn ich als Kunde erneut im Onlineshop einkaufe, möchte ich, dass sich der Shop an meine bevorzugte Empfangsadresse erinnert.“
- Der Scrum Master hat in erster Linie eine organisierende und moderierende Funktion. Er sorgt dafür, dass der Scrum-Prozess von allen verstanden und eingehalten wird und das Team gut arbeiten kann.
- Das Umsetzungsteam ist für die erfolgreiche Umsetzung der Stories zuständig. Es ist selbstorganisiert und dafür verantwortlich, dass alle vorgesehenen Stories in einem Sprint umgesetzt werden.
Der Reihe nach: die Rahmenbedingungen
Zum Start eines Projekts in Scrum ist es die erste Aufgabe des Product Owners, mit dem Auftraggeber die zwei begrenzenden Faktoren zu klären: Zeit und Budget. Sind diese Bedingungen abgesteckt, kann mit dem Auftraggeber besprochen werden, welche Anforderungen sich innerhalb des Rahmens umsetzen lassen. Dafür formuliert der Product Owner aus den Anforderungen sogenannte Stories, um das Product Backlog aufzubauen. Die Stories des Backlogs beschreiben die einzelnen Funktionen beispielsweiser einer Software.
Relativ zu Anfang des Scrum-Projekts kann der Product Owner die Komplexität der Stories seines gesamten Backlogs vom Umsetzungsteam in einem Meeting (Backlog Refinement ) grob in Story Points schätzen lassen. So erhält er ein Gefühl dafür, wie weit das Team innerhalb des verfügbaren Zeit- und Budgetrahmens kommen wird und kann seinem Auftraggeber eine ungefähre Vorstellung geben, wie „fertig“ das Produkt am Ende des Geldes sein wird.
Scrum ABC
Sprint: Eine fest definierte Zeitspanne (meist zwei Wochen) zur Umsetzung von Stories.
Daily Scrum: tägliches Meeting (15 Minuten). Jedes Teammitglied berichtet, was es gestern erreicht hat, was es heute plant und ob es Hindernisse gibt.
Sprint Review: Ergebnispräsentation des Sprints (1-2 Stunden). Der PO bewertet die Ergebnisse und nimmt sie an oder lehnt sie ab.
Retrospektive: Moderiert vom Scrum Master (1-2 Stunden) nach jedem Sprint: wie geht es dem Team, funktionieren die Werkzeuge, wie kann das Team besser und die Leistung optimiert werden? Mit der Retro ist der Sprint abgeschlossen.
Sprint Planning: Vor jedem Sprint (1-2 Stunden). Der PO stellt dem Team die am höchsten priorisierten Stories vor, die er als nächstes umgesetzt sehen möchte. Es endet mit dem Team Commitment, dem Versprechen des Teams, die ausgewählten Stories innerhalb des Sprints fertigzustellen.
Task Breakdown: Nach dem Planning (1-2 Stunden). Das Team schneidet die Stories in einzelne Tasks, die die Schritte zur Umsetzung beschreiben.
Backlog Refinement: Treffen (1-2 Stunden) einige Tage vor dem Planning. Anforderungen aus dem Backlog – Epics und Stories werden priorisiert und Lösungen besprochen. Das Team schätzt, wie hoch die Komplexität (Story Points) von Stories ist. Vom Product Owner vorher festgelegte Akzeptanzkriterien werden geprüft, Impediments (Hindernisse) identifiziert und im Anschluss mit Hilfe des Scrum Masters beseitigt.
Stories: Stories können mal größer mal kleiner sein, haben aber alle gemein, dass sich jede Story innerhalb eines Sprints umsetzen lassen muss. Die Points geben dem PO ein Gefühl, wie lange die Story-Umsetzung dauern wird.
Epic: große Features, die noch in Stories geteilt werden müssen
Product Backlog: die Sammlung aller Stories, die das fertige Produkt und seine Funktionen beschreiben.
Sprint Backlog: die Sammlung aller für den aktuellen Sprint relevanten Stories.
Der Sprint
Die Umsetzung der Stories erfolgt in einzelnen Abschnitten, den Sprints. Ein Sprint ist eine fest definierte Zeitspanne von durchschnittlich zwei bis drei Wochen, in der eine jeweils zwischen Product Owner und Team verhandelte Anzahl von Stories erledigt werden muss. Vor jedem Sprint, im Planning, verpflichtet sich das Team, innerhalb des Sprints die besprochenen Stories abzuarbeiten. Für ein besseres Verständnis und Umsetzung schneidet sich das Team die Stories in einzelne Tasks, die die Schritte zur Umsetzung beschreiben.
Das Ergebnis jedes Sprints sollte ein an den Auftraggeber auslieferbares Projekt-Inkrement sein, dessen Qualität im Sprint Review begutachtet wird. Im Review stellt das Team das Ergebnis seiner Arbeit vor. Der Product Owner bewertet die Ergebnisse und nimmt sie an oder lehnt sie ab. Er ist für den Erfolg des Projektes und den Return on Invest verantwortlich.
Auf jeden Sprint folgt die Retrospektive, moderiert vom Scrum Master. Gemeinsam überprüfen Team (und optional der Product Owner) den vergangenen Sprint auf Basis der Scrum-Prozesse: Wie geht es dem Team? Funktionieren die Werkzeuge? Mit der Retro ist der Sprint abgeschlossen. Es folgt das nächste Planning. Der Product Owner stellt dem Team die neuen Stories aus dem Product Backlog vor, die er als besonders relevant definiert hat.
Stories können mal größer mal kleiner sein, haben aber alle gemein, dass sich jede Story innerhalb eines Sprints umsetzen lassen muss.
Fokus auf das Wesentliche
Durch Schneiden und Priorisieren des Umfangs eines Produktes oder Projektes erreicht man, dass sich alle Beteiligten auf die wichtigsten Anforderungen konzentrieren und weniger Wichtiges hinten angestellt wird.
Dieses hohe Maß an Abwägen, Kommunikation und Transparenz ist einer der Erfolgsfaktoren von Scrum. Einerseits mit dem Team, andererseits dem Kunden gegenüber. Releasepläne basieren durch regelmäßiges Aktualisieren während der Umsetzung nicht länger auf Wunschdenken, sondern auf der Realität.
Scrum-Anfänger mögen sich über die vielen Meetings wundern und sie als Zeitverschwendung abtun. Sie dienen aber der intensiven Kommunikation zwischen dem Team und tragen essentiell zum Erfolg bei. Gerade die Rollenverteilung und die Meetings werden gerne von Teams aufgeweicht – dieses Phänomen taucht früher oder später garantiert bei jedem Scrum-Team auf und hat mit „ScrumBut“ auch schon seinen eigenen Begriff gefunden.

Autor
Joern Bock (VicePresident Project Management)
Bei AOE ist Joern Bock für die globale Projekt Management Organisation zuständig und treibt den Einsatz agiler Entwicklungsmethoden kontinuierlich voran. Er ist Key Account Manager für Kunden wie die Deutsche Telekom oder T-Systems und beschäftigt sich intensiv mit der mobilen Web-Entwicklung. Bock tritt regelmäßig als Speaker bei Konferenzen wie der Tools4AgileTeams auf.
www.aoe.com
contact-de(at)aoe.com
www.twitter.com/aoepeople