20.05.2021
Projektvorgehen
Luisa Stresemann unter der Betreuung von Cathleen Schwarze
Agiles Vorgehen ist in aller Munde und scheint inzwischen das Standardvorgehen für IT-Projekte zu sein. Doch welche Vorteile versprechen sich die Umsetzer, wenn sie dieses Vorgehen wählen? Der folgende Artikel beschreibt den Aufbau und die Vorgehensweise, sowie die Rollenverteilung bei agilen Methoden. Daraus ergeben sich zentrale Vorteile für das moderne Projektmanagement.
Die heutige Welt ist stets im Wandel und Projekte nehmen hinsichtlich Anforderungsumfang und Komplexität zu. Dieser Umstand ist eine enorme Herausforderung für das Projektmanagement: Die Aufgaben und deren Komplexität sind bei Projektbeginn nicht vollumfänglich greifbar und eindeutig definiert. Weiterhin ändern sich Anforderungen und externe Faktoren während der Projektrealisierung, sodass alternative Lösungswege gefunden und kurzfristig realisiert werden müssen. Bei einem klassischen Wasserfall-Projekt würde dies die initial getätigte Planung immer wieder unbrauchbar machen und eine Neuplanung muss erfolgen. Der agile Ansatz bietet ein Vorgehensmodell, welches Komplexität, Anforderungswechsel und Skalierung handhabbar macht.
Bei der Anwendung des agilen Vorgehensmodells werden Aufgabenkomplexe, welche für die Umsetzung des Projekts notwendig sind, in kleinere Unteraufgaben für einen überschaubaren Zeitraum heruntergebrochen. Dadurch werden die zu bearbeitenden Themen hinsichtlich Komplexität und Aufwand bewertbar. Insgesamt werden somit große undurchsichtige Aufgabenkomplexe in kleine Einheiten zerlegt, wodurch die Komplexität abnimmt und die Einzelschritte definierbar werden.
Ein grundlegendes Werkzeug der agilen Methode ist das sogenannte Backlog. Dieses enthält alle Anforderungen, die durch das Projektteam zu realisieren sind in priorisierter Reihenfolge. Je weiter hinten die Anforderungen sind, um so unspezifischer bzw. gröber sind sie. Das Sprint-Backlog beinhaltet die Sammlung an heruntergebrochenen Aufgaben, welche durch das Team im aktuellen bzw. kommenden Sprint bearbeitet werden müssen. Wesentliche Merkmale des Sprint-Backlogs sind die Sichtbarkeit von Komplexitäten an jeder einzelnen Anforderung und die Sortierung der Abarbeitung.
Das Rollenkonzept des agilen Projektmanagements umfasst das Entwicklerteam, den Product Owner, sowie den Scrum-Master. Das Entwicklerteam umfasst alle Personen mit fachlichem Bezug zur Realisierung von Projektaufgaben. Der Product Owner ist für das Produkt / Projekt inhaltlich verantwortlich. Er verwaltet die Anforderung, spezifiziert diese und bringt sie in eine Reihenfolge. Er definiert die Akzeptanzkriterien und nimmt das entwickelte Software-Artefakt ab. Er steht dem Entwicklerteam als Ansprechpartner zur Verfügung und ist die Schnittstelle zu allen Stakeholdern, die das Ergebnis benutzen werden.
Der Scrum-Master ist verantwortlich für den Prozess. Er organisiert und moderiert die typischen Scrum-Meetings, behandelt Konflikte und Spannungen und tut alles was notwendig ist, damit das Entwicklerteam gut arbeiten kann.
Die typische Projektleiter-Rolle wie wir sie aus dem klassischen Wasserfall-Projekten kennen, gibt es im Scrum nicht. Deren Aufgaben wurden auf das gesamte Team verteilt.
Die Schätzung von Aufgaben erfolgt mit Hilfe von Komplexitätspunkten, so genannter Storypoints. Das ist fundamental anders als beim klassischen Projektmanagement, bei dem mit einer zeitlichen Aufwandsabschätzung gearbeitet wird. Bei der Schätzung auf Basis von Komplexität werden die Anforderungen in Beziehung zu einer Referenzanforderung gesetzt. Die Referenzanforderung ist eine Anforderung, die bereits umgesetzt wurde, deren Komplexität allen Projektmitgliedern bekannt ist und die eher eine geringe Komplexität beinhaltet. Sie wird meist mit 1 oder 2 Storypoints belegt. Alle neuen Anforderungen werden mit dieser in Relation gesetzt. Die Storypoints spiegeln also die Komplexität der Aufgabe wider. Der zeitliche Aufwandsaspekt hat im Planungskonstrukt der Agilität eine untergeordnete Rolle.
Abgearbeitet werden die Aufgaben typischerweise in sogenannten Sprints. Dabei handelt es sich um definierte Zeiträume bzw. Zeitintervalle. In der Praxis sind Sprints über zwei oder drei Wochen üblich. Vor jedem Sprint findet ein Planungsmeeting statt. Der Product Owner stellt seine priorisierten Anforderungen vor. Das Entwicklerteam entscheidet, welche davon „reif“ genug sind, um in das Sprint-Backlog und damit für die Umsetzung aufgenommen werden zu können. In jedem Sprint kann pro Teammitglied eine gewisse Anzahl an Komplexitätspunkten bearbeitet werden. Die maximal möglichen Komplexitätspunkte pro Sprint ergeben sich aus Erfahrungswerten der Vergangenheit. Fachlich spricht man auch von Velocity. Am Ende eines Sprints erfolgt das sogenannte Review. Bei diesem Meeting stellt das Team dem Product Owner das Arbeitsergebnis vor.
Ein weiteres wichtiges Meeting am Ende des Sprints ist die Retrospektive. In dieser reflektiert das Projektteam was in der vergangenen Iteration gut lief und wo es Verbesserungsmöglichkeiten gibt. Im Gegensatz zum Review, in dem das Ergebnis begutachtet wird, steht in der Retrospektive der Zusammenarbeitsprozess im Fokus. Damit werden stetige Verbesserung und der Zusammenhalt im Team forciert.
Angemerkt sei hier noch, dass das nur funktioniert, wenn das Team und die Teamkapazität stabil ist/bleibt.
Um die Vorteile der agilen Arbeitsweise nutzen zu können, braucht es bei allen Beteiligten ein verändertes Werteverständnis bzw. eine andere Einstellung, sprich ein gemeinsames Mindset. Kunden bzw. Product Owner müssen sich darauf fokussieren immer das Wichtigste zu priorisieren und den Nutzen im Blick zu behalten vs. feste Zusagen bzgl. Scope und Budget zu erwarten. Die Entwickler übernehmen Verantwortung für ihre Lieferversprechen und schätzen nun in Komplexität statt in Zeiteinheiten. Manager müssen ihre Teams stabil halten, um Lernen und Kompetenzwachstum zu ermöglichen und damit High-Performance-Teams zu schaffen.