“Ein Rahmenwerk, innerhalb dessen 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.” (Scrum.Org and ScrumInc, 2015) Das ganze Rahmenwerk Scrum ist im sogenannten Scrum Guide definiert.

Scrum ist ein Rahmenwerk (engl. Framework), welches auf Empirie beruht. Alle Entscheidungen die getroffen werden beruhen auf den Erfahrungen, welche vorher gemacht wurden. Dies soll dabei helfen Risiken in Projekten besser zu kontrollieren. Das Rahmenwerk wird auf drei Säulen aufgebaut:

• Transparenz
• Überprüfung
• Anpassung

Transparenz bedeutet, dass stets für jeden Teilnehmenden klar ist, wann die aktuelle Aufgabe abgeschlossen (Definition of Done) ist und wie der aktuelle Status der Aufgabe ist. Überprüfung heißt im Scrum-Kontext, dass die momentane Aufgabe immer mit Blick auf die Definition of Done betrachtet werden muss. Abweichung, welche nicht in der Definition of Done enthalten sind, sind zu vermeiden. Die Anpassung wird meistens nach einer Überprüfung durchgeführt. Das ist vorallem dann nötig, wenn des Produkt nicht mehr den Erwartungen entspricht. Sowohl Überprüfung, als auch Anpassungen werden im Normalfall während des Sprint Plannings, Daily Scrums, Sprint Review und Sprint Retrospektive durchgeführt (siehe Kaptiel SCRUM GRUNDLAGEN EREIGNISSE). (Scrum.Org and ScrumInc, 2015)

Der Kern des Scrumteams besteht aus drei Personengruppen:

• Product Owner
• Entwicklungsteam
• Scrum Master

Alle Gruppen arbeiten eigenständig voneinander. Beispielsweise darf dem Entwicklungsteam nicht vorgeschrieben werden, wie sie etwas entwickeln müssen und welche Tools sie dafür ein zu setzen haben. In diesem Fall ist es lediglich von Priorität, dass das Ziel des Projektes erreicht wird.

Im Scrum Guide wird der Product Owner wie folgt definiert: “Der Product Owner ist für die Wertmaximierung des Produkts sowie der Arbeit des Entwicklungsteams verantwortlich.” Es handelt sich dabei lediglich um eine Person und nicht eine Gruppe von Personen. Der Product Owner ist die einzige Person, welche für den Product Backlog verantwortlich ist. Der Product Backlog ist eine Liste die alle Dinge umfasst, welche im finalen Produkt enthalten sein sollen. Er ist niemals vollständig und muss stets angepasst und erweitert werden. Der Product Owner ist dazu verpflichtet den Product Backlog so genau und klar zu formulieren, dass jeder diesen versteht. Auch ist es wichtig, dass diese Liste nach Priorität sortiert wird vom Product Owner, sodass das Entwicklungsteam effizient und optimal arbeiten kann.

Das Entwicklungsteam sind die einzigen, welche sogenannte Inkremente entwickeln. Ein Inkrement ist das Resultat aus vorherigen Inkrementen und den in einem Sprint (siehe Kaptiel SCRUM GRUNDLAGEN EREIGNISSE) bearbeiteten Einträgen aus dem Product Backlog. Da das Entwicklungsteam selbstorganisiert arbeitet, muss das Team als Ganzes über alle nötigen Fähigkeiten verfügen um ein Inkrement entwickeln zu können. Wichtig ist, dass, wenn es zu einem Versagen kommt und ein Ziel nicht erreicht wurde, das ganze Team dafür verantwortlich ist und nicht eine einzige Person.

Die letzte der drei Personengruppen ist der Scrum Master. Dieser ist dafür zuständig, dass jeder im Scrumteam Scrum versteht und Scrum auch korrekt durchgeführt wird. Sein Ziel ist es die Zusammenarbeit zu optimieren und damit den generierten Wert zu maximieren. So hilft der Scrum Master dem Product Owner den Product Backlog zu erabeiten und ihn so zu formulieren, dass er von jedem verstanden wird. Dem Entwicklungsteam soll der Scrum Master so helfen, dass diese besser selbstorganisiert arbeiten können und so hochwertige Produkte entwickeln. Dazu zählt beispielsweise auch das Beseitigen von Hindernissen und die Erklärung und Organisation von Scrum. (Scrum.Org and ScrumInc, 2015)

Das wichtigste Ereignisse im Ablauf von Scrum ist der Sprint. Der Sprint ist zeitlich begrenzt auf einem Monat und minimal eine Woche. Während des Sprintes wird ein Produkt-Inkrement entwickelt, welches die gesetzte Definition of Done erfüllt und potenziell auslieferbar ist. Zwar ist es möglich einen Sprint abzubrechen, aber auf Grund der Kürze des Sprints ist dies nur dann zu tun, wenn das Ziel des Sprintes obsolet geworden ist. Dies hat lediglich der Product Owner zu entscheiden.

Zu Anfang eines Sprintes kommt das Sprint Planning. Die Dauer des Plannings ist an die Dauer eines Sprintes anzupassen. Empfohlen wird für einen ein monatigen Sprint ein acht Stunden Planning. In einem Sprint Planning wird geplant, welche Teile des Product Backlogs im Sprint-Inkrement enthalten sein sollen. Dabei kann das Entwicklungsteam beurteilen, welche Funktionalität zeitlich gesehen in der Dauer des Sprintes implementiert werden kann. Hat das Entwicklungsteam entschieden, welche Einträge aus dem Product Backlog im Sprint bearbeitet werden sollen, verfasst das komplette Scrum Team ein Sprint-Ziel. Das Ziel soll erklären warum das Inkrement entwickelt wird und was erreicht werden muss. Die vom Entwicklungsteam ausgewählten Einträge aus dem Product Backlog für einen Sprint werden als Sprint Backlog bezeichnet. Folgend berät das Entwicklungsteam wie sie die Einträge aus dem Sprint Backlog entwickeln sollen beziehungsweise können. Bei Verständnisfragen kann der Product Owner helfen. Zuletzt erklärt das Entwicklungsteam, sowohl Scrum Master als auch Product Owner, wie es diesen Sprint verfahren will.

Folgend hält das Entwicklerteam täglich das sogenannte Daily Scrum ab. Im Daily Scrum erklärt jede einzelne Person was sie am gestrigen Tage erreicht hat, was sie heute erreichen will und welche Hindernisse sie sieht. Alles mit Hinblick auf das Sprint-Ziel. Der Scrum Master ist beim Daily Scrum nur dafür verantwortlich, dass es durchgeführt wird und keine anderen Personen, außer dem Entwicklerteam, daran teilnehmen. Das Daily Scrum ist auf 15 Minuten Dauer beschränkt.

Am Ende eines Sprintes wird das Sprint Review und die Sprint Retrospektive durchgeführt. Während des Sprint Reviews wird vom Entwicklerteam das Sprint-Inkrement vorgeführt. Es handelt sich dabei um ein informelles Meeting, welches für einen einmonatigen Sprint eine Dauer von vier Stunden nicht überschreiten sollte. Es ist nicht dazu gedacht einen Statusreport abzugeben, da es vielmehr dem Entwicklerteam Feedback geben soll. Bei dem Sprint Review ist es auch möglich, dass der Product Owner Stakeholder einlädt. Diese können meist noch genaueres Feedback stellen. Wichtig ist, dass das Entwicklungsteam Entwicklungsprobleme nach außen hin kommuniziert. Dies gilt auch wenn diese während des Sprintes schon gelöst wurden. Weiterhin ist es während des Sprint Reviews notwendig zu überprüfen, ob sich die Marktsituation verändert hat und sich somit neue Ziele ergeben, welche im Product Backlog festgehalten werden müssen. So wird das Product Backlog von Sprint zu Sprint immer weiter überarbeitet und somit optimiert. Nach dem Sprint Review wird die Sprint Retrospektive durchgeführt, wobei eine Dauer von drei Stunden bei einem ein monatigen Sprint nicht überschritten werden sollte. Diese Zeit dient dem Scrum Team als Phase der Selbstreflexion. Im Besonderen müssen die Prozesse während des letztens Sprints und die Kommunikation zwischen den teilnehmenden Personen begutachtet werden. Das Scrum Team arbeitet während der Sprint Retrospektive “einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Scrum Teams” aus. Das soll wiederum die Arbeitsweise des Teams effektiver machen, was dazu führt das der Wert des Produktes maximiert wird. (Scrum.Org and ScrumInc, 2015)

Bei der Entwicklung des Dokumentationstools wurde innerhalb des Projektes für einen Teil der Mitarbeiter zum ersten Mal Scrum zur Arbeitsorganisation verwendet. Auf Grund dessen wurde vor dem Start des Projektes eine Präsentation vorgstellt, welche allen Teilnehmenden die Grundzüge von Scrum nahe bringen sollte.

Rolf Becker ist im Projekt der Product Owner. Da er zum ersten Mal Scrum verwendete und keine offzielle Zertifizierung als Product Owner von Scrum.org besitzt, wurde er beim Product Backlog durch das Entwicklungsteam unterstützt. Dieses besteht aus Fabian Joeken und Jan Sonntag. Nach dem Scrum Guide ist die Größe von zwei Leuten bei einem Entwicklerteam eigentlich zu gering. Es wird eine Größe von mindestens drei Personen bis maximal neun Personen vorgeschlagen. Dies liegt vor allem daran, dass angenommen wird, dass eine so geringe Zahl an Entwicklern kein Inkrement in einem Sprint entwickeln kann. Die geringere Anzahl von Entwicklern wurde während des Sprint Plannings beachtet. Scrum Master ist Jan Sonntag, da er bereits als solcher zertifiziert ist. Er führte vor Beginn des Projektes auch die Präsentation durch, in welcher die Grundzüge von Scrum erklärt wurden.

Auch wenn die Länge von Sprints eigentlich nicht über die Dauer eines Projekts hin verändert werden sollte, wurde entschieden, dass der erste Sprint eine Länge von zwei Wochen haben sollte und die Folgenden eine Dauer von lediglich einer Woche. Dies lag vorallem daran, dass zunächst einmal viel Grundlagenentwicklung durch geführt werden musste. Dazu zählt beispielsweise das Planen einer Architektur, aber auch das Ausprobieren von mehreren Technologien und Ansätzen. Da jedoch mit einem kleinem Entwicklungsteam, es nicht möglich ist diese grundlegende Entwicklung innerhalb einer Woche zu einem Inkrement zusammenzufügen wurde im ersten Sprint Planning die Dauer des Sprints angepasst.

Zunächst wurden die Sprint Plannings Montags durchgeführt, dies wurde aber nach wenigen Sprints auf Freitags verschoben, auf Grund von Terminkollisionen. Diese Terminkollisionen haben die Effektivität von Scrum und die des Teams vermindert, so war es effektiver die Scrum-Meetings zu verschieben. Da die Entwicklung des Dokumentationstools, besonders für den Product Owner und auch die Stakeholder, nicht die einzigen Projekte waren, wurden das Sprint Planning, Sprint Review und die Sprint Retroperspektive folgend an einem Tag pro Sprint als ein größeres Scrum-Meeting abgehalten. Organisator war der Scrum Master.

Begonnen wurde mit dem Sprint Review. Bei diesem waren meistens noch weitere Stakeholder anwesend. Ein wichtiger Stakeholder ist und war Norbert Gröger, als Sachverständiger der Landwirtschaftskammer NRW und Teilnehmer im Projekt Gärtners Grüner Daumen. Auch haben weitere Stakeholder teilgenommen, welche meistens für das Projekt Gärtners Grüner Daumen weitere Applikationen, die eng mit dem Dokumentationstool zusammenarbeiten sollen, entwickeln. Nach dem Sprint Review hat das Scrum Team mit dem Sprint Planning des nächsten Sprintes begonnen. Dabei konnten besonders die davor gesammelten Informationen aus dem Sprint Review helfen. Nach dem Sprint Planning hat das Entwicklerteam unter sich eine Schätzung der gewählten Backlog Items durchgeführt. In Scrum gibt es keine genauen Vorgaben, wie die einzelnen Elemente des Product Backlogs aufgebaut sein müssen. In diesem Fall wurde entschieden, dass sogenannte User Stories verwendet werden. Preußig definiert User Storys wie folgt: “Eine User Story besteht typischerweise nur aus einem oder ein paar wenigen Sätzen und beschreibt einen Anwendungsfall auf grober Ebene.” Zusammengefasst wurden die User Storys in sechs Epics. “Mit einem Epic (…) werden im agilen Projektmanagment mehrere, miteinander in Verbindung stehende Anwendungsfälle zusammengefasst.” (Preußig, 2015) Eine genaue Beschreibung und Analyse der Epics und User Storys ist in Kapitel ANALYSE SZENARIO zu finden. Die für einen Sprint ausgewählten User Storys wurden dann beim sogenannten Planning Poker geschätzt. Bei dem Schätzen soll jeder Entwickler unabhängig Anderer einschätzen wie viel Aufwand eine User Story macht bis ihre Definition of Done erfüllt ist. Es werden dabei Story Points vergeben. Diese haben keinen Umrechnungsfaktor in beispielsweise die reale Zeit, sondern müssen stets relativ zu den Schätzungen anderer User Storys betrachtet werden. Durch das Schätzen konnte im Entwicklerteam stets eine Diskussion über die User Storys geführt werden. Dies half dabei die User Storys besser zu verstehen und eine besser Implementierungslösung zu finden. Nach dem Sprint Planning wurde dann mit dem Sprint begonnen. Da das Entwicklerteam lediglich aus zwei Entwicklern bestand, hat sich das Daily Scrum meistens auf direkte Textnachrichten beschränkt. Teilweise wurden aber auch größere Entwicklungen in Meetings besprochen.

Die Benutzung des Scrum Frameworks als agile Methode im Projekt hatte sowohl Vor- als auch Nachteile, wobei die Nachteile sich nicht auf die Effektivität der Entwickler ausgewirkt haben. Die Vorteile im Projekt sind klar erkennbar. Der größte Vorteil war der enge Kontakt zu den Stakeholdern. So konnte jede Woche ein Feedback zum aktuellen Stand des Projektes eingeholt werden. Das machte es besonders einfach innerhalb einer Woche Anpassungen vorzunehmen. Ohne diesen steigen Austausch wäre das Dokumentationstool in eine andere Richtung entwickelt worden. Dies hätte zur Folge gehabt, dass zum Ende des Projektes hin, tiefgreifende Änderungen hätten vorgenommen werden müssen. Zu diesem Zeitpunkt hätte das viel Zeit gekostet, die wohlmöglich nicht vorhänden gewesen wäre. Weiterhin ermöglichte Scrum es auch, dass die Entwickler das Inkrement aus einer anderen Sichtweise betrachten konnten. Ein weiterer Vorteil war es, dass über den Product Backlog stets für alle Teilnehmenden einsehbar war, wie weit das Projekt fortgeschritten ist und welche User Storys momentan bearbeitet werden. Besonders den Entwicklern half es, akkurate Planungen für jeweils die nächste Woche zu treffen. Als ein Nachteil ist anzusehen, dass Scrum nicht perfekt umgesetzt werden konnte. Dies lag zum einen an der Terminplanung und damit an manchen Terminkollisionen, zum anderen wurden die Abläufe in den Scrum Meetings besonders zum Ende des Projektes hin nicht mehr richtig befolgt. Dies scheint sich aber nicht sonderlich auf die Effektivität ausgewirkt zu haben. Das lag vor allem daran, dass zum Ende hin weniger neue Funktionen implementiert wurden, sondern die meiste Zeit für das Ausmerzen von Fehlern verwendet wurde. Trotzdem gab es noch einen regelmäßigen Austausch mit den Stakeholdern, sodass trotzdem noch weitere Detailanpassungen gemacht werden konnten.

Scrum hat im Projekt einen wichtigen Nutzen gehabt, und trotz der nicht perfekten Umsetzung, seine Wirkung nicht verfehlt.