Bildnachweis: You X Ventures
Als Agentur, die täglich agile Prozesse in der Softwareentwicklung anwendet, sehen wir uns vor verschiedene Herausforderungen gestellt: Da wir keine eigenen Produkte bauen, sondern verschiedenste Webprojekte für Kunden realisieren, binden wir unsere Partner regelmäßig in den Feedback-Prozess und die Abnahme mit ein. Zudem arbeitet unser Team immer parallel an verschiedenen Projekten, die sich in unterschiedlichen Entwicklungsphasen befinden. Jedes Projekt und jeder Kunde erfordert eine individuelle Anpassung unseres agilen Prozesses, bei dem wir jedoch immer unsere Grundprinzipien verfolgen.
Bei unserem agilen Prozess handelt es sich um ein spezielles Verfahren, bei dem unser Auftraggeber eng eingebunden wird und alle Arbeitsergebnisse in einem inkrementellen, iterativen Prozess entstehen.
Dieser Prozess ist von einer verantwortungsbewussten und vertrauensvollen Zusammenarbeit beider Parteien geprägt.
Die Einzelaufträge werden mit Hilfe von sich wiederholenden 2-wöchigen Zyklen (“Sprints”) entwickelt. Das hierzu angewandte inkrementelle Vorgehensmodell beschreibt den Prozess der Softwareentwicklung, bei dem es darum geht, das Ziel (“Vertragsgegenstand”) durch die Zerlegung in kleine Arbeitsschritte greifbar zu machen und eine kontinuierliche Verbesserungen zu erreichen.
Vor jedem Sprint findet ein Meeting zur Ausarbeitung und Priorisierung der zu entwickelnden Anforderungen des Produkts (“Product Backlog”) statt. Die Erfassung aller Anforderungen geschieht über ein Projektmanegment Werkzeug, das allen am Projekt beteiligten Personen zugänglich ist. Mit laufendem Projektforschritt erarbeiten beide Parteien die Anforderungen gemeinsam. Der Projektverantwortliche seitens des Auftragnehmers (“Product Owner”) pflegt und priorisiert das Product Backlog regelmäßig. Die Anforderungen werden dabei in einem knappen Szenario oder Vorgang in möglich natürlicher Sprache beschrieben (“User Story”).
Vor Beginn jedes Sprints wird ein Planungsmeeting durchgeführt, bei dem der Product Owner und das Entwicklungsteam sowie bestenfalls auch der Projektleiter seitens des Auftraggebers teilnimmt. Dort wird eine Feinspezifikation vorgenommen und vereinbart, welche Anforderungen an den Vertragsgegenstand im anstehen Sprint umgesetzt werden. Für jeden Sprint wird ein neues Sprintboard erstellt. Beide Parteien betrachten diesen Sprint Backlog als die verbindliche Beschreibung der Anforderungen an den Vertragsgegenstand für den jeweiligen Sprint. Die Abnahme der Leistung erfolgt dann zum Ende des Sprints in einer Sprint Demo. Anforderungen, die nicht erfüllt sind, gelten als nicht abgenommen, werden wieder in das Product Backlog eingepflegt und im nächsten bzw. einem späteren Sprint umgesetzt.
ROLES / WHO?
DEVELOPMENT TEAM
- Die Mitglieder des Dev Teams haben multidisziplinäre Kompetenzen und steuern sich selbst, was bedeutet, dass alle anfallenden Aufgaben die im Entwicklungsprozess erledigt werden müssen, von seinen Mitgliedern eigenverantwortlich umgesetzt werden. Das Team plant vor jedem Sprint, welche Aufgaben erledigt werden sollen und setzt diese im Arbeitsprozess eines jeden Sprints um.
PRODUCT OWNER
- Die Aufgabe des Product Owner ist es, dafür Sorge zu tragen, dass das digitale Endprodukt alle Bedürfnisse verschiedener Interessengruppen (Kunde, Nutzer usw.) erfüllt. Hierzu pflegt er eine nach Wichtigkeit sortierte Liste namens Product Backlog, die alle Aufgaben ("Items") enthält, um dieses Ziel zu erreichen. Die Priorisierung der Items, die dem Produkt hinzugefügt werden sollen, zählt dabei zu seinen wichtigsten Aufgaben. Diese legt er nach maximalem Wert für den Kunden und in Abstimmung mit den verschiedenen Stakeholdern fest.
- Für unsere Kunden ist der Product Owner auch entsprechend der Account Manager, ein definierter Ansprechpartner über die Projektlaufzeit und während der laufenden weiteren Betreuung.
SCRUM MASTER
- Der Scrum Master spielt eine entscheidende Rolle für das Coaching des Dev Teams und achtet darauf, dass die Grundprinzipen bzw. Scrum Spielregeln befolgt werden. Seine Wichtigste Aufgabe ist es, dem Team alle zur Erfüllung des Sprintziel notwendigen Ressourcen zu Verfügung zu stellen. Er beseitigt möglicherweise auftretende Hinternisse ("Impediments"), sodass sich das Dev Team vollständig auf die Aufgabenlösung konzentrieren kann und zu jeder Zeit effizient und qualitativ hochwertiger Output gewährleistet wird.
LISTS / WHAT?
SPRINT
- Scrum verfolgt einen iterativen Prozess, bei dem jede Phase Sprint genannt wird. Ein Sprint dauert in der Regel mindesten 2 und maximal 4 Wochen. Die Aufgaben, die innerhalb diesen Zeitraums erledigt werden und dem Softwareprodukt als Items angefügt werden, werden vor jeden Sprint genau definiert, geschätzt und priorisiert. Am Ende jedes Sprint werden die neuen Funktionen getestet und so erhält das Dev Team direktes Feedback zum Produkt.
PRODUCT BACKLOG
- Das Product Backlog ist eine Liste, die alle Aufgaben enthält, die das Produkt erhalten soll. Diese sog. Backlog Items werden häufig in Form von User Stories formuliert. Jedes Item wird vom Team und dem Product Owner auf seinen Wert für das Endprodukt geschätzt und entsprechen höher oder niedriger im Umsetzungsprozess priorisiert. Ein gut gepflegter Backlog sollte immer genügend Items enthalten, um einen neuen Sprint füllen zu können.
- Der Product Owner arbeitet bei der Priorisierung des Backlogs eng mit dem Projektleiter auf Kundenseite zusammen. Um Verzögerungen zu vermeiden hat dabei der Kunden-Projektleiter idealerweise weitreichende Entscheidungsbefugnisse.
SPRINT BACKLOG
- Beim Sprint Backlog handelt es sich um die Liste aller Aufgaben,, die aus den Product Backlog Items für den aktuellen Sprint eingeplant wurden und vom Team im zeitlich vorgegebenem Rahmen erledigt werden. Die Items werden dabei im Sprint Planning Meeting in einzelne Aufgaben zerlegt. Die Teammitglieder entscheiden anhand ihres Know-Hows selbst, welche Aufgaben sie aus dem Sprint Backlog erledigen können.
MEETINGS / HOW?
DAILY SCRUM
- In maximal 3 Minuten berichtet jeder Teilnehmer im Daily Scrum, welchen Aufgaben er seit dem letzten Termin bearbeitet hat, welche er bis zum nächstem Meeting erledigen möchte und ob es hierbei Blocker gibt, die ihn von seinem Ziel abhalten oder er Hilfe benötigt. Die 3 Kernfragen lauten:
- Was habe ich seit dem letzten Meeting getan?
- Was werde ich bis zum nächsten Meeting tun?
- Welche Aufgaben habe ich und welche Hilfe benötige ich dabei?
SPRINT PLANNING
- Zu Beginn eines Sprints führt das Team ein Sprint Planning Meeting, in welchem der Product Owner die zu erledigenden Aufgaben erläutert. Anschließend werden gemeinsam die Items aus dem Product Backlog in den Sprint Backlog genommen, die sicherstellen, dass die avisierten Sprintziele erreicht werden können.
REVIEW
- Zum Abschluss des iterativen Sprintprozesses wird das Sprint Ergebnis idealerweise in Beisein des Kunden vorgestellt, zum Beispiel in Form einer Demo. Durch die Vorstellung werden die im Sprint erreichten Fortschritte gezeigt und Stakeholder erhalten einen Einblick zum Status des Produkts. Zudem können Sie auch direkt Feedback geben.
RETROSPECTIVE
- Zum Schluss einer Sprintphase wird zudem ein internes Verbesserungsmeeting durchgeführt, in dem alle Beteiligten des Produktentwicklungsteams darüber in einer konstruktiven und offenen Art reflektieren, was aus dem Sprint gut lief, gelernt und in Zukunft an der Zusammenarbeit verbessert werden kann.
BACKLOG REFINEMENT
- Die Aufgabe beim Backlog Refinement besteht darin, die Items so vorzubereiten und alle nötigen Informationen einzuholen, damit diese als Basis für das Sprint Planning genutzt werden können und das Entwicklerteam weiß, welche konkreten Aufgaben zu tun sind. Hier muss im Vorfeld mit verschiedenen Stakeholder abgestimmt werden, wie ein Prozess genau aussehen soll. Oftmals wird auch der Aufwand der Items von den Teilnehmern geschätzt (=Planning Poker)
Weitere Begriffe im SCRUM
Photo von İrfan Simsar via Unsplash
TASK BOARD
- Über das Task Board wird der Status jeder Aufgabe (Task, User Story) visualisiert. Task Boards können über eine physisch als Wandtafel oder wie bei zauberware digital über eine Projektmanagement-Software (z. B. Teamwork, Jira, Asana, Trello) gepflegt werden.
USER STORIES
- Eine User Story ist das zentrale Element zur Beschreibung von Anforderungen im agilen Kontext. Alle User Stories werden im Product Backlog festgehalten. "Als Rolle möchte ich Ziel/Wunsch um Nutzen zu erreichen“.
EPICS
- Sehr grob formulierte User Stories, deren Umsetzung von einer Vielzahl an einzelnen Items bzw. Aufgaben abhängt. Epics sollten vor einem Sprint Planning in einzelne Teile zerlegt werden, um die Komplexität zu verringern, da sie nicht alle in einen zeitlich limitierten Sprint eingeplant werden können.
TEAM VELOCITY
- Das Volumen, welches das Dev Team innerhalb eines Sprint abarbeiten kann. Idealerweise wird die Menge dokumentiert, sodass das Team von Mal zu Mal besser einschätzen kann, welche Menge realistisch geleistet werden kann.
