Am 9. Mai 2019 erläuterte Achim Kämmler, ein Mann mit jahrzehntelanger Erfahrung im Bereich der Softwareentwicklung und Mitarbeiter des Fraunhofer Instituts, die Prinzipien eines moderneren Ansatzes für Software Development: Scrum.
Scrum schwört den Werten des Manifests für Agile Softwareentwicklung die Treue. Demnach wird Individuen, Ergebnissen und Flexibilität eine höhere Priorität als detaillierter Dokumentation, Verträgen, rigiden Plänen und den benutzten Prozessen beigemessen. Das Wort selbst ist dem Rugbyjargon entnommen, um die Wichtigkeit der Zusammenarbeit zu unterstreichen.
Scrum kann in drei Hauptbestandteile unterteilt werden: Rollen, Zeremonien und Artefakte. Die verschiedenen Rollen beschreiben, welchen Platz jedes Mitglied der Gruppe, die aus fünf bis neun Personen besteht, innerhalb des Projektes einnimmt. Der Product Owner, idealerweise auch Bestandteil derjenigen Partei, für die die Software entwickelt wird, definiert, priorisiert und passt die benötigten Features an, entscheidet über das Datum der Veröffentlichung und ob die erbrachten Resultate angenommen oder verworfen werden und ist weiterhin verantwortlich für den Profit des Projekts. Der ScrumMaster unterstützt im wesentlichen das Team durch das Durchsetzen und Aufrechterhalten der “ideologischen” Werte von Scrum, das Entfernen von Hindernissen und Störungen von außen und er ermöglicht enge Zusammenarbeit. Jedoch trifft der ScrumMaster keine Entscheidungen für das Team. Das Team besteht üblicherweise aus Vollzeitmitgliedern, die alle in mehreren Bereichen der Entwicklung tätig sind. Umgekehrt ist auch jedes Aufgabenfeld von mehreren Personen besetzt.
Die Zeremonien beschreiben die gesamte Struktur von Scrum. Zu allererst wird ein sogenannter Sprint geplant. Ein Sprint ist eine zwei- bis vierwöchige Arbeitsphase mit dem Ziel ein lieferbares Produktinkrement zu erzeugen. Für eine vernünftige Planung wird das Product Backlog, ein Anforderungskatalog, analysiert und ein konkretes Ziel für den Sprint, welches auf die Erfüllung einer oder mehrerer dieser Anforderungen hinarbeitet, wird festgelegt. Die oberste heilige Scrum-Regel verbietet, dass dieses Ziel während des Sprints verändert wird. Zudem wird das initiale Backlog des Sprints, eine Liste von Tasks, welche dazu dienen, das Ziel des Sprints zu erfüllen, erstellt. Während des Sprints wird zu Beginn jedes Arbeitstages ein Daily Scrum abgehalten, eine fünfzehnminütige Zeremonie, in der alle Beteiligten kurz darüber sprechen, was sie gestern getan haben, heute tun werden und ob sie auf irgendwelche Probleme gestoßen sind. Tasks können dem Sprint Backlog frei hinzugefügt und nach Bedarf angepasst werden. Für jeden Punkt des Backlogs wird eine täglich aktualisierte Abschätzung der verbleibenden Arbeitsstunden kreirt. Teammitgliedern werden keine Tasks fest zugewiesen, sie entscheiden selbst, an welchem Task sie arbeiten möchten, weshalb schlussendlich jeder Verantwortung am Projekt trägt. Danach präsentieren die Gruppenmitglieder dem Rest der Gruppe im Rahmen des Sprint Reviews informell ihre Ergebnisse. Während der Sprint Retrospective inspizieren alle, was funktioniert oder nicht funktioniert, beispielsweise durch Klären der Fragen, was man beginnen sollte zu tun, womit man aufhören sollte und welche Aktivitäten fortgeführt werden können. Nach Ende all dessen wird der nächste Sprint geplant.
Artefakte sind die zuvor genannten Backlogs und ein Burn-Down-Chart, eine Visualisierung des verbleibenden Arbeitsaufwands in Relation zur verbleibenden Zeit.
Für Projekte, die mehr Personen erfordern, kann ein Scrum of Scrums realisiert werden. Jede Gruppe delegiert ein Mitglied für ein Treffen zur Koordination und Kommunikation.
Die enge Zusammenarbeit mit dem Kunden reduziert das Risiko, das falsche Produkt zu erstellen, erheblich und nach Erfahrung des Sprechers hatte der Wechsel vom Wasserfallmodell zu Scrum eine Steigerung der Produktivität von circa 40 bis 50 Prozent zur Folge. Jedoch gab er auch zu bedenken, dass Programmierer nun unter größerem Stress litten.
Insgesamt war es sehr faszinierend, etwas über agile Softwareentwicklung von jemandem zu hören, der in “beiden Welten” intensiv involviert war und gerne detaillierte Einblicke in nahezu alle damit zusammenhängenden Aspekte lieferte.
