Das Agile Manifest erklärt und wie man es anwendet
Das Agile Manifest ist ein Dokument, das Arbeitsweisen festlegt, die Anpassungsfähigkeit, Reaktionsfähigkeit und Flexibilität in der Softwareentwicklung fördern.
Zumindest war das seine ursprüngliche Absicht. Heute haben sich agile Arbeitsweisen weit über die Technikwelt hinaus verbreitet und finden in unzähligen anderen Branchen Anwendung.
Aber ... was bedeutet das eigentlich? Und wie wirkt sich ein Manifest auf die tägliche Arbeit aus? Schauen wir es uns genauer an.
Kostenlos freischalten
Erstellen Sie ein kostenloses Konto, um diesen Beitrag zu Ende zu lesen und Teil einer Community zukunftsorientierter Führungskräfte zu werden, die Tools, Leitfäden und Insights für den Erfolg im Zeitalter der KI freischaltet.
Have an account? Log In
Was ist das Agile Manifest?
Das Agile Manifest ist eine schriftliche Erklärung, die vier Werte und zwölf Prinzipien enthält, welche die Arbeitsweise in der Softwareentwicklung verbessern sollen.
Das Manifest ist eher philosophisch als vorschreibend und sollte für eine Vielzahl von Teamgrößen, Zielen und Bedingungen anwendbar sein.
Die 4 Werte des Agilen Manifests
Das offizielle Agile Manifest besteht aus diesen vier Werten:
- Individuen und Interaktionen vor Prozessen und Werkzeugen
- Funktionierende Software vor umfassender Dokumentation
- Kundenzusammenarbeit vor Vertragsverhandlung
- Reagieren auf Veränderung vor dem Befolgen eines Plans
Interessant ist, dass die Autoren die Werte mit folgender Klarstellung ergänzten: "Das heißt, obwohl wir den Dingen auf der rechten Seite Wert beimessen, schätzen wir die Dinge auf der linken Seite mehr."
Dies verdeutlicht, dass es beim Agilen Manifest nicht darum geht, einem bestimmten Prozess zu folgen oder ein spezifisches agiles Tool zu verwenden. Es geht vielmehr darum, eine bestimmte Denkweise zu verinnerlichen.
Die 12 Prinzipien des Agilen Manifests
Zusätzlich zu den vier Werten enthält das Agile Manifest zwölf unterstützende Prinzipien, die erklären, wie die Werte in agilen Projekten interpretiert und umgesetzt werden können.
1. Den Kunden an erste Stelle setzen
Die höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufriedenzustellen.
2. Veränderungen willkommen heißen
Verändernde Anforderungen sind willkommen, selbst in späten Entwicklungsphasen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
3. Häufig liefern
Liefern Sie funktionsfähige Software häufig aus, im Abstand von wenigen Wochen bis wenigen Monaten, wobei kürzere Zeiträume zu bevorzugen sind.
4. Teamübergreifend zusammenarbeiten
Fachabteilungen und Entwickler müssen täglich während des gesamten Projekts zusammenarbeiten.
5. Talente fördern
Projekte werden um motivierte Individuen aufgebaut. Geben Sie ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertrauen Sie ihnen, die Arbeit zu erledigen.
6. Miteinander reden
Die effizienteste und effektivste Methode zur Informationsübermittlung an und innerhalb eines Entwicklungsteams ist das persönliche Gespräch.
7. Das Wesentliche messen
Funktionierende Software ist das wichtigste Maß für Fortschritt.
8. Arbeit tempoorientiert steuern, um Überlastung zu vermeiden
Agile Prozesse fördern nachhaltige Entwicklung. Sponsoren, Entwickler und Anwender sollten in der Lage sein, über unbegrenzte Zeit ein konstantes Tempo beizubehalten.
9. Auf Qualität achten, damit die Arbeit schneller vorangeht
Ständige Aufmerksamkeit für technisches Können und gutes Design erhöht die Agilität.
10. Einfachheit fördern
Einfachheit – die Kunst, die Menge nicht erledigter Arbeit zu maximieren – ist wesentlich.
11. Kein Mikromanagement
Die besten Architekturen, Anforderungen und Designs entstehen aus selbstorganisierten Teams.
12. Reflektieren und Anpassen
In regelmäßigen Abständen reflektiert das Team darüber, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.
Geschichte, Autoren und Entstehungsgeschichte des Agile Manifests
In der Tech-Welt wird das Agile Manifest mit derselben Ehrfurcht und Respektlosigkeit diskutiert wie jede andere überlieferte "heilige" Schrift.
Im Februar 2001 kamen 17 Software-Profis, die sich selbst „The Agile Alliance” nannten, im US-Bundesstaat Utah zusammen, um ein „Manifest für agile Softwareentwicklung“ zu verfassen. Das Dokument, das vier Werte und zwölf Prinzipien betont, ist heute als Agiles Manifest bekannt.
Die Autoren des Agilen Manifests werden oft als Agile Alliance bezeichnet und umfassten Vertreter verschiedener Entwicklungsprozesse, darunter Extreme Programming, Scrum und Crystal.
Ein kurzer Blick auf die offizielle Webseite des Manifests zeigt die Autoren in einer Situation, die an eine geheime Gesellschaft oder ein Gründerväter-Treffen erinnert. Ihr Ziel war es ganz klar, etwas mit bleibendem Einfluss auf die Branche zu schaffen. Und das ist ihnen mit Sicherheit gelungen.
Auch wenn die Personen, die sich in Utah trafen, nicht die Pioniere der agilen Grundsätze an sich waren, so festigten sie doch die Werte, die schon länger im Hintergrund der Softwareentwicklung vorhanden waren.
Heute hat die agile Methodik nahezu jede Branche durchdrungen.
Zu den Autoren gehören:
- Kent Beck
- Mike Beedle
- Arie van Bennekum
- Alistair Cockburn
- Ward Cunningham
- Martin Fowler
- James Grenning
- Jim Highsmith
- Andrew Hunt
- Ron Jeffries
- Jon Kern
- Brian Marick
- Robert C. Martin
- Steve Mellor
- Ken Schwaber
- Jeff Sutherland
- Dave Thomas
Warum das Agile Manifest (immer noch) wichtig ist
Das Agile Manifest ist nach wie vor relevant, weil es den Fokus auf menschenzentrierte Arbeitsweisen legt und Flexibilität ermöglicht.
Mit schnellen technologischen Veränderungen gehen oft sich ändernde Projektanforderungen einher. Das Agile Manifest ermöglicht es Projektmanager:innen, Anpassungsfähigkeit und Zusammenarbeit zu priorisieren, indem es ein reaktionsschnelles und widerstandsfähiges Projektumfeld schafft, das gleichzeitig Arbeit liefert, Innovationen vorantreibt und bei Bedarf neue Wege einschlägt.
Es fördert auch eine kundenorientierte Denkweise, indem funktionierende Lösungen mehr wert sind als umfassende Dokumentation. Dadurch können Projektmanager:innen frühzeitig Feedback einholen und ihre Arbeit kontinuierlich verbessern, sodass das Projekt eng an den Bedürfnissen der Nutzenden ausgerichtet ist. Dieser iterative und kundenzentrierte Ansatz erhöht sowohl die Erfolgsquote als auch die Zufriedenheit bei Projekten.
Wie sich das Agile Manifest praktisch anwenden lässt
Werfen wir einen genaueren Blick auf die vier Werte des Agilen Manifests. Durch die Betrachtung dieser Kernwerte tauchen wir gleichzeitig in die zwölf Prinzipien ein, die sich daraus ableiten.
Wert #1: Individuen und Interaktionen stehen über Prozessen und Werkzeugen
Der Kern von Agile sind die Menschen. Agile betont, dass ein Team gemeinsam arbeitet, eng zusammenarbeitet und eigenständig Entscheidungen trifft. Agile bedeutet nicht, einem Team vorzuschreiben, was es tun oder bauen soll.
Bei agilen Projekten muss Kommunikation frei fließen und kontinuierlich stattfinden, nicht strikt definiert und terminiert werden. In abgeschotteten Silos zu arbeiten, entspricht nicht dem agilen Ansatz.
Teamkommunikation bewerten
Fragen Sie sich selbst: Führen Sie und Ihr Team persönliche Gespräche? Oder verlassen Sie sich auf E-Mails, Dokumente und beliebte Messaging-Tools (keine Namen …)?
Auch wenn Sie remote arbeiten: Ein persönliches Gespräch kann vieles schneller ermöglichen. Gerade wenn ein Team neu zusammenkommt, schafft synchrone Kommunikation Vertrauen, Offenheit und baut Beziehungen auf.
Weniger kontrollieren
Wir waren alle schon mal zu kontrollierend. Aber Vertrauen ist essenziell für Agile. Suchen Sie nach etwas, das Sie sofort umsetzen können? NICHT MIKROMANAGEN (ja, das musste großgeschrieben werden).
Es ist verlockend, sehr kleinteilig bei den Aufgaben vorzugehen, diese an das Team zu verteilen und sie dann so lange nachzuverfolgen, bis sie die vorgegebene Deadline einhalten (oder eben nicht), nur um alles unter Kontrolle zu haben. Aber um dein Team wirklich zu stärken, musst du dich etwas zurücknehmen und ihnen die Verantwortung für ihre Arbeit überlassen!
Ein selbstorganisierendes Team fördern
Es geht nicht um Management – es geht um Führung und das Unterstützen der Teamarbeit. Ein selbstorganisierendes Team bedeutet, dass das Team selbst entscheidet, wie es seine Arbeit am besten erledigt. Sie bestimmen, wie der Arbeitsbacklog in auslieferbaren Code umgewandelt wird. Doch das bedeutet nicht, ins andere Extrem zu verfallen und keinerlei Unterstützung oder Leitlinien zu bieten – das Team braucht weiterhin eine Vision, Motivation und Hilfe bei der Beseitigung von Hindernissen.
Wie schafft man es also, Aufgaben nicht einfach nur zu verteilen, sondern den Arbeitsprozess aktiv zu begleiten?
Mach dir keine Sorgen um Prozess oder Tool
Ich weiß, ich weiß – das Thema Projektmanagement-Software und agile Projektmanagement-Software ist in der agilen PM-Welt allgegenwärtig.
Aber hier kommt’s: Deinem Kunden sind deine internen agilen Prozessabläufe egal. Und das ist auch richtig so.
Agilität bedeutet, den Kunden in den Mittelpunkt zu stellen und deinem Team zu ermöglichen, bessere und wertvollere Arbeit zu liefern. Mehr zu diesem kundenfokussierten Ansatz später!
Silos auflösen
Silos behindern die Zusammenarbeit und stehen damit agilen Werten entgegen.
Um Silos zu vermeiden, beachte folgende Tipps:
- Das Team gemeinsam platzieren: Ja, das schon wieder. Es ist großartig, wenn sich Designer zusammensetzen und über Design sprechen können, aber wäre es nicht noch besser, wenn sie sich direkt mit Entwicklern über das Produkt austauschen? Mir ist bewusst, dass das in größeren Organisationen oder in Remote-Umgebungen schwierig ist, aber selbst ein gemeinsamer Slack-Channel oder geplante virtuelle Coworking-Sessions, in denen alle gleichzeitig und ortsunabhängig konzentriert arbeiten, können das Team stärker verbinden.
- Weitergabe zwischen Abteilungen vermeiden: Der stärker abgegrenzte, wasserfallartige Ansatz, bei dem jede Abteilung einzeln und nacheinander (erst UX, dann Design, dann Entwicklung, dann QA) arbeitet, führt oft zu Kommunikationsproblemen und erhöht den Aufwand. Lass dein Team lieber gemeinsam an Features arbeiten, statt Aufgaben einfach weiterzureichen. Selbst wenn du mit Sprints arbeitest, aber einen vorgelagerten Design-Sprint hast, beziehe deine Entwickler mit ein – schließlich sind sie es, die das Produkt später bauen!
Wert #2: Funktionierende Software statt umfassender Dokumentation
Denk daran: Das Manifest fordert nicht, Dokumentation abzuschaffen – es vermittelt nur, dass die Dinge auf der linken Seite mehr geschätzt werden als die auf der rechten. Das heißt, Dokumentation existiert weiterhin. Scrum etwa bedient sich User Storys, um Entwicklern den Einstieg in die Umsetzung zu erleichtern.
Aber was kannst du tun, um weg von schwerfälliger, zeitfressender Dokumentation zu kommen und schnell etwas Greifbares zu erstellen?
Dokumentation verschlanken
Erkenne die Schmerzpunkte oder Hindernisse in deinem Prozess. Ist deine Dokumentation zu umfangreich? Verbringst du ewig damit, das perfekte Pflichtenheft zu erstellen, feilst stundenlang an einem Funktionsumfang und hast dann keine Zeit mehr, das Produkt tatsächlich zu bauen? Reduziere unnötige Dokumentation, indem du:
- Dich auf Design- und Entwicklungsaufgaben konzentrierst, die direkt ins Produkt einfließen, anstatt auf ein Dokument, das letztlich nie genutzt wird
- Zu Beginn Workshops durchführst, um Anforderungen und nächste Schritte zu definieren, anstatt lange Dokumente zu schreiben. Ergebnisse dokumentieren und mit Fotos und kurzen Notizen teilen.
Schnell in die Umsetzung kommen
Seitenweise Anforderungen zu schreiben ist eine Möglichkeit, die Bedürfnisse von Unternehmen, Kunden und Nutzern abzubilden. Doch am Ende ist es viel hilfreicher, etwas Funktionierendes zu sehen, das sich verhält und reagiert.
Probiere einige der folgenden Ansätze, um dein Projekt schneller voranzubringen:
- Discovery- oder Definitionsphase zeitlich verkürzen: Wenn du die Zeit für die Ausarbeitung und Definition beschränkst, hast du schneller etwas, mit dem Designer und Entwickler weiterarbeiten können. Das Tempo kannst du zum Beispiel mit diesen Discovery-Session-Fragen erhöhen.
- Workshops veranstalten: Teamworkshops bringen Stakeholder an einen Tisch und erleichtern schnellere Entscheidungen.
- Deinen Projektplan ändern: Hast du die Phasen Definition, Design und Entwicklung nacheinander gestaffelt? Vielleicht solltest du die Entwicklung vorziehen und Designer und Entwickler früher gemeinsam etwas ausarbeiten lassen.
Verwenden Sie Prototyping-Methoden statt statischer Designs
Sie sollten Fortschritte nicht als ein Definitionsdokument oder ein statisches Design betrachten, das Ihr Kunde nur abhakt. Zeigen Sie ihm stattdessen etwas, das Teil des fertigen Produkts wird.
Nutzen Sie Rapid Prototyping, um etwas Funktionierendes und Nutzbares zu erstellen – und noch wichtiger, etwas, das Sie mit echten Kunden testen können. Rückmeldungen zu einem Prototyp einzuholen, wird so zu einer sinnvollen Methode, um Fortschritte zu verfolgen, anstatt sich auf ein Ergebnis zu verlassen, das nicht Teil des Endprodukts ist.
Sie können Prototypen in verschiedenen Detaillierungsgraden erstellen:
- Niedrige Detailtreue: Klickbare Designs. Hierbei geht es darum, möglichst schnell eine Version zu bekommen, mit der man das Aussehen, das Gefühl und einfache Interaktionen mit Kunden testen kann.
- Mittlere Detailtreue: Einsatz von etwas Bewegung oder Animationen.
- Hohe Detailtreue: Funktionierendes HTML. Wird für komplexere Interaktionen genutzt, kann aber direkt in veröffentlichungsfertigen Code überführt werden.
Prototypen mit hoher Detailtreue kommen einer „funktionierenden Software“ am nächsten, sind aber meist zeitaufwendiger in der Erstellung. Prototypen mit niedriger oder mittlerer Detailtreue bieten Entwicklern eine bessere Orientierung als statische Designs.
Liefern Sie dem Endnutzer oder Kunden schnell etwas aus
Das ist ein entscheidender Punkt.
Durch häufige Releases funktionierender Software können Ihre Kunden direkt mit neu veröffentlichten Funktionen arbeiten. Anstatt bis zum Ende des Projekts auf einen großen Launch zu warten, ist es entscheidend, dem Kunden früher Wert zu liefern, um ein besseres Produkt zu erhalten.
Wie können Sie in Ihrer Organisation häufiger ausliefern?
- Überprüfen Sie Ihren Projektplan oder Projekt-Roadmap: Haben Sie geplant, die Entwicklung komplett abzuschließen und dann am Ende Ihres Projekts zu veröffentlichen? Arbeiten Sie stattdessen mit Ihrem Team zusammen, um die Arbeit in Funktionspakete oder Arbeitsschritte zu unterteilen, die unabhängig voneinander veröffentlicht werden können.
- Fokussieren Sie sich auf Blockaden: Ein zentraler Teil Ihrer Aufgabe ist es, das Team bei Blockaden zu unterstützen. Wie können Sie ihnen helfen, effizienter auszuliefern? Gibt es Arbeitsweisen, die Releases verzögern? Ein Sprint-Retrospektive mit Ihrem Team kann Ansatzpunkte für Prozessverbesserungen liefern.
- Automatisieren: Falls Ihr Unternehmen viel Aufwand in Releases steckt, automatisieren Sie Prozesse, wann immer möglich. Automatisierte Tests und Deployments sparen z. B. manuelle Arbeit und verringern den Arbeitsaufwand für einen Release. Sprechen Sie mit Ihrem agilen Entwicklungsteam über die aktuellen Prozesse und mögliche Automatisierungen.
Wert #3: Zusammenarbeit mit dem Kunden statt Vertragsverhandlung
Anstatt zu Beginn eines Projekts einen extrem spezifischen Vertrag zu erstellen, der genaue Ergebnisse, Umfang, Budget und Zeitpläne festlegt, halten Sie Ihren agilen Vertrag so allgemein wie möglich. Treffen Sie Entscheidungen im Laufe des Projekts durch enge Zusammenarbeit mit Ihren Kunden und Stakeholdern.
Agilität bedeutet nicht, viel Zeit mit der Definition von Anforderungen im Voraus zu verbringen. Es geht darum, ein Projekt zu starten und im Laufe der Zeit, durch Kundentests und Feedback anhand funktionierender Software, zu lernen.
Setzen Sie auf eine kundenorientierte Herangehensweise
Ich liebe dieses Zitat aus einem Artikel von Neil Killick:
„Ein agiler Denker fragt sich fortlaufend: 'Was ist der einfachste/schnellste Weg, dem Kunden einen Mehrwert zu liefern?' Stellen Sie sich diese Frage täglich? Wenn nicht, ist das Ihr erster Schritt.“
Nicht nur Designer und Entwickler sollten so denken – auch Projektmanager. Wir sind ebenfalls dafür verantwortlich, dem Kunden das bestmögliche Produkt oder die bestmögliche Dienstleistung zu liefern. Ihr Kunde, der Nutzer Ihres Produkts oder Ihrer Dienstleistung, sollte im Mittelpunkt all Ihrer Bemühungen stehen.
Stellen Sie den Endkunden ins Zentrum Ihrer Planung
Statt um Liefergegenstände und Schätzungen herum zu planen, planen Sie auf Basis von wertstiftenden Kundenergebnissen. Was soll der Kunde tun – und warum? Wie prüfen wir, ob es tatsächlich funktioniert?
Lenken Sie die Gespräche darauf, welchen Mehrwert Sie für den Kunden geliefert haben, statt wie viele Arbeitspakete Sie abgearbeitet haben.
Beziehen Sie Ihren Kunden eng in das Projekt mit ein
Halten Sie nicht nur wöchentliche Status-Meetings ab und liefern dann am Ende eines bestimmten Zeitraums ab. Arbeiten Sie stattdessen darauf hin, Ihren Kunden täglich in das Projekt einzubinden.
Wenn Sie eher nach einem Scrum-Prozess arbeiten, machen Sie den Kunden zum Product Owner. Der Product Owner ist dafür verantwortlich, die geschäftlichen, technischen und Kundenanforderungen zusammenzuführen. Die frühzeitige und regelmäßige Einbindung sowie Zustimmung des Kunden ist entscheidend, um Verzögerungen zu vermeiden. Dies führt letztlich zu einem besseren Produkt oder Service für den Endkunden.
Beziehen Sie einen entfernt arbeitenden Kunden ein
Falls Ihr Kunde keine Zeit hat, aktiv am Projekt mitzuwirken oder anderweitig nicht eingebunden ist, stellen Sie sicher, dass jemand im Team den Kunden vertritt. Es ist von entscheidender Bedeutung, dass jemand die Bedürfnisse von Kunde und Unternehmen berücksichtigt.
Auch wenn der Kunde nicht täglich eingebunden ist, stellen Sie sicher, dass Sie regelmäßig mit ihm kommunizieren und ihn zumindest in alle agilen Planungs- und Priorisierungsrunden einbeziehen. Zeigen Sie ihm die Vorteile seiner Beteiligung auf.
Führen Sie eine Produkt-Roadmap ein
Erwägen Sie, eine Produkt-Roadmap einzusetzen, um den Weg Ihres Produkts zu planen. Eine Produkt-Roadmap kommuniziert den Plan für das Produkt und visualisiert die geplanten Funktionen. Eine Roadmap ist zu Beginn eines Projekts nicht in Stein gemeißelt; sie entwickelt sich im Laufe der Zeit und spiegelt veränderte Prioritäten wider.
Sprechen Sie unbedingt mit Ihren Endanwendern oder Kunden
Ich kann es nicht genug betonen – Sie sollten versuchen, Ihr Produkt frühzeitig und häufig mit Endanwendern und Kunden zu testen.
Tests bieten zahlreiche Vorteile:
- Sie können sicherstellen, dass Ihr Produkt die Bedürfnisse der Kunden erfüllt, d.h. ist das Produkt für den Kunden und somit für das Unternehmen wertvoll? Das hilft Ihnen, den Product-Market-Fit zu bewerten.
- Sie können Kundenfeedback in Ihren Design- und Entwicklungsprozess einfließen lassen und damit ein besseres Endprodukt schaffen.
- Sie können wertvolle Erkenntnisse für die zukünftige Arbeit gewinnen.
- Das oft genannte Problem bei Kundentests ist das Budget – es kann teuer sein. Hier sind einige Möglichkeiten, unabhängig von Ihrem Projektbudget zu testen:
Guerrilla-Testing: Ich liebe diese Methode, weil sie günstig und unkompliziert ist. Bieten Sie Leuten einen echten (oder virtuellen) Kaffee an, wenn sie ein paar Fragen zu Ihren Designs oder Prototypen beantworten. Es ist schwieriger zu kontrollieren, wer Ihre Fragen beantwortet, aber ein schnelles Feedback kann hilfreich sein, wenn Sie beispielsweise das Look-and-Feel oder einfache Interaktionen testen möchten.
Umfragen: Um quantitative Daten von einer breiteren Zielgruppe zu erhalten, können Sie eine Umfrage erstellen, um Designs zu bewerten oder das Kundenverhalten genauer zu analysieren.
Seiten wie usertesting.com: Sie können Ihre Designs auf einer dieser Seiten hochladen und dort anhand von Kriterien gezielt Personen rekrutieren. Diese klicken sich dann durch Ihre Entwürfe, protokollieren ihre Gedanken und beantworten Ihre Fragen.
Persönliches Testing: Ja, das kann die kostspieligere Option sein, da Sie meist Probanden anwerben und ihnen Anreize bieten müssen. Dies kann jedoch gerade bei komplexen Interaktionen oder risikoreichen Funktionen sehr wertvoll sein.
Wert #4: Reagieren auf Veränderungen statt stur einem Plan zu folgen
Agile und Wasserfall-Projekte könnten in dieser Hinsicht nicht unterschiedlicher sein. In klassischen Softwareprojekten werden Anforderungen, Kosten und Zeitpläne im Voraus festgelegt, während agile Methoden Veränderungen zulassen und sogar begrüßen.
Veränderung ist gut! Sie ist nicht böse! Wie viele Projektpläne sind bei Ihnen schon genau so verlaufen, wie Sie sie am Anfang erstellt haben? Ich vermute, nicht viele (ich selbst habe Projekte mit Dutzenden überarbeiteten Plänen erlebt).
Pläne sind eine Momentaufnahme, die Sie während des Projekts präzisieren können – jedoch lassen sie meist keine Veränderungen zu. Was passiert, wenn sich die Kundenbedürfnisse ändern? Wenn das Unternehmen einen neuen Kurs einschlägt? Wenn der Kunde neue Prioritäten setzt? Wenn sich ein Feature als komplexer entpuppt als gedacht?
Agile Arbeitsweisen begegnen Ungewissheiten mit einem adaptiven Planungsansatz (wie etwa Planning Poker). Beispielsweise ist im Scrum vorgesehen, dass das Team Sprint für Sprint plant. Bevor eine zeitlich begrenzte Arbeitsphase beginnt, nehmen agile Teams Aufgaben aus dem Backlog und priorisieren sie für die Umsetzung.
Auch wenn oft der Wunsch besteht, Kosten, Zeitrahmen und Umfang zu Beginn des Projekts festzunageln, führt ein realistischer Umgang mit den Unsicherheiten meist zu einem weitaus besseren Endprodukt. Und genau das sollten Sie, Ihr Kunde und Ihre Stakeholder am Ende wollen.
Hier einige Möglichkeiten, wie Sie Veränderungen in Ihren Projekten zulassen und mehr Flexibilität fördern können:
Erstellen Sie einen "leichten" Plan, um Stakeholder zu beruhigen
„Aber wir brauchen doch einen Plan!“, rufen Ihre Stakeholder. Statt sie mit „Überraschung, es gibt keinen Plan!“ zu verschrecken, erstellen Sie einen leichten Release-Plan, um ihnen Vertrauen in den etwas weniger förmlichen Ansatz zu geben.
Wenn Sie agiles Projektmanagement mit Scrum-Prozessen machen, werden Sie eine Liste von priorisierten und geschätzten User Stories in Ihrem Backlog haben. Arbeiten Sie mit dem Product Owner zusammen, um diese grob zu Releases zu gruppieren und ordnen Sie diese Ihrer Produkt-Roadmap zu.
Versuchen Sie, nicht alles im Voraus zu planen, da sonst die Vorteile der Nutzung der Scrum-Methodik verpuffen. Zeigen Sie Ihren Stakeholdern, was Sie in den ersten zwei bis drei Releases planen, und erklären Sie ihnen dann, wie das erneute Planen ein Kernelement der agilen Arbeitsweise ist. Kommunizieren Sie Updates und weitere Releases laufend. Hoffentlich gibt Ihnen das das Vertrauen, das sie brauchen!
Führen Sie das Team schrittweise an einen Sprint-basierten Ansatz heran
Mike Cohn schlägt in seinem Artikel „Introducing an agile process to an organization“ vor, Teams den Einstieg in Scrum zu erleichtern, indem eine Reihe von Sprint-Typen definiert werden, zum Beispiel:
- Prototyping
- Anforderungserhebung
- Analyse und Design
- Implementierung
- Stabilisierung
So beschreibt er, wie dies helfen kann:
„Wir arbeiten dann mit den Teams zusammen, um die Artefakte zu definieren, die aus jedem Sprint-Typ hervorgehen werden. Durch die Nutzung von Sprint-Typen wird genügend Formalität eingeführt, sodass die Teams ihren Weg durch das Projekt klarer erkennen können. Wenn die Teams mit der informelleren agilen Vorgehensweise vertrauter werden, lassen sie das Konzept der Sprint-Typen nach und nach weg.“
Dies ist eine weitere Möglichkeit, Ihren Release-Plan zu gestalten. Wenn Sie jedem Sprint einen „Typ“ zuweisen, können die Stakeholder sehen, wie der Plan Form annimmt, ohne dass Sie Features garantieren müssen. Ihr Team bekommt auch ein besseres Gefühl dafür, woran sie arbeiten werden.
Verabschieden Sie sich von festen Deadlines
Dem Team eine Deadline zu geben oder einen festen Termin an den Kunden zu kommunizieren, sind Strategien, die entweder zum Scheitern verurteilt sind oder zumindest unterwegs zu Stress führen. Vertrauensaufbau zwischen Ihnen und Ihrem Team sowie zu Ihrem Kunden oder Stakeholder ist entscheidend, um zu beweisen, dass Sie liefern – und dabei auch echten Mehrwert für den Endkunden schaffen.
Denken Sie daran: Sie versuchen, die Notwendigkeit für viele Meilensteine und Freigaben zu reduzieren. Die Einführung von Deadlines in Ihrem Projekt wird Ihnen dabei nicht helfen. Es ist auch nicht gut, Ihrem Team ständig im Nacken zu sitzen und sie für die Arbeit zu drängen, die sie „versprochen“ haben zu liefern.
Wie oben erwähnt, können Roadmaps und Release-Pläne ein gutes Mittel sein, um von einem Ansatz mit festen Terminen abzurücken. Indem Sie den Stakeholdern vermitteln, was in der nahen Zukunft veröffentlicht wird, können Sie ihnen das Gefühl geben, dass es einen Plan gibt.
Verwenden Sie ein nach Aufwand abgerechnetes Leistungsspektrum
Wenn Sie einen Festpreis mit festen Lieferobjekten vereinbart haben, ist es schwierig, auf agile Weise zu liefern. Sie können zwar einige der schon beschriebenen Techniken nutzen, z. B. eine stärker kollaborative Teamarbeit ermöglichen. Aber Sie sind eingeschränkt, wie sehr Sie auf Änderungen reagieren und sich anpassen können, dem Team die Entscheidung über ihre Aufgaben überlassen oder einen stärker kundenzentrierten Ansatz verfolgen.
Arbeiten Sie mit Ihrem internen Team und dem Kunden zusammen, um ein nach Aufwand abgerechnetes Leistungsspektrum zu etablieren – das heißt, der Kunde bezahlt für ein Team, nicht für feste Lieferobjekte. Anfänglich könnten Kunden nervös reagieren, wenn sie nicht genau wissen, was sie bekommen.
Um dieser Sorge entgegenzuwirken, könnten Sie im Rahmen des Leistungsspektrums ein Backlog mit Aktivitäten oder Aufgaben einbeziehen, die für den Launch in Betracht gezogen werden könnten. Halten Sie im Vertrag fest, dass das Team das Backlog mit Kundeneinbindung während des Projektfortschritts neu plant und priorisiert (wobei nicht jedes Element berücksichtigt wird).
Um besser mit sich verändernden Prioritäten und Liefergegenständen umzugehen, können Teams auf agile Management-Software setzen, um ihr Backlog kontinuierlich neu zu priorisieren, sowie auf Kollaborations-Tools für die Softwareentwicklung, um funktionsübergreifende Zusammenarbeit zu koordinieren.
Auf diese Weise verpflichten Sie sich nicht zu einem fest definierten Leistungsumfang, und der Kunde muss weniger Sorge haben, wie das Endprodukt letztlich aussehen wird.
Behalten Sie den Fortschritt im Blick
Das Tracken und Visualisieren des Fortschritts fällt auch ohne formellen Projektplan nicht einfach unter den Tisch. Den Fortschritt für das Team und die Stakeholder sichtbar zu machen, sorgt nicht nur dafür, dass mögliche Blockaden und Engpässe nicht übersehen werden, sondern hält auch die Stakeholder auf dem Laufenden.
Der Einsatz eines Kanban-Boards nach dem WIP-Prinzip oder agiler Dashboards eignet sich gut für agile Projekte. Sobald Sie Ihren Prozess visualisiert haben, können Sie begleitende Aufgaben und Aktivitäten planen. Das hilft dabei, Engpässe zu entdecken und zu beseitigen, um eine schnellere Lieferung an die Kunden zu ermöglichen.
Kritik am agilen Manifest
Wie jede andere Projektmanagement-Methode ist auch Agile nicht perfekt. Kritiker weisen darauf hin, dass die Autoren des Agile Manifesto eine homogene Gruppe waren, die möglicherweise alternative Herangehensweisen an Arbeit nicht berücksichtigt haben – etwa die Vorteile von Remote-Arbeit oder wie agile Methoden außerhalb der Softwareentwicklung angewendet werden können.
Wenn man es übertreibt, kann Agile dazu führen, dass Entscheidungen im Ausschuss getroffen werden, was die Arbeitsgeschwindigkeit verlangsamen kann. Fehlende Dokumentation könnte die Projektausführung beeinträchtigen, insbesondere in einer Remote-Umgebung, in der asynchrone Kommunikation entscheidend ist.
Wenn Sie sich entscheiden, Agile in Ihren Projekten einzusetzen, sollten Sie sich unbedingt an den agilen Werten und Prinzipien orientieren. Sie sind ein nützlicher Leitfaden, um die schlimmsten Auswüchse der agilen Arbeitsweise im Zaum zu halten.
Lesen Sie mehr über die Debatte, ob Agile eine Methodik oder eine Denkweise ist, hier.
Agilität, nicht Agile
Ein letzter Gedanke: Vergessen Sie die Retrospektive nicht! Wie das Manifest besagt:
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.
Unabhängig davon, welche Art von Prozess Sie anwenden, ist die Retrospektive ein wirkungsvolles Mittel, um zu prüfen, wie Sie arbeiten und den Erfolg zu optimieren. Sorgen Sie dafür, dass Sie Projektretrospektiven regelmäßig in den von Ihnen verwendeten Prozess einbauen – und dass Sie einen Mechanismus haben, um Ihre Erkenntnisse zu verwerten! PS: Es ist wichtig, dass Sie auch Ihre stillen Teammitglieder in Retros zum Sprechen bringen – hier erfahren Sie wie.
Wie geht es weiter?
Um mehr darüber zu erfahren, wie Sie agile Arbeitsweisen implementieren und von den besten Projektmanagern der Branche lernen können, werfen Sie einen Blick auf unsere DPM-Mitgliedschaftsoptionen.
