Blogpost vom 08. August 2017
Scrum. Willkommen in der Zettelwirtschaft!
IT-Projekte sind multi-dimensional: viele verschiedenen Abhängigkeiten und Wechselwirkungen müssen bedacht werden. Hinzu kommt, dass sich im Projektverlauf Änderungen ergeben können, die zu Beginn nur schwer vorherzusehen sind. Das gilt insbesondere für Branchen, die auf dynamischen Märkten agieren: Hier können die Anforderungen an Software besonders volatil sein. Eine sinnvolle Antwort darauf ist Scrum.
Bleiben Sie flexibel
Um den Wechselfällen im Lauf eines Projektes flexibel begegnen zu können, gibt es auf dem Gebiet der Projektabwicklung die innovative Schule des Agilen Projektmanagements, deren besonders anerkanntes Framework Scrum wir hier vorstellen möchten. Es basiert auf den Grundsätzen des Agilen Manifests. Scrum setzt alle agilen Grundsätze in die tägliche Praxis um. Dabei stellt es etablierte Projektmanagementmethoden mitunter infrage, indem es auf radikale Vereinfachung setzt.
Das Scrum-Prinzip
Scrum ist inkrementell. Das bedeutet, es geht einen Weg der „kleinen Schritte“: Während herkömmliche Verfahren das gewünschte Endprodukt schon vor Entwicklungsbeginn in einem Pflichtenheft spezifizieren, entsteht es bei Scrum schrittweise und aus seiner eigenen Logik heraus. Das bedeutet nicht, dass Chaos ausbricht, sondern hat im Gegenteil einen Zugewinn an Struktur und Übersicht zur Folge.
Scrum ist iterativ. Das klassische lineare Entwicklungsverfahren wird bei Scrum durch ein zyklisches ersetzt: Regelmäßige Feedback-Schleifen sorgen dafür, dass die Software auf Basis jedes Inkrements und in jeder Phase ihrer Entstehung beobachtet und hinsichtlich ihrer Qualität optimiert wird.
Scrum ist empirisch. Scrum geht davon aus, dass echtes Wissen weniger aus der Theorie als aus der Erfahrung entsteht. So sorgt das iterative Vorgehen zum Beispiel dafür, dass der Projektaufwand auf Basis empirischer Daten wie etwa der Teamgeschwindigkeit leichter und korrekter eingeschätzt werden kann.
Die Scrum-Tugenden
Aller guten Dinge sind drei. So auch die Scrum-Tugenden:
- Transparenz: Fortschritte und Hindernisse im Projektverlauf werden täglich und für alle sichtbar festgehalten.
- Überprüfung: Die fertigen Produktfunktionalitäten werden nicht als Gesamtpaket am Ende des Projektes ausgeliefert, sondern jeweils einzeln und schon während des Projektverlaufes geprüft, auch auf Kundenseite.
- Anpassung: Die Anforderungen an die Software werden nicht in einem initialen Hauptdokument, der Spezifikation, vorgegeben, sondern in so genannten User Stories formuliert. Diese beziehen sich stets nur auf einzelne Teilanforderungen, so dass die Gesamtrichtung des Projektes jederzeit flexibel angepasst werden kann.
Das Scrum-Team
Das Scrum-Team besteht aus drei Entitäten: Product Owner, Scrum Master und Entwicklerteam.
- Der Product Owner vertritt den Auftraggeber und ist für den Erfolg der fertigen Software beim Kunden verantwortlich. Er verwaltet die User Stories im so genannten Product Backlog und gibt die in dieser Form gestellten Anforderungen an das Entwicklerteam weiter.
- Der Scrum Master gehört im Regelfall zum Haus des Softwaredienstleisters. Er führt sein Amt weniger in der Art eines klassischen Projektleiters als in der Art eines „Servant Leaders“ aus. Er trägt Sorge, dass das Entwicklungsteam gut arbeiten kann und dass alle Scrum-Kriterien im Projektverlauf eingehalten und ernstgenommen werden. Außerdem fällt es in seinen Aufgabenbereich, für die persönliche und fachliche Weiterentwicklung der Teammitglieder Sorge zu tragen. Er ist ausdrücklich ein Unterstützer, kein Vorgesetzter. Er bildet die Schnittstelle zwischen Product Owner und Entwicklerteam sowie zwischen Entwicklerteam und interner Geschäftsführung.
- Das Entwicklerteam bündelt sämtliche Kompetenzen, die für die Umsetzung der Software notwendig sind: Programmierer, Webentwickler, Tester. Es sollte insgesamt nicht mehr als max. 15 Mitglieder umfassen. Es arbeitet selbstorganisiert und entscheidet eigenverantwortlich, welche User Stories es in welcher Zeit realisieren kann. Es empfängt weder Anweisungen vom Product Owner noch vom Scrum Master.
Der Scrum-Workflow
Der Scrum-Workflow besteht aus Sprint, Sprint Planning und Daily Scrum:
- Der Sprint ist das Herzstück von Scrum. Die Zeitspanne von höchstens 4 Wochen bildet den Rahmen für die Umsetzung einer bestimmten, vorher vom Entwicklerteam festgelegten Anzahl von User Stories.
- Das Sprint Planning ist das Eröffnungsmeeting für jeden Sprint und je nach Sprintlänge auf max. 8 Stunden begrenzt. Im Sprint Planning wird festgelegt, wie lange der jeweilige Sprint dauern soll und welche User Stories innerhalb dieser Zeit umgesetzt werden sollen. Teilnehmer sind der Product Owner, der Scrum Master und das Entwicklerteam.
- Das Daily Scrum ist eine 15-minütige tägliche Besprechung innerhalb des Entwicklerteams, in der jeder Entwickler seine Baustelle für dieses Tag mündlich vorstellt und alle aktuellen Baustellen innerhalb des Teams synchronisiert werden.
Der Sprint Review
Am Ende jedes Sprints wird ein Sprint Review abgehalten, um zu prüfen, ob alle Inkremente umgesetzt wurden, die für diesen Sprint geplant waren, und um das Product Backlog gegebenenfalls anzupassen. Es handelt sich um ein Abnahmemeeting für alles, was das Entwicklerteam als „Done“ erklärt: Softwareteile, Codefragmente, Teilprodukte.
Die Sprint-Retrospektive
Bei Bedarf kann zusätzlich eine Sprint-Retrospektive durchgeführt werden. Diese dient dazu, den vergangenen Sprint im Hinblick auf Mitarbeiter, Beziehungen, Prozesse und Werkzeuge zu evaluieren und, falls nötig, Verbesserungen vorzunehmen.
Scrum-Artefakte
Die Scrum-Artefakte sind diese beiden:
- Product Backlog: Ausgehend von der gemeinsamen Vision eines Endproduktes enthält das Product Backlog die Gesamtheit aller User Stories. Im Gegensatz zu einer klassischen Spezifikation bilden diese nicht die gesamte Software in einem einzigen Dokument ab, sondern formulieren einzelne Funktionswünsche für die fertige Applikation. Das Product Backlog ist auch nicht von Anfang an komplett, sondern wird vom Product Owner sukzessive ausgebaut. Im so genannten Product Backlog Grooming klären Product Owner und Entwicklerteam die technischen Anforderungen für jede einzelne User Story und schätzen deren jeweiligen Umsetzungsaufwand in der Einheit so genannter Story Points.
- Sprint Backlog: Das Sprint Backlog enthält die Summe aller für einen Sprint ausgewählten User Stories sowie eine Aufstellung aller Arbeiten, die für die Fertigstellung des Inkrements oder der Inkremente in diesem aktuellen Sprint erforderlich sind. Dabei sollte das Entwicklerteam unbedingt eine gemeinsame Vorstellung von „fertig“ haben, in Scrumsprache eine gemeinsame „Denition of Done“. Nicht fertig gewordene User Stories wandern am Ende des Sprints zurück in das Product Backlog und werden im nächsten Sprint neu bewertet.
Das Scrum Board
Für das Onlinezeitalter zumindest ungewöhnlich ist die für Scrum bezeichnende Wiedergeburt des Klebezettels. Statt die verschiedenen Aufgaben und Teilbaustellen eines Projektes über eine Software zu verwalten, bilden wir sie bei Scrum auf Post-its ab, welche je nach Bearbeitungsstatus durch die verschiedenen Bereiche einer Pinnwand wandern. Vorsintflutlich? Unzeitgemäß? Ganz und gar nicht! Die scrum-typische „Zettelwirtschaft“ hat erwiesene Vorteile im Bereich Transparenz und Kommunikation!
Die Vorteile von Scrum
Die Erfahrung hat gezeigt, dass die Stärken von Scrum genau da liegen, wo die Verfechter klassischer Vorgehensweisen möglicherweise die Gefahren sehen: in der Eigenverantwortung der Entwickler und in der Abwesenheit eines allumfassenden Plans.
Vorteile 1:
- Sehr gute Codequalität durch das Testen der einzelnen Inkremente schon während der Entwicklungsphase
- Sehr gute weil schnelle Reaktionsmöglichkeiten im Falle sich ändernder Anforderungen im laufenden Projekt
- Große Flexibilität bei der Verwendung der optimalen Technologien
- Eine hohe Transparenz des Projektverlaufs durch einen pinboard-driven Entwicklungsprozess
Vorteile 2:
- Regelmäßiges Feedback und strukturierte Kommunikation
- Sehr gute Arbeitsdisziplin durch die Verantwortung regelmäßiger Feedbacks
- Sehr hohe Arbeitsmoral durch die Pflege einer echten Teamkultur
- Erhebliche Einsparungen im Bereich Verwaltung und Dokumentation
- Ein stringentes und klares Projektmanagement
Planung und Kontrolle werden bei Scrum durch eine niederschwellige Philosophie der “Kleinen Schritte“ ersetzt. Der typische empirische, iterative und inkrementelle Projektverlauf ermöglicht zudem ein flexibles Vorgehen bei gleichzeitig besseren weil feinmaschigen Kontrollmöglichkeiten.
Die positive Auswirkung von Scrum auf die Arbeitsmoral des Teams ist ebenfalls von großer Bedeutung für den Projekterfolg.
Agiles Projektmanagement mit Micromata
Jedes Softwareprojekt und jeder Kunde hat seine eigene Charakteristik und bedarf eines daran angepassten Projektmanagements. Scrum empfiehlt sich immer dann, wenn die Komplexität der zu entwickelnden Software so hoch ist, dass unmöglich alle Bedingungen und Wechselwirkungen schon vor Entwicklungsbeginn überblickt werden können.
Da Scrum bei den meisten Kunden bisher nicht als Standard implementiert ist, haben wir es von unserm UX- Team in unseren Forschungsprojekten testen lassen. Mit erstaunlichem Erfolg:
„Unsere Forschungsprojekte sind in aller Regel vielschichtig und erfolgskritisch für unsere Kunden. Dennoch oder gerade deswegen hat sich Scrum in dieser Umgebung als besonders effektiv herausgestellt, wobei man auch sagen muss, dass Forschungsprojekte ihrer Natur nach positiv auf empirische und iterative Prozesse reagieren.“
Simon Krackrügge, Experte für Requirements Engineering bei Micromata
