Scrum bei der SCT 

von Tabea Schröder (SCT) und Michele Schönen (A&K)

„Tut mir leid, aber ich kann Ihnen den Kollegen/die Kollegin gerade nicht ans Telefon holen. Er/sie sitzt in der Sprint-Planung!“ Der ein oder andere hat diesen Satz sicherlich schon einmal von unserer Telefonzentrale gehört. 

Der Kollege bzw. die Kollegin bereitet sich jedoch nicht auf eine Leichtathletik-Meisterschaft vor, sondern ist Teil eines Scrum-Teams. Was das genau ist und warum es sowohl für die Entwickler- als auch Kundenseite Vorteile bringt, erläutern wir Ihnen im Folgenden.

Was ist dieses Scrum?

Scrum ist ein Vorgehensmodell des Projekt- und Produkt­manage­ments, insbesondere zur agilen Softwareentwicklung. Es wurde ursprünglich in der Softwaretechnik entwickelt, ist aber davon unabhängig. Der Begriff Scrum stammt von Ikujirō Nonaka und H. Takeuchi, die damit das Gedränge (englisch scrum) im Rugby als Analogie für außergewöhnlich erfolgreiche Produkt­entwicklungs­teams beschrieben. Diese Teams arbeiten als kleine, selbst-organisierte Einheiten und bekommen von außen nur eine Richtung vorgegeben, bestimmen aber selbst die Taktik, wie sie ihr gemeinsames Ziel erreichen. Durch diese Agilität kann das Team auf die komplexen Anforderungen reagieren, die ein Projekt mit sich bringt.

Kurz zusammengefasst lässt sich das Modell so definieren: „Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.“

Agil und damit anpassungsfähig

Scrum verkörpert die Werte der agilen Software-Entwicklung:

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
2. Funktionierende Software ist wichtiger als umfassende Dokumentation.
3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Agilität wird genutzt, um komplexe Anforderungen umzusetzen. Früher waren die Anforderungen simpel oder kompliziert. Dies ließ sich mit einem klassischen Prozess wie beispielsweise dem Wasserfallmodel abbilden. Heute ist das „Was“ und „Wie“ nicht von Anfang an klar und die Problemstellungen sind daher komplexer.

Deshalb wird empirisch, inkrementell und iterativ vorgegangen, indem Anforderungen und Lösungsansätze in Zwischenergebnissen schrittweise geklärt werden. Diese Aufteilung bzw. Segmentierung hat den Vorteil, dass jedes einzelne Segment überschaubarer und damit genauer analysier- und lösbar wird, als es das Gesamt-Produkt ist. Anforderungen, die „im Großen und Ganzen“ untergegangen wären, können so rechtzeitig erkannt und bei der Lösung berücksichtigt werden.

Gleiches gilt für den Planungsprozess, der ebenfalls iterativ und inkrementell erfolgt:
Der Gesamtplan (das sog. Product Backlog) ist langfristig ausgelegt und erfährt eine stetige Verbesserung und Verfeinerung, während die Detailplanung (das Sprint Backlog) nur für die jeweils nächste Periode (den Sprint) generiert wird. Das bedeutet für die Team-Mitglieder, dass sie sich auf die wesentlichen Aspekte fokussieren können.

Der Sprint zum Produkt Inkrement

Im Sprint Backlog ist also die Detailplanung zu finden, während im Product Backlog letzten Endes das fertige Produkt geplant wird. Dies geschieht, indem eine Liste aus Eigenschaften bzw. Anforderungen aus der Perspektive des Anwenders/Kunden erstellt wird. Diese wird in ein bis vier Wochen lange Intervalle unterteilt – die Sprints. Die Sprints bei der SCT dauern zwei Wochen. Ein Sprint besteht aus dem Sprint Planning, dem Sprint Review und der Retrospektive. Wie bereits erwähnt, ist der Inhalt jeden Sprints das Sprint Backlog, in dem ein Anforderungssegment detailliert geplant wird. Als Ergebnis jedes Sprints sollte eben dieses Teilprodukt entsprechend gelöst bzw. umgesetzt sein – das Product Increment. Dadurch kann bereits früh im Projekt ein Wert für den Kunden geliefert werden. Auf den Sprint folgt dann die erneute Prüfung von Produkt, Anforderungen und Vorgehen (der Review), deren Ergebnisse als Sprint Backlog in den nächsten Sprint gehen und entsprechend weiterentwickelt werden.

Sinn dieser ganzen Segmente ist es, durch regelmäßige und für alle sichtbare Dokumentationen für mehr Transparenz zu sorgen. Zudem werden in den Reviews die Ergebnisse regelmäßig evaluiert und ggf. zur Optimierung freigegeben. Darüberhinaus werden Pläne, Vorgehensweisen und Produkt nicht zu Beginn der Entwicklung fixiert, sondern entwickeln sich stetig weiter. Die empirische Prozesskontrolle ermöglicht außerdem, ein frühes Feedback vom Kunden/Stakeholder einzuholen und den Kurs gegebenenfalls korrigieren zu können. Dadurch wird die Aufgabe zwar nicht weniger komplex, aber die Inkremente sorgen für eine bessere Übersicht aller Beteiligten.

Ohne Teamwork geht es nicht

Damit wären wir beim Scrum-Team angelangt, das das geforderte Produkt entwickelt und optimiert. Im Normalfall besteht ein Team aus fünf bis elf Mitgliedern. Wir erfüllen die Größenanforderungen mit genau elf Teammitgliedern noch so gerade Allerdings merken wir auch langsam, dass wir die Obergrenze erreichen und die Meetings zu lang werden. Verbunden mit unserem dynamischen Wachstum werden wir deshalb demnächst zwei Teams bilden.

Ein Scrum Team besteht aus drei Rollen:

• Product Owner: ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich,
• Entwicklungsteam: ist für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge sowie die Einhaltung der vereinbarten Qualitätsstandards verantwortlich und organisiert sich selbst
• Scrum Master: ist für das Gelingen von Scrum als Rahmenwerk verantwortlich, arbeitet mit dem Entwicklungsteam zusammen, gehört aber selbst im Regelfall nicht dazu.

Diese treten mit den weiteren am Produkt Beteiligten (Stakeholder) in Kontakt und berichten über Fortschritt und Zwischenergebnisse.

Stakeholder haben ebenfalls den Überblick

Die Gruppe der Stakeholder, die zwar nicht Teil des Scrum Teams, aber dennoch in den Prozess involviert ist, besteht aus Kunden, Anwendern und dem Management:

• Kunden: erhalten das Produkt nach Fertigstellung, können eine interne Fachabteilung – in unserem Falle die Berater – oder auch externe Personen sein, sollten schon nach den ersten Sprints die Möglichkeit des Feedbacks haben
• Anwender: die Produktanwender – können, aber müssen nicht auch zugleich Kunden sein, erhalten daher beim Sprint Review und Product Backlog Refinement die Möglichkeit, das Produkt zu testen und Feedback zu geben
• Management: trägt die Verantwortung dafür, dass die Rahmenbedingungen stimmen und stellt Räume, Arbeitsmittel und Unterstützung für das Team zur Verfügung

Vier Ereignisse – ein Sprint

Jeder Sprint ist in sogenannten Ereignissen organisiert, die wiederum in festen Zeitfenstern zu erfolgen haben.

1. Am Anfang steht die Sprint Planung (Sprint Planning), in der der Product Owner dem Team inklusive Scrum Master das Product Backlog vorstellt. Zudem werden gemeinsam die zu erfüllenden Eigenschaften und daraus resultierenden Akzeptanzkriterien festgelegt. Die Kriterien, die am Ende des Sprints erfüllt sein müssen, um ein funktionsfähiges, auslieferbares Produkt zu ergeben, bilden die Definition of Done. Das Team legt nun fest, wie viele der im Product Backlog festgehaltenen Punkte es im anstehenden Sprint umsetzen kann, wobei der Product Owner die Reihenfolge festlegt. Daraus ergibt sich das gemeinsam definierte Sprint-Ziel. Das Entwicklungsteam plant nun im Detail die Aufgaben, die zur Erreichung des Sprint-Ziels gelöst werden müssen. Der Product Owner nimmt an diesem Teil der Planung nur zur Beantwortung von Nachfragen teil, ansonsten entscheidet das Entwicklerteam autark und erstellt so das Sprint Backlog.
2. Täglicher Bestandteil eines Scrum-Prozesses ist der sogenannte Daily Scrum, der für gewöhnlich ca. 15 Minuten dauert: Das Entwicklerteam tauscht sich – in unserem Falle – morgens aus, der Daily ist aber zu jedem beliebigen Zeitpunkt am Arbeitstag durchführbar. Er sollte nur immer zur gleichen Uhrzeit erfolgen. Jedes Mitglied bespricht hier, was es seit dem letzten Daily Scrum erreicht hat, was es an diesem Tag erreichen will und ggf. welche Hindernisse ihm dabei im Weg sind. Der Scrum Master kümmert sich darum, dass ein Hindernis erkannt und beseitigt werden kann und unterstützt das Team dabei. Kann eine Frage, die während des Daily Scrum auftritt, nicht innerhalb der 15 Minuten beantwortet werden, wird dafür ein weiteres Meeting anberaumt. Dieses kann auch direkt im Anschluss an den Daily Scrum stattfinden.
3. Im Sprint Review steht das jeweilige Produkt Inkrement auf dem Prüfstand. Sowohl das Team, als auch die Stakeholder überprüfen gemeinsam, ob die gesetzten Ziele erreicht wurden. Die Ergebnisse fließen in das Product Backlog ein. Ein Sprint Review erfolgt am Ende jeden Sprints und sollte pro Sprintwoche 1 Stunde dauern.
4. Mit der Sprint-Retrospektive endet der Sprint: Nach dem Feedback im Review steht hier nun die Überprüfung der Arbeitsweise im Vordergrund. Was war effektiv, ineffektiv, förderlich, störend? Das Team tauscht sich hierzu offen und ehrlich aus. Das bedeutet, dass Stakeholder nur auf Einladung des Teams hinzukommen sollten, um keine Hemmnisse bei der Diskussion zu erzeugen. Bei der SCT gilt hier die goldene Regel “Ganz egal, was wir entdecken werden: Wir glauben zutiefst, dass jede(r) nach besten Kräften gearbeitet hat, wenn man den aktuellen Wissensstand, die Fähigkeiten und Fertigkeiten, die verfügbaren Ressourcen und die derzeitige Situation zugrunde legt.“ Als Ergebnis werden Verbesserungsmaßnahmen bzw. Lösungsvorschläge erarbeitet und festgehalten. Idealerweise fließen diese dann in den nächsten Sprint ein, wobei es Aufgabe des Scrum Masters ist, für die Umsetzbarkeit der Optimierungsansätze zu sorgen. Je Sprint bzw. Woche sind für die Retrospektive jeweils 45 Minuten einzuplanen.

Was heißt hier „erledigt“?

Da es das Hauptanliegen von Scrum ist, den Entwicklungsprozess für alle Seiten so transparent wie möglich zu gestalten, kommt man hier natürlich auch nicht ohne eine genaue Definition aus, was denn nun „erledigt“ genau bedeutet. Diese Definition of Done (DoD) wird durch das Team erstellt und enthält für gewöhnlich die Qualitätskriterien, funktionelle Bedingungen und nicht-funktionale Anforderungen an das zu erledigende Inkrement. Wie auch der gesamte Scrum-Prozess entwickelt sich die DoD beständig weiter und sorgt für einen stetigen Verbesserungsprozess. Durch die Elemente bzw. Kriterien, die die DoD enthält, lassen sich auch die einzelnen Tasks jedes Inkrements besser definieren und damit gestaltet sich die jeweilige Aufgabe für das Team transparenter. Das Team trägt auch die Verantwortung für die Einhaltung der DoD.

Ich habe „fertig“!

Ähnlich, wie es eine Definition of Done gibt, die festlegt, wann ein Inkrement fertig ist, gibt es auch eine Definition dafür, wann ein Inkrement in den Sprint übernommen werden kann – die Definition of Ready (DoR). Darin sind alle nötigen Vorbedingungen, Dokumentationen und Inputs definiert, die das Team braucht, um einen Eintrag im Product Backlog auch in den Sprint implementieren zu können. Der Product Owner hat entsprechend für die Einhaltung der DoR zu sorgen.

Pokern für das Team

Eine Methode, den Aufwand für eine Aufgabe abzuschätzen, die hier Anwendung findet, ist der Planungs Poker. Dabei erhält jeder Teilnehmer einen Satz Karten, die mit Schwierigkeitsgraden bedruckt sind. Unsere Karten sind mit Fibonacci-Zahlen (1, 2, 3, 5, 8, 13, 21, …) bedruckt, die die zunehmende Unsicherheit bei der Einschätzung schwererer Aufgaben wiedergeben. Der Spielablauf ist folgender:

1. Der Product Owner stellt die zu schätzende Aufgabe vor.
2. Fragen des Teams zu der Aufgabe werden diskutiert und geklärt.
3. Jedes Teammitglied wählt für sich eine Karte, die seiner Ansicht nach der Schwierigkeit der Story entspricht.
4. Alle gewählten Karten werden gleichzeitig aufgedeckt.
5. Die Teilnehmer mit der niedrigsten und der höchsten Schätzung erklären ihre Beweggründe.
6. Der Prozess wird dann noch einmal wiederholt und das Ergebnis dann als Basis für einen Konsens genutzt.
7. Das Spiel wird wiederholt, bis alle Aufgaben geschätzt sind.

Fazit

Auch wenn unsere Kunden nicht Teil des Teams sind, so sind sie doch im Entwicklungsprozess involviert und sowohl ihr Feedback als auch ihr Input sind wertvolle Bestandteile, die über den Product Owner einfließen. Der Planungsprozess mag zwar kompliziert und der Planungsaufwand groß erscheinen, letzten Endes sorgt SCRUM aber für deutlich mehr Transparenz bei den Entwicklern, den Kunden und dem Management auf der einen Seite und einer stetigen Verbesserung des Produktes – in unserem Fall DISKOVER SCO – auf der anderen Seite.