Kann das in den Müll oder brauchen wir das Wissen noch?
Agiles Projektmanagement ist weit mehr als das Befolgen eines festen Regelwerks – es ist eine Denkweise, die sich flexibel an Unternehmen, Produkte und Teams anpassen lässt. Doch genau diese Flexibilität bringt Herausforderungen: Was passiert, wenn Agilität falsch verstanden oder unkontrolliert umgesetzt wird?
In meinem Berufsalltag als Projektmanager habe ich immer wieder erlebt, wie unterschiedliche Interpretationen des agilen Manifests Projekte beflügeln, aber auch ausbremsen können. In diesem Beitrag teile ich eine Erfahrung, die zeigt, wie leicht die Agilität falsch umgesetzt wird und welche Maßnahmen nötig sind, um wieder Kurs auf eine produktive und strukturierte Arbeitsweise zu nehmen.
Nehmen Sie sich kurzweilige 5 Minuten Zeit und lesen Sie mehr über Berge und Müll.
Das Manifest
Das agile Manifeste mit seinen 12 Prinzipien und 4 Werten gibt zwar die Basis für ein agiles Mindset vor, stellt aber keine starre Richtlinie dar.
Jedes Team und jedes Unternehmen kann agiles Projektmanagement unterschiedlich interpretieren und in jedem Unternehmen hat Agilität eine etwas andere Erscheinungsform. Angepasst auf die Firmenkultur und das Produkt bietet agiles Projektmanagement Raum für jede Menge Entfaltungsformen, die manchmal auch schwer kontraproduktiv sind.
Machen wir an dieser Stelle einen kleinen Exkurs, damit auch die Leser mitgenommen werden, denen das Agile komplett fremd ist. Ich halte mich dabei bewusst nah beim Thema Anforderungen und fange mit den User Story an.
Kleiner Exkurs zur User Story
In einem agilen IT-Projekt sind User-Stories eine kurze, einfache Beschreibung einer Funktionalität aus der Perspektive des Endbenutzers oder Stakeholders. Sie formulieren die Bedürfnisse und Anforderungen der Nutzer und geben dem Entwickler den Kontext, warum eine bestimmte Funktion erforderlich ist.
Eine User Story könnte also lauten:
„Als Kunde möchte ich meine Bestellungen in meinem Konto einsehen können, damit ich die Details meiner Einkäufe nachvollziehen kann.“
Nach zwei Sprints war der erste Prototyp fertig und die Product Owner bekamen die erste Version zum Testen. Das erste Feedback kam nach einer Woche und war schon recht positiv. Es fehlten nur hier und da ein paar Kleinigkeiten, die ja kein Problem sein sollten. Somit wurden die Aufgaben in den Backlog für den nächsten Sprint gelegt.
Was das Lehrbuch so sagt?
Laut Lehrbuch erfasst typischerweise der
Product Owner die User Stories.
Oft in enger Zusammenarbeit mit dem Entwicklungsteam. Das Team kann bei der Ausarbeitung der Details helfen, technische Aspekte einbringen und gemeinsam mit dem Product Owner Akzeptanzkriterien definieren. In manchen Fällen können auch andere Stakeholder Input geben, aber die finale Formulierung und Priorisierung liegt beim Product Owner.
Was in der Praxis daraus wird!
In der Praxis sieht die Erfassung der Stories schon um einiges wilder aus. Da kann ein bunter „Story-Blumenstrauß“ auch mal von vielen Stakeholdern kommen.
Wer sind diese Stakeholder?
Witzige Zeitgenossen schieben hier schnell den Begriff “Schnitzelhalter” ein, kann man komisch finden, muss man aber nicht. Die Analogie versteht auch kaum jemand auf Anhieb.
In einem agilen IT-Projekt gibt es verschiedene Stakeholder, die jeweils unterschiedliche Interessen und Verantwortlichkeiten haben. Hier eine einfache Auflistung:
- Product Owner
- Kunden und Endbenutzer
- Entwicklungsteam
- Scrum Master oder Agile Coach
- Management und Führungskräfte
- Business Analysten
- Externe Partner und Lieferanten
- Regulierungs- und Compliance-Behörden
Was passiert bei Scrum?
Scrum ist ein agiles Framework, das in Iterationen, den sogenannten Sprints, arbeitet. Ein Sprint dauert meist 2-4 Wochen und folgt einem festen Ablauf:
- Sprint Planning
Das Team plant, welche Aufgaben (Product Backlog Items) im Sprint bearbeitet werden. Diese Aufgaben werden im Sprint Backlog gesammelt. - Daily Scrum
Tägliches 15-minütiges Meeting, in dem das Team Fortschritte bespricht, Hindernisse identifiziert und die Arbeit für den Tag plant. - Sprint Execution
Das Team arbeitet gemeinsam an den definierten Aufgaben. Der Fokus liegt darauf, ein funktionsfähiges Inkrement am Ende des Sprints zu liefern. - Sprint Review
Am Ende des Sprints wird das Ergebnis den Stakeholdern präsentiert. Feedback fließt zurück ins Product Backlog. - Sprint Retrospective
Das Team reflektiert, was gut lief und was verbessert werden kann, um den nächsten Sprint effizienter zu gestalten.
Der Prozess ist iterativ und darauf ausgelegt, kontinuierlich Wert zu schaffen und die Arbeitsweise zu optimieren.
Der Product Owner
Der Product Owner ist hat eine zentralen Rollen in Scrum.
Seine Hauptaufgaben sind:
- Product Backlog verwalten
- Anforderungen priorisieren
- Stakeholder einbinden
- Vision vermitteln
Bepackt mit diesem Wissen folgt nun ein Ausflug in den täglichen Projektwahnsinn. Der deutlich zeigt, was alles bei falsch verstandener Agilität schief laufen kann.
Los geht es!
Die Story
Vor ein paar Jahren hatte ich Kontakt zu einer Projektmanagerin mit dem Namen Kathrin. Wir plauderten ein bisschen über Softwareentwicklung und Projektmanagement und sie erzählte mir von ihrer Firma, in der sie arbeitete.
Das Unternehmen hatte 12 Entwickler, die in 4 Teams arbeiteten. Dazu kamen 4 Product Owner, die themen- und fachbezogen für die Software zuständig waren.
So weit war das Ganze nicht auffällig, trotzdem war Kathrin genervt. Auf meine Nachfragen hin meinte sie, dass sie extrem viel Zeit für die Vorbereitung des nächsten Sprints benötigt.
Vor jedem Sprint müssen die Stories im Product-Backlog durchgesehen und, wenn noch nicht geschehen, mit dem Product Owner abgestimmt werden. Die Stories werden dann entweder zurückgestellt oder in den Sprint-Backlog verschoben.
“Was passiert in diesen Meetings genau?” fragte ich nach. “Der Product Owner sollte seine Stories doch eigentlich kennen.”
Kathrin schaut sich mit dem Product Owner gemeinsam an, was in den Stories für eine Funktion gewünscht wird, sie prüfen, wie wichtig sie für den Kunden ist und wie schnell sie fertig sein muss. Fehlen diese Informationen, fragen sie beim Erfasser der Story nach.
Das Problem hierbei besteht aber darin, dass die Anzahl der Stories im Backlog rasend schnell steigt. Wir schaffen es nicht, alle offenen Fragen zu klären. Aktuell sind es über 1200, die noch gar kein Product Owner gesehen hat.
Hier passt was nicht!
Wer erfasst die Stories in der Firma,
wenn nicht der Product Owner?
Sie erzählte mir, dass die Product Owner nur sporadisch Zeit für die Erfassung der Stories haben und so übernehmen die Leute aus dem Support, vom Vertrieb, dem Consulting und manchmal auch die Product Owner die Erfassung.
Jeder Supporter, der einen Fehler gemeldet bekommt, erfasst eine Story. Jeder Consultant, der für einen Kunden eine Funktion benötigt, erfasst eine Story.
Jeder darf eine Story erfassen, wenn es ein Fehler ist oder die Funktion gebraucht wird.
Der Backlog wird somit von allen Seiten unaufhörlich mit Stories vollgestopft.
Wie behält man da den Überblick?
“Entstehen bei diesem Vorgehen nicht furchtbar viele doppelte Stories?” fragte ich.
Ja! Es entstehen furchtbar viele doppelte Einträge, gerade bei den Fehlern.
Auch bei den neuen Funktionen ähneln sich sehr viele Stories, aber die meisten haben ein anderes Ziel oder einen anderen Ablauf.
Somit kann man die doppelten Stories nicht einfach löschen, es könnte sein, dass der Kunde genau dieses Vorgehen für seine Prozesse benötigt.
Diese Anforderung wäre dann weg. Somit müssen wir in solchen Fällen mit jedem Erfasser separat klären, was genau benötigt wird und ob es nicht mit den anderen Stories auch gehen würde.
Das ist mühselig und sehr ermüdend. Es nimmt einfach kein Ende, da die Software auch so groß ist.
Wir sind mittlerweile ganze zwei Tage vor jedem Sprint damit beschäftigt, die Stories zu sichten und wir kommen zu nichts Anderem mehr.
Sehr viele Rückfragen komme auch von den Entwicklern.
Uns fehlt die Zeit, jede Story und die dazugehörigen Anforderungen zu erfassen und aufzuarbeiten.
Eine Herausforderung?
Wir überlegten gemeinsam, was die größten Herausforderungen sind:
Der Wildwuchs an Stories musste aufhören.
Die Menge der Stories musste massiv verringert werden.
Die Qualität der Stories musste verbessert werden
Eine mögliche Lösung?
Eine geeignete Lösung zu finden, war in diesem Fall nicht einfach. Jeder Lösungsansatz zog einen nicht unerheblichen Zeitaufwand nach sich.
Wir erstellten eine Liste mit den einzelnen Schritten:
- Alle Stories kategorisieren und nach Dringlichkeit sortieren
- Abklärung der Stories, die nicht ganz klar oder unvollständige sind und die Dringlichkeit neu bewerten
- Moscow – Methode auf die Stories anwenden, aber die Stories nicht löschen sondern nur in einen separaten Backlog verschieben, damit evtl. wichtige Informationen nicht verloren gehen
Für diese Arbeit haben wir einen kompletten Sprint geplant, da die Abklärung der Stories erfahrungsgemäß sehr viel Zeit in Anspruch nimmt.
Unser Vorgehen stand fest und eine letzte Hürde lag noch vor uns.
Die Firmenführung musste überzeugt werden, dass unser Vorgehen viel Zeit und somit Geld sparen wird und dass die Erstellung der Stories mehr Kontrolle benötigt und nur von einigen wenigen vorgenommen werden sollte.
Die Diskussionen waren hitzig und wir bekamen erst einmal nur grünes Licht für das Aufräumen der Stories. “Alles weitere werden wir dann sehen” hieß es.
Die Durchführung!
Mit der Freigabe begannen wir mit unserer Arbeit und es wurde umfangreicher als geplant.
Weniger Stories als gedacht waren doppelt und somit mussten viele Anforderungen geprüft und erhoben werden.
Viele Stories mit Fehlern konnten gelöscht werden, da sie nicht mehr nachvollzogen werden konnten.
In diesen zwei Wochen haben wir mehr Überstunden gemacht als uns lieb war, aber wir hatten eben nur diese zwei Wochen.
Ein Erfolg!
Am Ende waren knapp ⅔ der Stories noch übrig, wobei knapp 1/3 im “Sonder-Backlog” lagen.
Bei der nächsten Sprint-Vorbereitung ging alles schon viel schneller.
Die Stories waren klar sortiert, die wichtigsten waren oben und so wurden sie auch in den Sprint gezogen.
Die Entwicklung konnte sich schnell einlesen, Klärungsbedarf gab es nur wenig und die Schätzrunden waren auch schnell erledigt.
Alles fühlte sich gut an…
…bis wir die neuen Stories gesehen haben, die in der Zwischenzeit entstanden sind. Hier war die Qualität wieder unterirdisch: doppelt, unverständlich, nicht nachvollziehbar.
Wir konfrontierten die Geschäftsführung und drängten auf eine Lösung.
Es wurde dringend ein Product Owner benötigt, der auch Zeit für seinen Job bekam.
Rechnerisch lohnte sich eine Vollzeitstelle und auch für die Motivation des Teams konnte es nur von Vorteil sein, einen kompetenten Ansprechpartner zu haben.
Die Geschäftsführung nahm sich etwas Zeit und entschied, dass Kathrin die Stelle als Vollzeit Product Owner bekam.
So wurden die bisherigen Product Owner zeitlich entlastet und die Entwickler bekamen eine kompetente Ansprechpartnerin, die ihren Job bis heute liebt.
Fazit
Agilität lebt von Anpassungsfähigkeit. Ohne klare Strukturen und Verantwortlichkeiten kann sie aber schnell zum Chaos führen.
Die Geschichte von Kathrin und ihrem Unternehmen zeigt, wie wichtig es ist, den Backlog nicht nur zu pflegen, sondern ihn mit Sorgfalt und Fokus zu managen.
Ein klarer, verständlicher Prozess für das Erfassen und Priorisieren von Stories, sowie ein Product Owner mit ausreichend Zeit und Verantwortung sind extrem wichtig für die Qualität und die Effizienz in agilen Projekten.
Agiles Projektmanagement bedeutet nicht, alles dem Zufall zu überlassen, sondern gezielt Raum für Flexibilität und Innovation zu schaffen – ohne die Grundpfeiler aus den Augen zu verlieren.
So wird Agilität zu einem echten Erfolgsfaktor.
Und jetzt?
Torsten Kleinstück „Handle jetzt!“
Als Coach und Projektmanager helfe ich gestressten Product Owner und Projektmanagern, die schnell die Kontrolle über Ihre Projekte bekommen und
Zeit bei der Planung, Durchführung und Dokumentation ihrer Projekte sparen möchten.
Dieser Artikel
Dieser Artikel handelt von einer Projektmanagerin, die eine unerträgliche Arbeitslast auferlegt bekam und mit einem mutigen Schritt nicht nur eine Job bekam, den sie liebt, sondern auch wieder mehr Freizeit und weniger Druck.
Wie geht es weiter?
Wenn Sie mehr zum Thema Projekt- und Anforderungsmanagement in IT-Projekten lesen möchten, dann freuen Sie sich auf den nächsten Beitrag mit dem Titel:
“Raus aus der Schule, rein ins Chaos”
Projektmanager und Anforderungsmanager
Seine Botschaft: Jeder kann erfolgreich Projekte planen, managen und dokumentieren.
- Er hilft Projektmanagern, Zeitdruck und Stress zu reduzieren, damit sie den Kopf frei haben für das Projektziel
- Zeigt Wege für eine einfach Planung
- Seine Projekterfolgs-Formel hilft Zeit und Geld zu sparen!