Agiles Projektmanagement – sicher planen mit agilen Methoden & Prozessen

    Agiles Projektmanagement

    Agiles Projektmanagement und agiles Arbeiten setzen Flexibilität, Anpassungsfähigkeit und strategische Konsistenz während des Projekts voraus.

    Im Gegensatz zu einem Wasserfall-basierten Vorgehen, bei dem Planbarkeit und fest Rahmenbedingungen den Projektverlauf maßgeblich bestimmen, sind agile Projekte in der Lage, sich an Veränderungen schnell und unbürokratisch anzupassen – sowohl bezüglich des Produktes, das entwickelt wird, als auch bezüglich des Teams, dessen Methodiken und Setup.

    Somit steht an oberster Stelle:

    Es wird das umgesetzt, was wirklich benötigt wird, nicht zwingend das, was in der Vergangenheit geplant wurde.

    Wie planen Sie also solche flexiblen, agilen Projekte erfolgreich?

    Agile Projekte zum Festpreis a.k.a. Agiler Festpreis?

    Es wäre doch sicher die schönste Lösung, wenn agile Projekte zu einem Festpreis abgewickelt werden könnten. So hätte man maximale Flexibilität UND Planungssicherheit des Budgets in einem Modell vereint. Denn das eine schließt das andere doch aus, oder?

    Fakt ist, dass sich, durch den Einsatz agiler Methoden, das gesamte Team einem Lernprozess über das eigene Projekt unterzieht, und somit zu Beginn nicht alle Anforderungen bekannt sind.

    Meist ist nicht vorher abschätzbar, welchen Aufwand dieses denn mit sich zieht.

    Sie merken: Agiles Arbeiten braucht eine angepasste Form von Projektplanung und Projektmanagement, um diese Tatsache abzufangen. Ferner ist auch eine Anpassung von Tools, Methoden und vor allem der Einstellung des Teams und der Stakeholder in Bezug auf das Thema “Flexibilität” nötig.

    Doch viel zu oft tappen Unternehmen und Projektteams in die Falle, agiles Projektmanagement zu flexibel zu gestalten.

    Grundsatz: „Agil“ bedeutet nicht „planlos“.

    Agiles Projektmanagement und so auch ein „agiler Festpreis“ haben nicht das Ziel, etwas einfach nach Vorgabe umzusetzen und darauf zu hoffen, dass der ursprüngliche Plan auch nach der Fertigstellung noch Ihre Buyer Persona begeistert. Vielmehr steht auch bei einem agilen Festpreis die kontinuierliche Verbesserung, sowohl des Produkts als auch der Team-Performance, im Vordergrund.

    So können auch die Kosten und der benötigte Zeitrahmen nicht von Anfang an zu 100% feststehen. Meist setzt man ein Budget und versucht, agile Projekte so zu steuern, dass immer jene Anforderungen durch Priorisierung umgesetzt werden, die den größten Mehrwert für Ihre Zielgruppe und Ihre Marketing- und Vertriebsziele liefern.

    Ein agiler Festpreis sieht vielmehr vor, dass bereits zu Beginn des Projekts die (zum aktuellen Zeitpunkt bekannten) Anforderungen bestmöglich definiert werden.

    Während des Projekts werden Sie immer wieder neue Anforderungen durch User Tests oder Anpassungen Ihrer Strategie erkennen.

    Diese gilt es dann zu priorisieren und bisweilen durch andere Anforderungen mit niedrigerer Priorität und etwa gleichem Aufwand auszutauschen. So kann das Budget fest bleiben – die Flexibilität ist dennoch gegeben.

    Dieses Vorgehen ist als agiler Festpreis bekannt.

    Zurück nach oben

    Agiles Projektmanagement – Sicherheit in der Planung?

    Wie schaffen Sie es nun, das Projekt in einen Rahmen zu lenken, der für alle Projektbeteiligten akzeptabel und zufriedenstellend ist?

    Unsere Antwort: Es werden jeweils einzelne „Meilensteine“ (oder „Sprints“ im Scrum-Jargon) definiert, die der Reihe nach die wichtigsten Anforderungen an die Software in einem agilen Projekt implementieren.

    Nach jedem Milestone entsteht ein Stück einsetzbare, testbare und somit für Ihr Team und/ oder Ihre Kunden erlebbare Software.

    Jeder Meilenstein wird mit Use Cases, Epics und User Stories geplant und vom gesamten Entwicklerteam im Aufwand (meist Planungspoker in Scrum) geschätzt.

    Dieser Vorgang der Aufwandschätzung sollte transparent sein und in Anwesenheit der Projektteilnehmer stattfinden.

    Dieses Vorgehen schafft Vertrauen und gibt dem Product Owner oder Kunden, als auch anderen Stakeholdern auch für agile Projekte Sicherheit in der Planung.

    Zurück nach oben

    Nach jedem Sprint wird die erstellte Software ausgeliefert und kann für Tests mit Ihrer Nutzergruppe, der Buyer Persona, verwendet werden. Auch hier dient das Feedback durch diese Anwender der frühen und kontinuierlichen Verbesserung.

    Sind die Stakeholder nicht mit den Sprint-Ergebnissen zufrieden, werden in der Retrospektive Maßnahmen zur Verbesserung gemeinsam erarbeitet, die umgehen im nächsten Sprint umgesetzt werden. Agile Methoden setzen auf ein systematisches Vorgehen auf der Basis kontinuierlicher Verbesserung.

    Suchen Sie das passende agile Team?

     

    Dadurch, dass das Projekt und das Team durch agile Methoden anpassungsfähig und flexibel bleiben, entsteht Sicherheit in der Qualität des Produkts.

    Es wird immer das umgesetzt, was wirklich wichtig ist und das verbessert, was nicht gut funktioniert hat – und zwar in kurzen Zyklen (Sprints + Retrospektive). Dies ist die Basis für erfolgreiche agile Projekte.

    Je kürzer die einzelnen Sprints, desto geringer das Risiko, sich in eine falsche Richtung zu bewegen.

    Es ist natürlich möglich, ein agil entwickeltes Softwareprojekt zu einem festen Preis abzuwickeln – dies ermöglicht der agile Festpreis.

    Allerdings ist es nicht möglich, neben dem festen Preis auch einen festen Zeitrahmen und eine feste Anforderungsliste zu vereinbaren.

    Es wird mit einem festen Preis so lange gearbeitet, bis das Budget aufgebraucht ist und durch das Vorgehensmodell und die Priorisierung sichergestellt, dass sich das Budget im Wert der entstandenen Software wiederfindet. Danach ist immer ein Stück einsatzbereite Software entstanden.

    Diese Software hat auf jeden Fall die, als am wichtigsten priorisierten Anforderungen implementiert.

    Zurück nach oben

    Ein Pflichtenheft für agile Projekte?

    „Zeig mir deine Projektanforderungen und ich sage dir, ob dein Projekt erfolgreich sein wird.“

    Oder: “Die Qualität der Anforderungen bestimmt die Qualität der Ergebnisse”.

    Oder noch bekannter: „Wie es in den Wald hineinruft, so schallt es heraus.“ 😉

    Dies ist gerade für agiles Projektmanagement wichtig.

    Denn „agil“ heißt keinesfalls planlos.

    Um der hohen Flexibilität gerecht zu werden, brauchen Projekte Struktur, z.B. durch das Einhalten agiler Methoden im gesamten Team.

    Tatsächlich bilden die Anforderungen – sowohl in klassischen Wasserfallprojekten als auch in agilen Projekten – die Grundlage für planbaren Projekterfolg. Anforderungen haben auch im agilen Projektmanagement oder allgemein für agiles Arbeiten drei wesentliche Aufgaben:

    1. Sie steuern die Erwartungshaltung der Stakeholder.
    2. Sie machen Fortschritt messbar.
    3. Sie vermitteln dem umsetzenden Team das, was umgesetzt werden muss, damit das Projekt erfolgreich wird.

    Sie geben also Sicherheit über das Ergebnis und die aufzuwendenden Ressourcen, um das gewünschte Ergebnis herzustellen.

    Im Folgenden stellen wir Ihnen die wesentlichen Formate für Anforderungen kurz mit ihren Vor- und Nachteilen vor.

    Lastenheft und Pflichtenheft – im Detail

    Eine kurze Definition:

    Das Lastenheft schreibt in der Regel der Kunde. Es bildet das ab, was sich dieser „wünscht“.

    Das Pflichtenheft erstellt der Entwicklungspartner oder das Team, das für die Architektur und die Umsetzung verantwortlich ist. Es beschreibt das, was aus den „Wünschen“ entstehen soll: Die finale Software.

    Agile Methoden priorisieren ein Vorgehensmodell, das auf Flexibilität und Anpassungsfähigkeit setzt.

    Da ein Pflichtenheft diese Flexibilität nicht zulässt, gibt es in agilen Projekten meist keines.

    Das klassische Pflichtenheft hat die Aufgabe, in Wasserfallprojekten die Anforderungen an die Software aus der sehr technischen Sicht der Softwarearchitektur zu definieren.

    Es bietet Technikern Sicherheit darüber, wie die Software beschaffen sein muss und ist hauptsächlich in der IT-Welt, vorrangig unter Informatikern, verständlich.

    Zurück nach oben

    Für digitale Projekte sind das klassische Lastenheft und Pflichtenheft wenig geeignet.

    Warum? Sie bestehen aus Text – und Text enthält meist viele Lücken zur Interpretation – oder sie bestehen aus hunderten von Seiten und erlauben es nicht, das Projektergebnis in seiner Gesamtheit zu erfassen und zu validieren.

    Zudem sind solche Anforderungskataloge meist schon nach Fertigstellung wieder veraltet. Unsere Welt ändert sich einfach zu schnell, um solchen statischen Konstrukten eine Daseinsberechtigung zu verschaffen.

    Starre Lasten- und Pflichtenhefte schränken agiles Arbeiten erheblich ein und die nötige Flexibilität kann sich nicht entfalten.

    Nochmal zur Betonung: Agiles Projektmanagement heißt nicht “planlos arbeiten”. Agile Methoden und agiles Arbeiten haben kurze Planung (je Sprint) und schnelle Verbesserungen (zusammengetragen in der Retrospektive) als oberste Priorität.

    Wireframes für agiles Projektmanagement

    Visuelle Elemente eignen sich am besten zur Abstimmung und zum Evaluieren von verschiedenen Meinungen und Vorstellungen. Sie lassen frühes Feedback der späteren Buyer Persona zu. Bei reinem Text hingegen ist das weniger der Fall.

    Agile Methoden leben von Feedback und Verbesserung.

    Sie haben es sicher selbst mehrfach erlebt: Visuell aufbereitete Informationen sind einfacher zu erfassen als lange Seiten Text (selbst dieser Artikel fühlt sich schon wirklich langatmig an, nicht wahr?!).

    Bei besonders UX-lastigen Projektergebnissen sowie in frühen Projektphasen, wenn es um die Abstimmung der User Interfaces geht, eignen sich Wireframes und klickbare Prototypen sehr gut, um schnelle Abstimmungen und Anpassungen ohne hohe Kosten zuzulassen.

    Sie sind schnell verständlich und eignen sich für schnelle Iterationen in agilen Projekten mit vielen Feedbackschleifen. Die Ideenfindung und die Ideenverfeinerung wird somit beschleunigt und Sie haben direkt „etwas zum Anfassen“ als Ergebnis, das alle Beteiligten testen und verstehen können.

    Zurück nach oben

    User Stories und Akzeptanzkriterien für agile Projekte

    Dennoch fehlt die Definition der User-System-Interaktion. Bei komplexen Systemen mit Integrationen, Workflows, Moderationsabläufen, Microservice-Architekturen über verschiedene Systeme hinweg und viel Logik müssen Designs und Mockups unbedingt um funktionale Beschreibungen (z.B. auch Validierungen etc.) ergänzt werden.

    Hier reicht hübsches Aussehen allein natürlich nicht, so wie in fast jedem Website Relaunch oder App-Projekt ebenfalls die visuellen Ziele unbedingt strategische Prioritäten verfolgen sollten.

    Akzeptanzkriterien, die “Definition of Ready” (sprich: Wann sind Anforderungen so weit definiert, dass sie in die Umsetzung gehen können und dort für Klarheit sorgen?) und die “Definition of Done” (sprich: Wann ist etwas in der Implementierung wirklich abgeschlossen, inklusive Dokumentation, Tests und Auslieferung?) sind wichtige Bestandteile im Baukasten agiler Methoden.

    Geschieht dies nicht, sieht die Anwendung am Ende zwar schick aus, funktioniert jedoch nicht, wie sie soll. Hier können Sie mit ersten Wireframes und Mockups arbeiten, wenn der Umfang überschaubar ist.

    Die Kombination visueller und funktionaler Anforderungen führt zu einem schnellen Verständnis darüber, was in der Entwicklung umgesetzt werden soll.

    Wir empfehlen immer die Kombination von Mockups oder Designs mit User Stories oder zumindest Epics und Use Cases (siehe weiter unten).

    Randnotiz: Häufig werden in Web-Projekten die Redakteure vernachlässigt. So wird zwar häufig die „Customer Journey“ konzipiert und durchdacht, es werden jedoch nur wenige Gedanken in die „Author Journey“ investiert. Als Ergebnis haben Sie eine Webseite oder Webanwendung, die kein:e Redakteur:in pflegen kann – oder will.

    Dies kann vermieden werden, wenn Sie das CMS Ihrer Wahl gut kennen und ein paar Gedanken in die Backend-Ansicht und dessen Workflows investieren.

    Ihre Redakteure werden es Ihnen mit Sicherheit danken. Denn auch sie sind Nutzer:innen Ihrer Software und von hoher Wichtigkeit!

    Zurück nach oben

    Epics und Use Cases im agilen Projektmanagement

    Die Definition von Epics und Use Cases bilden die Anforderungen und machen agiles Projektmanagement planbar – es ist damit definiert, was am Ende eines Sprints geliefert wird.

    Agile Methoden erheben Anforderungen meist aus der Sicht der Anwender:innen. Beide beschreiben Anwendungsfälle. So beispielsweise den Registriervorgang, das Auswählen von Produkten oder den Checkout-Prozess in einem Onlinestore aus der Sicht, aus der sie die Buyer Persona später erleben soll.

    Use Cases sind “gröber” als Epics und geben eine “high level” Rahmen für das Projekt.

    Textliche Beschreibungen können dabei durch Wireframes oder Designs visuell ergänzt werden.

    Dies trägt zu einem deutlich besseren Verständnis für die Anforderungen bei und erleichtert die Abstimmung zwischen Stakeholdern und dem Umsetzungsteam.

    Für das spätere Entwicklerteam bildet ein Konzept aus Epics und Use Cases mit Mockups oder Designs eine gute Basis für einen nahtlosen Entwicklungsworkflow.

    Website Relaunch, neue Kanäle oder doch einfach mehr Content?

    User Stories – im Detail

    User Stories sind einzelne und sehr feingranulare, testbare Nutzerinteraktionen einer Software mit Akzeptanzkriterien.

    Sie entsprechen dieser Form:

    „Als Nutzer möchte ich …
    meinen Benutzernamen und mein Passwort eintragen und auf ‚Anmelden‘ klicken, …
    sodass ich anschließend die Software als eingeloggter Benutzer verwenden kann…
    Bitte beachte, dass diese Funktion responsive funktionieren muss und als Authentifizierung oAuth verwenden können soll.“

    Sie sehen, dass dabei die Definition sehr feingranular ist. Die Definition von User Stories ist gerade in agilen Projekten das Mittel zum Zweck, um Anforderungen festzuhalten – immer mit dem Ziel, eine Mehrwert für den Nutzer zu schaffen.

    User Stories werden häufig in Epics und Use Cases gruppiert.

    User Stories können auch die perfekte Basis sein, um automatisierte Tests, z.B. mit Behat, zu erstellen. So wird das Testen mit sich schnell ändernden Anforderungen und schnell fortschreitenden Ergebnissen auch einfacher zu bewältigen sein und schnellere Release-Zyklen unterstützen.

    Automatisierte Tests unterstützen agile Projekte erheblich durch höhere Stabilität in bereits umgesetzten User Stories.

    Gerade agile Projekte mit schnellen Release-Zyklen und komplexer Systemarchitektur, über Microservices verteilt, stellen an das Konzept- und UX-Team hohe Anforderungen.

    Sind Anforderungen schwammig definiert oder lückenhaft, oder ist das Gesamtsystem nicht im Detail durchdacht, wird das Ergebnis trotz des Einsatzes agiler Methoden nicht den Vorstellungen entsprechen.

    Dies verhindert schnelle Releases und oft den Gesamterfolg des Projekts.

    Agiles Arbeiten als Kultur

    Für erfolgreiches Agiles Arbeiten muss zunächst das Thema Flexibilität und Anpassungsfähigkeit in den Köpfen der Manager und Teams zugelassen, erfahren und gelernt werden.

    Agile Methoden funktionieren nur dann, wenn die starren Elemente des Projektmanagements so reduziert werden, dass sie den ständigen Fortschritt nicht blockieren.

    Agile Methoden verfolgen keinen Selbstzweck. Sie haben eine klaren Rythmus, um immer genau das zu tun, was gerade erforderlich ist, um einem Ziel einen Schritt näherzukommen.

    Nur in einer Kultur, die von offenem Feedback geprägt ist, können Verbesserungspotentiale entdeckt und ergriffen werden. Das bedeutet auch, dass für agiles Arbeiten unbedingt Fehler zugelassen werden müssen.

    Fehler, die erkannt werden (Feedback), fördern das Lernen aller Beteiligten. In einer Kultur, in der Fehler bestraft werden, können sich agile Methoden nicht entfalten.

    Zurück nach oben

    Planungssicherheit durch Erfahrungsaustausch

    Wenn Sie erfahren möchten, wie Sie am sinnvollsten vorgehen, um Budgetsicherheit, Terminsicherheit und Leistungssicherheit in Ihr Projekt zu bekommen, sprechen Sie uns gerne an. Wir unterstützen Sie von der Konzeption über die Planung bis hin zur Umsetzung Ihres Projekts.

    Nehmen Sie jetzt Kontakt mit uns auf.

    FAQ

    Verwandte Blogbeiträge

    Diese Themen beschäftigten uns und unsere Kunden kürzlich