16.06.2022
E-Commerce Beratung
Diana Labs | Projektleiterin
Agiles Vorgehen – warum hängt der Projekterfolg wesentlich von Ihnen als Auftraggeber ab?
Agiles Vorgehen bedeutet eine sehr viel engere Zusammenarbeit zwischen Auftraggeber und Dienstleister als bisher – und das von Beginn an. Einige unterschätzen das und werden von der Intensität und dem Umfang der Einbeziehung in das agile Projekt überrascht.
Festlegung der Projektziele durch den Projekt-Sponsor
Warum führen Sie als Auftraggeber, also Projekt-Sponsor, dieses Projekt durch? Wann ist das Projekt für Sie erfolgreich? Was muss mindestens erfüllt sein, damit das Projektergebnis für Sie wertvoll ist? In vergangenen Blogartikeln sind wir bereits darauf eingegangen, wie wichtig klare Projektziele und die Priorisierung von Anforderungen im agilen Projektvorgehen sind (> zum Blogartikel ).
Eines der Prinzipien aus dem Manifest für Agile Softwareentwicklung lautet, „… den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen“(Quelle). Wertvolles entsteht aber nur, wenn Sie auch benennen können, was wertvoll für Sie ist.
Zur Veranschaulichung nutzen wir ein vermeintlich abwegiges Vorhaben - die Einrichtung einer Kindertagesstätte: Als Ziel für das Produkt/das Projekt „Einrichtung einer Kindertagesstätte“ wird vereinbart, zum frühestmöglichen Zeitpunkt mindestens zwei Gruppen für Kinder ab drei Jahren zu öffnen. Diese Zielstellung und das Vorgehen zur Zielerreichung müssen auch die für das Vorhaben einbezogenen Dienstleister kennen, um die eigene Arbeitsweise und die Arbeitsplanung daran auszurichten.
Für die Realisierung der Ziele benennt der Projekt-Sponsor einen Product Owner.
Eine Lanze für die Rolle “Product Owner”
Der Product Owner ist für die Zielerreichung des Projekts verantwortlich. Das ist leicht gesagt, jedoch anspruchsvoll in der Praxis. Das Projektergebnis ist das „Produkt“, auch wenn es vielleicht gar kein Produkt ist, sondern – wie in unserem Beispiel - die Einrichtung einer Kindertagesstätte.
Aufgabe des Product Owner ist es, Anforderungen an das „Produkt“ im sogenannten Product Backlog zu sammeln und in Bezug auf die Notwendigkeit für die Zielerrichtung – vorgegeben durch den Projekt-Sponsor - zu bewerten. Dafür müssen alle zukünftigen Anwender-Rollen und die wichtigsten Vertreter benannt und diese für die Mitarbeit im Projekt gewonnen werden. Die Vertreter der zukünftigen Anwender-Rollen müssen bereit sein, ihre Anforderungen zu formulieren und zwischen „ohne geht’s nicht“ (Must Have), „wäre prima, wenn“ (Should Have), „wäre auch nicht schlecht“ (Could Have) und “diesmal nicht, wird aber für die Zukunft vorgemerkt” (won’t have) zu unterscheiden (MoSCoW-Priorisierungmethode (Quelle)). Nicht alle Anforderungen sind gleich wichtig.
Dieser Aspekt verlangt vom Product Owner analytisches Denken und Prozesswissen, kombiniert mit Stehvermögen und Fingerspitzengefühl. Die zukünftigen Anwender sind in ihren Fachgebieten die Experten, und Argumenten wie: „Das haben wir schon immer so gemacht“ oder „Es läuft doch, warum etwas ändern?“ muss der Product Owner überzeugend begegnen können. Ein Verweis auf die Ziele und den Projekt-Sponsor kann hier eventuell, aber sicher nur begrenzt helfen.
Wenn Sie in Ihrem Unternehmen keinen Product Owner finden oder dieser nur zeitlich begrenzt verfügbar ist, dann kaufen Sie besser einen fachlich und methodisch kompetenten Product Owner für das Projekt ein.
Die Fachexperten und das Anforderungsmanagement
Nicht- oder Kaum-Verfügbarkeit der benannten Vertreter für die Anwender-Rollen – die Fachexperten, fehlende Entscheidungskompetenz des Product Owner, Nicht- oder Alles-Priorisierung sind das K.O. für ein agiles Projekt. Product Owner und Fachexperten müssen die Anforderungen verstehen, Abhängigkeiten erkennen und dafür sorgen, dass das Product Backlog qualifiziert und zügig gefüllt wird.
In unserem Beispiel sind die wichtigsten Nutzer die Kinder (à Anwender-Rolle) und Erzieher*innen (à weitere Anwender-Rolle).
Wenn schon vor oder bei Projekt-Start absehbar ist, dass für diese Aufgabe mehr Zeit und viele Abstimmungen erforderlich sind, dann empfehlen es sich, genau diese Vorbereitung und Befüllung des Product Backlog als Vorprojekt durchzuführen. Das Product Backlog sollte zu mindestens 60 % gefüllt sein, bevor man mit der Realisierung der Anforderungen startet.
Product Backlog mit einem Mindest-Füllstand von 60 %
Sie werden sich fragen: 60 % - wovon?
Für die ungefähre Bestimmung des Backlog-Gesamtumfangs, also 100 %, ist eine Zusammenstellung der Anforderungen in Bezug auf die wichtigsten Aufgaben und Geschäftsprozesse der Anwender-Rollen im Zusammenhang mit dem „Produkt“ und der Zielstellung hilfreich. Im agilen Sprachgebrauch sind das die sogenannten “Epics”. Jedem Epic können ein oder mehrere detaillierte Anwendungsfälle (User Stories) zugeordnet werden.
Ich bin weder Einrichtungsplaner noch pädagogische Fachkraft – aber bleiben wir trotzdem beim Beispiel „Einrichtung einer Kindertagesstätte“, um die Vorgehensweise bei der Zusammenstellung von Epics und Anwendungsfällen zu verdeutlichen:
Kinder werden von ihren Eltern gebracht, spielen, essen, lernen, schlafen, waschen sich, werden abgeholt - das sind Epics. Erzieher/innen begrüßen, lehren, organisieren Spiele, verköstigen, halten Kontakt mit den Erziehungsberechtigten der Kinder - das sind weitere Epics.
Jedem Epic werden wesentliche Anwendungsfälle zugeordnet, so können z. B. zum Epic „Kinder bringen“ gehören:
- Kinderstraßenbekleidung wiederauffindbar und zuordenbar deponieren
- Ersatzsachen zuordenbar deponieren
- Händewaschen vor Zutritt zur Gruppe
- usw.
Wenn der Product Owner und die Fachvertreter der Anwender-Rollen zielgerichtet die wesentlichen Epics und zugeordnete Anwendungsfälle zusammengestellt haben, dann gilt es zu priorisieren („Must Have’s“) und diese Anwendungsfälle zu detaillieren und zu ergänzen – mit Abnahmekriterien, Testfällen, notwendigen Testdaten, Dokumentationsaufgaben u. ä. gemäß den vereinbarten Kriterien für die „Definition of Ready“.
MVP – Minimal Viable Product ODER das funktionale Minimum für die Nutzung
Mitunter wird für den Mindestumfang – also die „Must-Have“-Anwendungsfälle – auch der Begriff „Minimal Viable Product” oder die Abkürzung MVP verwendet. Der MVP-Umfang fasst jedoch nur die Funktionen, die für ein erstes Release, also die erstmalige Nutzung durch die wesentlichen Anwender-Rollen unabdingbar sind. Es ist durchaus möglich und zielführend, „Must Have’s“ in ein Nachfolge-Release zu verschieben, wenn diese für eine Inbetriebnahme nicht zwingend erforderlich sind. So können Erst-Anwender und Product Owner mit dem MVP-Funktionsumfang echte Erfahrungen sammeln und resultierende Bedarfe in die weiteren Ausbaustufen (Nachfolge-Releases) einbringen.
Für unser Beispiel wäre also zu überlegen, welche der “Must Have”-Anwendungsfälle für eine Eröffnung von wenigstens <u>einer</u> Kindergruppe in der Kindertagessstätte <u>mindestens</u> erforderlich ist.
Projekterfolg erfordert Ihre MItarbeit: Methodenwissen und Entscheidungskompetenz
Und was macht dann der Dienstleister?
Um bei dem Beispiel zu bleiben: Die Kinder und Erzieher/innen als Anforderer müssen nicht wissen, wie und womit eine Kindertagesstätte eingerichtet wird. Sie kennen jedoch ihre eigenen Abläufe, Interessen und Bedarfe. Der Dienstleister realisiert die priorisierten Anwendungsfälle, er bringt das Wissen über Methoden und Möglichkeiten sowie die Erfahrungen aus bisherigen Projekten mit.
Das heißt, Sie als Auftraggeber haben die Hoheit und den Spielraum zu entscheiden, was Ihnen wichtig ist, um Ihr Projektziel zu erreichen und möglichst schnell, aber qualifiziert Erfolg und/oder Umsatz zu generieren.
