Agiles Projektmanagement: Methoden und Prozesse

    Agile Projekte und allgemein agiles Arbeiten setzen Flexibilität und Anpassungsfähigkeit während des Projekts an oberste Stelle. Im Gegensatz zu einem Wasserfall basierten Vorgehen, wo Planbarkeit und fest Rahmenbedingungen den Projektverlauf bestimmen, sind Agile Projekte in der Lage, sich auf Veränderung schnell und unbürokratisch anzupassen – sowohl bzgl des Produkts das entwickelt wird auch bzgl des Teams, dessen Methodik und Zusammensetzung. Somit steht an oberster Stelle: Es wird das Umgesetzt, was wirklich benötigt wird, nicht zwingend das was in der Vergangenheit geplant wurde.


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

    Agiles Arbeiten braucht eine angepasste Form von Projektmanagement und somit auch eine Anpassung von Tools, Methoden und vor allem der Einstellung des Teams und der Stakeholde bzgl des Themas “Flexibilität”. 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 bzgl. des Budgets in einem Modell vereint. Da sich durch den Einsatz Agiler Methoden jedoch das gesamte Team einem Lernprozess über das eigene Projekt unterziehen, sind zu Beginn nicht alle Anforderungen bekannt und meist ist nicht vorher abschätzbar, was das lernen denn an Aufwand bedeutet. 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 Bestand hat. 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 die Anforderungen durch priorisierung umgesetzt werden, die den größten Business Value liefern. Ein Agiler Festpreis sieht vor, dass

    bereits zu Beginn die zum aktuellen Zeitpunkt bekannten Anforderungen bestmöglich definiert werden. Es ist zweifelsfrei, dass auch für Agile Projekte planung wichtig ist. Während des Projekts werden neue Anforderungen erkannt werden. Diese gilt es dann zu priorisieren und ggf durch andere Anforderungen mit niedrigerer Priorität und etwa gleichem Aufwand auszutauschen. So kann das Budget fest bleiben und die Flexibilität ist dennoch gegeben. Dieses Vorgehen ist als Agiler Festpreis bekannt.


    Agiles Projektmanagement und Sicherheit in der Planung

    Wie schafft man es nun, das Projekt in einen Rahmen zu lenken, der für alle Projektbeteiligten akzeptabel und zufriedenstellend ist? Ganz einfach: Es werden jeweils einzelne „Meilensteine“ (oder Sprints im Jargon Agiler Projekte) definiert, die der Reihe nach die wichtigsten Anforderungen an die Software in einem Agilen Projekt implementieren. Nach jedem Meilenstein entsteht ein Stück einsetzbare 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. Nach jedem Sprint wird die erstellte Software ausgeliefert und kann für Tests mit den Anwendern verwendet werden. Auch hier dient das Feedback durch die 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 um nächsten Sprint umgesetzt werden. Agile Methoden setzen auf ein systematisches Vorgehen auf der Basis kontinuierlicher Verbesserung. Dadurch, dass das Projekt und das Team durch Agile Methoden anpassungsfähig und flexibel bleibt entsteht durch Agile Projekte Sicherheit in der Qualität des Produkts denn: Es wird immer das Umgesetzt was wirklich wichtig ist und das verbessert was nicht gut funktioniert hat – und zwar in kurzen Zyklen (Spints + 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 ein Stück einsatzbereite Softweare entstanden.

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


    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”. 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 durch das Einhalten Agiler Methoden (z.B. Scrum) 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 3 wesentliche Aufgaben:

    • Sie steuern die Erwartungshaltung der Stakeholder.
    • Sie machen Fortschritt messbar.
    • Sie vermitteln dem Entwicklerteam 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 möchte ich die wesentlichen Formate für Anforderungen kurz mit ihren Vor- und Nachteilen darstellen.


    Checklisten für Agile Anforderungen

    Damit Sie in komplexen Projekten nichts vergessen, stellen wir Ihnen unsere Checklistensammlung kostenlos zu Verfügung.

    Checklisten für Agile Anforderungen

    Vergessen Sie bei komplexen Projekten keine Details, wir stellen Ihnen unsere Checklisten kostenlos zur Verfügung.

    Lastenheft und Pflichtenheft im Detail

    Das Lastenheft schreibt in der Regel der Kund, es bildet das ab, was er sich „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.

    agiles projektmanagement

    Werden jedoch digitale Projekte durch die Digitalisierung nicht nur durch Informatiker, sondern durch Fachabteilungen ins Leben gerufen und umgesetzt, so ist das Pflichtenheft sicher wenig geeignet. Warum? Es besteht aus Text und Text enthält meist viele Lücken zur Interpretation – oder es besteht aus hunderten von Seiten und erlaubt es nicht, das Projektergebnis in seiner Gesamtheit zu erfassen und zu validieren. Und sollte dies durch ein bestimmtes Format möglich sein, ist das Pflichtenheft meist schon nach fertigstellung wieder veraltet. Unsere Welt ändert sich einfach zu schnell um solchen statischen Konstrukten eineDaseinsberechtigung zu verschaffen. Starre 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 am besten zur Abstimmung und zum Evaluieren von verschiedenen Meinungen und Vorstellungen und sie lassen frühes Feedback der späteren Nutzer zu. Bei Text hingegen ist das weniger der Fall. Agile Methoden leben von Feedback und Verbesserung und Sie haben es sicher selbst mehrfach erlebt: Visuell ist einfacher zu Erfassen als lange Seiten Text.

    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 Abstimmung and 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 man hat „etwas zum Anfassen“ als Ergebnis das alle Beteiligten verstehen können.


    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. Akzeptanzkriterien, die “Definition of Read” (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” (wann ist etwas in der Implementierung wirklich abgeschlossen inkl 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 kann man mit Annotationen in den Designs oder Mockups arbeiten, wenn der Umfang überschaubar ist. So können durch Agile Projekte bereits in der Planung visuelle und funktionale Anforderungen kombiniert werden. Dies führt zu einem schnellen Verständnis darüber, was in der Entwicklung umgesetzt werden soll.


    Wir empfehlen jedoch 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 „Digital Customer Journey“ konzipiert und durchdacht, es werden jedoch nur wenige Gedanken in die „Author Journey“investiert. Als Ergebnis hat man eine Webseite oder Webanwendung, die kein Redakteur pflegen kann oder will. Dies kann vermieden werden, wenn man das CMS seiner Wahl gut kennt und ein paar Gedanken in die Backend-Ansicht und dessen Workflows investiert. Ihre Redakteure werden es Ihnen mit Sicherheit danken. Auch sie sind Nutzer Ihrer Software mit hoher Wichtigkeit 😉


    Epics und Use Cases in Agilen Projekten

    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. Beide beschreiben Anwendungsfälle wie den Registriervorgang, das Auswählen von Produkten oder den Checkout-Prozess in einem Onlinestore aus der Sicht, aus der sie der Nutzer der Anwendung 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.


    User Stories – ins Detail

    User Stories sind einzelne und sehr feingranulare, testbare Nutzerinteraktionen einer Software mit Akzeptanzkriterien. Sie entsprechen der Form:

    „Als anonymer 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.“

    Man sieht, 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 dem

    Einsatz 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 von klassischem Projektmanagement so reduziert werden, dass sie 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 seinem Ziel einen Schritt näher zu kommen. 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 der beteiligten. In einer Kultur, wo Fehler bestraft werden, können sich Agile Methoden nicht entfalten.


    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, von Wasserfall bis agil, von Werkvertrag bis Dienstvertrag und gerne auch in Kombination. Nehmen Sie jetzt Kontakt mit uns auf.


    Verwandte Blogbeiträge

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

    Bereit für Projekte ohne Grenzen?

    Wir freuen uns auf Ihre Projekt-Ideen! Lernen Sie uns gerne in einer kostenlosen Erstberatung kennen und nehmen Sie noch heute Kontakt zu uns auf.PROJEKT ANFRAGE STELLEN

    Wie sieht Ihre perfekte Digitalagentur aus?

    Wir haben aus über 500 Anfragen die häufigsten Kriterien zur Agenturauswahl zusammengetragen. So können Sie Ihre Anbieter einfach vergleichen.CHECKLISTEN HERUNTERLADEN
    Darmstadt

    Bright Solutions GmbH
    Pfnorstraße 10-14
    64293 Darmstadt

    Adresse anzeigen
    Hamburg

    Bright Solutions Hamburg GmbH
    Altonaer Poststraße 9a
    22767 Hamburg

    Adresse anzeigen
    Telefon

    Darmstadt: +49 6151 / 27 647 - 0

    Hamburg: +49 040 / 350 80 130

    Nummern anzeigen