8 Vorteile von einem Agilen Projektvorgehen

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.

Herausforderungen an modernes 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.

Merkmale der agilen Methode

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.

Agiles Projektvorgehen

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.

Vorteile der agilen Vorgehensweise

• Reaktion auf Marktanforderungen
  Das Ziel ist, nach jedem Sprint eine lieferbare / einsetzbare Version des (Software-) Produkts zu haben. Damit hat der Product Owner die Möglichkeit, sein Produkt zu testen und wertvolles Kunden-/Marktfeedback einzuholen, was er wiederrum in die Weiterentwicklung einfließen lassen kann.

• Entwicklungsende jederzeit möglich
  Durch die Priorisierung werden immer die zu einem Zeitpunkt wichtigsten Anforderungen umgesetzt. Kombiniert mit der Lieferung eines fertigen Inkrements nach jedem Sprint kann der Product Owner jederzeit das Produkt für fertig erklären. Damit ist sichergestellt, dass der Kunde für sein bis dahin investiertes Geld den höchsten/besten Output erhalten hat.

• Flexibler Umgang mit neuen oder geänderten Anforderungen
  Während einer Projektabwicklung ist es keine Seltenheit, dass sich Projektanforderungen ändern oder dass Detailfragen hinsichtlich der Anforderungen auftreten, die bei Projektbeginn noch nicht sichtbar waren. Das heißt Anforderungen werden konkreter, neue Anforderungen kommen hinzu. Die Systematik der agilen Arbeitsweise ermöglicht es, Anforderungen unter Einbeziehung von Abhängigkeiten und Konsequenzen flexibel, zeitnah und reibungslos in das Projekt zu integrieren. Sie werden vom Product Owner in das Backlog eingefügt und entsprechende priorisiert. Dadurch kommen niedriger priorisierte Anforderungen erst später in die Umsetzung.

• Hohes Maß an Transparenz
  Durch die gepflegten Backlogs ist für jeden im Projekt ersichtlich, was geplant ist und was als nächstes drankommt. Nach jedem Sprint erfolgt ein Review der aktuellen Arbeitsstände. Der Product-Owner nimmt die fertiggestellten User Stories anhand der definierten Akzeptanzkriterien ab. Dadurch erfolgt eine Dokumentation des erreichten Standes. Der Kunde hat jederzeit Einblick in den aktuellen Entwicklungsstand, kann den Entwicklungsprozess begleiten und bei Bedarf Einfluss nehmen. Gleichzeitig erhält das agile Team stetig Feedback und kann nah am Kundenziel das Projekt umsetzen.

• Reduzierter Planungsprozess
  Durch die konsequente Priorisierung wird nur das spezifiziert und geschätzt, was für den nächsten Sprint benötigt wird. Es wird kein Aufwand in Themen, die später kommen und sich höchstwahrscheinlich sowieso noch ändern oder möglicherweise ganz entfallen, investiert. Damit verringert sich auch die aufwändige Behandlung von möglichen Abhängigkeiten.

•  Abschätzung auf Basis von Komplexitätspunkten
  Der Vorteil, auf Basis von Komplexität zu schätzen, ist, dass es dafür keine Detailplanung der Umsetzung benötigt. Neue Features werden mit dem Referenz-Feature in Relation gesetzt. Es braucht dafür keine meist aufwändige Diskussion der Umsetzungsdetails, in der das „Wie“ besprochen wird, was zu dieser Zeit jedoch noch keine Rolle spielt. Die Schätzung von Storypoints geht viel schneller und das Ziel einer zuverlässigen Liefervorhersagen ist gut erfüllbar. Auch wenn es zu Anfang eine große Umstellung für das Entwicklerteam bedeutet, die häufig mit dem Zeitschätzen vertrauter sind.

• Lieferzuverlässigkeit
  Mit jedem durchgeführten Sprint wächst das Team mehr zusammen, es lernt aus seinen Fehlern und Problemen. Mit zunehmender Erfahrung steigt die Teamkompetenz User Stories abzuschätzen und die Sprintplanungen werden sicherer bzw. genauer. Die Velocity (Anzahl Storypoints pro Sprint) stabilisiert sich. Die Lieferzuverlässigkeit nimmt zu. Angemerkt sei hier noch, dass das nur funktioniert, wenn das Team und die Teamkapazität stabil ist/bleibt.

• Kontinuierliche Verbesserung
  Durch die regelmäßigen Retrospektiven werden Probleme während des Projekts schnell erkannt und im nächsten Sprint kann ein entsprechend alternativer Weg gegangen bzw. können Maßnahmen ergriffen werden. Die kontinuierliche Verbesserung ist quasi im Prozess verankert.

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.