NBA13: Agile Projektplanung
Shownotes
Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile.
Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/29-nba13-agile-projektplanung
—
Letzte Folge „NBA12: Vertrauen geben“
Agil-O-Mat
Artikel „Agile Projektplanung“
Spielkarten „Das Agile Manifest“
Zusammenfassung
In Folge 13 von No Bullshit Agile geht Thomas der Frage nach, wie agile Projektplanung funktioniert und wie man mit der Frage „Wann ist das Projekt fertig?“ umgeht. Im Gegensatz zum traditionellen Wasserfall-Modell, das detaillierte Pläne und Zeitvorgaben erstellt, verfolgt die agile Methode einen flexibleren Ansatz.
Thomas erklärt, dass in der agilen Welt die Planung kontinuierlich und in Phasen erfolgt. Um den Umfang und den Abschluss eines Projekts zu definieren, empfiehlt er zwei Methoden:
User Story Mapping: Diese Methode hilft dabei, die Anforderungen und Benutzererfahrungen zu visualisieren. Dabei werden große User Tests in kleinere Sub-Tasks zerlegt und nach Priorität geordnet, um eine klare Vorstellung von den notwendigen Features zu bekommen.
Dimensional Planning: Hierbei geht es darum, die Sub-Tasks aus dem User Story Mapping sinnvollen releasebaren Versionen zuzuordnen.
Diese Methoden unterstützen dabei, das Projekt in handhabbare Teile zu gliedern und kontinuierlich an Verbesserungen zu arbeiten, anstatt sich auf ein einmaliges Enddatum festzulegen. Thomas hebt hervor, dass agile Planung nicht bedeutet, auf Planung zu verzichten, sondern diese iterativ und flexibel zu gestalten.
Transkript
Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt auf der Praxis, daher auch der Name No Bullshit Agile.
In der letzten Folge habe ich über Vertrauen geben gesprochen. Wenn dich das Thema interessiert, hör doch gerne mal rein. Dies ist die Folge 13, und heute geht es um die agile Projektplanung.
Bevor wir einsteigen, wie immer ein bisschen Housekeeping: Zuallererst, ich bin auf mastodon.social gewechselt. Vorher war mein Mastodon-Account bei podcast.social. Das habe ich tatsächlich gemacht, weil auf mastodon.social mehr los ist und ich auch festgestellt habe, dass ich da mehr Leute erreiche. Bei Mastodon gibt es im System bereits vorgesehene Weiterleitungen. Das heißt, wenn du mir folgst, folgst du mir jetzt auch automatisch auf der neuen Mastodon-Instanz. Du musst also eigentlich nichts tun; Mastodon regelt das für dich.
Das zweite ist, es gibt jetzt auf der Webseite No Bullshit Agile.de einen "Agilomaten", wie ich ihn genannt habe. Wie du gemerkt hast, versuche ich, hier viel Fundament zu setzen, und für mich ist das Fundament eben das Agile Manifest und die 12 agilen Prinzipien. Und ich habe mir gedacht, es wäre doch ganz gut, auf einer Webseite A) das darzustellen und B) Filter möglich zu machen. Deswegen habe ich mir Kategorien überlegt.
Auf der Webseite sieht man dann erst einmal alle vier Punkte aus dem Agile Manifest und alle 12 agilen Prinzipien auf Karten optisch dargestellt. Du kannst die filtern. Zum Beispiel kannst du sagen: „Okay, zeigt mir alle Elemente aus dem Agile Manifest und den 12 agilen Prinzipien, wo es um Effizienz geht.“ Dann reduziert sich die Anzahl dieser Karten, und du siehst, welche Karten sich mit Effizienz beschäftigen.
Es ist zum Beispiel jetzt gerade so, wenn ich auf Effizienz schaue, dann ist die Idee, dass man mit einem Team, einer Kollegin oder einem Kunden diskutiert und dabei Leitplanken hat – unser Fundament. Man kann sich dann anschauen, was das Agile Manifest dazu sagt und wo man das in den 12 agilen Prinzipien wiederfindet.
Das ist natürlich schwer in einem Podcast zu erklären. Schau da gerne mal rein; den Link dazu findest du wie immer in den Shownotes. Ich überlege tatsächlich, ob ich vielleicht ein kleines YouTube-Video mache, um das zu erklären oder zu zeigen.
Ja, soweit zum Housekeeping. Dann kommen wir doch mal zum Kernthema für heute, nämlich der agilen Projektplanung.
Die erste Leitfrage, die man sich da stellen kann – und die kennt ihr wahrscheinlich auch, wenn ihr mit Kunden sprecht – lautet: „Wann ist das Projekt denn fertig?“ Genau diese Frage bekomme ich immer wieder und habe ich mir auch immer wieder versucht zu beantworten.
Für mich ist die grundlegende Herangehensweise, wie man in der Agilität mit so einer Frage umgeht, wie folgt: Im klassischen Wasserfall würde man jetzt sagen, wir erstellen einen Projektplan, haben ein Pflichtenheft und ein Lastenheft, machen einen Projektstrukturplan (PSP) und können dann den kritischen Pfad ermitteln, weil wir für jedes Element auch eine Reihenfolge definiert haben und berechnet haben, wie lange ein Element dauert. Der kritische Pfad beantwortet dann genau diese Frage: „Das Projekt ist in 14 Wochen fertig.“ Wenn es zu Verzögerungen kommt, schaut man, wie man den kritischen Pfad optimieren kann. Das wäre das klassische Projektmanagement.
In der agilen Welt ist es anders. Wir wollen ja auf Umwelteinflüsse reagieren und nicht an einem Pflichten- und Lastenheft festhalten. Wir wollen das Learning, das wir während des Projekts haben, einfließen lassen. Also können wir so nicht vorgehen.
Wenn man die grundsätzliche Frage „Wann ist das Projekt fertig?“ jetzt mal zerlegt, sehe ich zwei Dinge, die man hinterfragen muss. Erstens: Was genau ist das Projekt? Zweitens: Wann genau können wir überhaupt sagen, dass das Projekt fertig ist?
Was ist das Projekt? Wann ist ein Projekt fertig? Ich habe mal irgendwo auf Mastodon gelesen, da hatte jemand auf eine solche Frage geantwortet, dass ein Projekt fertig ist, wenn man „den Stöpsel zieht“ – also wenn das Projekt seinen Lebenszyklus beendet hat. Dann kann man sicher sagen, dass das Projekt fertig ist. Mir geht es darum, dass wir ja permanent an dem Projekt arbeiten wollen – sei es Projekt oder Produkt. Das bedeutet, dass man überhaupt nicht sagen kann, das Projekt ist fertig. Wir wollen weiterarbeiten. Wir haben vielleicht Projektphasen. Wir wollen vielleicht sagen, diesen Teil machen wir zuerst, dann den nächsten und so weiter.
Wann genau können wir sagen, dass es fertig ist? Das hängt natürlich damit zusammen, wie wir gerade gesehen haben, dass wir gar nicht definieren können, was das Projekt ist. Also können wir auch nicht sagen, wann das Projekt fertig ist. Das ist die Antwort auf diese Frage.
Es gibt zwei Methoden, die einem helfen, in der agilen Welt einen Überblick über das Projekt mit dem heutigen Kenntnisstand zu bekommen und es in Phasen zu unterteilen, um dann konkret benennen zu können, wann eine Version oder Phase fertig ist. Das ist kein komplettes Missverständnis: In agilen Projekten kann man planen und muss auch planen, nur eben viel kleiner und viel öfter.
Die erste Methode, die uns hilft, was genau das Projekt ist, nennt sich User Story Mapping. Mit User Story Mapping haben wir eine schöne Methode, um zu sammeln, welche Anforderungen wir zum heutigen Zeitpunkt haben. Das Verfahren funktioniert wie folgt: Ihr schnappt euch ein großes Whiteboard und viele Post-Its oder nutzt ein elektronisches Tool wie Miroboard, FigJam oder Confluence Whiteboard. Ich würde versuchen, das erst einmal auf einem Whiteboard wirklich zu machen.
Ihr setzt euch mit einem oder zwei Stakeholdern zusammen, also im Zweifel mit dem Kunden und jemandem aus dem Dev-Team. Wir sammeln methodisch alle Anforderungen. Wir fangen an mit den sogenannten User Tests. Das sind die groben Aufgaben, die ein Benutzer unseres Systems erledigen möchte.
Zum Beispiel: Angenommen, wir haben einen Job, in dem wir Bücher verkaufen. Dann sind diese User Tests etwa: Der Benutzer kommt auf unseren Shop, sucht nach einem Buch, wählt aus den Suchtreffern aus, packt das in den Warenkorb und klickt auf „Bestellen“ und muss dann noch die Zahlung durchführen. Das ist eine Reise, die der Benutzer macht und die relativ sequenziell verläuft. Es ist klar, dass Benutzer eventuell bestimmte Schritte überspringen oder dass es Abzweigungen gibt. Aber wir haben eine grobe Orientierung darüber, was ein Benutzer im Durchschnitt macht.
Ihr schreibt diese Schritte auf Post-Its und klebt sie ans Whiteboard. Im nächsten Schritt gruppiert ihr diese User Tests nach Aktivitäten. In unserem Beispiel könnten das so etwas wie „Suchen“, „Details ansehen“ und „Kaufen“ sein.
Im letzten Schritt füllt ihr weitere Karten aus – die sogenannten Sub-Tests. Hier zerlegt ihr jeden einzelnen Schritt der User Tests in kleinere Happen. Zum Beispiel: Der Benutzer gibt einen Begriff in ein Suchfeld ein, wir zeigen einen Suchergebnis an, und so weiter.
Ihr findet einen Link zu einem Artikel, den ich geschrieben habe, in den Shownotes. Dort gibt es Schaubilder zu dem, was ich gerade beschreibe. Wenn dich das im Detail interessiert, klick gerne in den Shownotes auf den Link zum Artikel.
Was haben wir jetzt im User Story Mapping? Wir haben auf dem Whiteboard viele Post-Its, wahrscheinlich in unterschiedlichen Farben. Wir haben eine grobe Gruppierung (Aktivitäten), darunter eine feinere Gliederung (User Tests) und schließlich viele Post-Its mit den detaillierten Sub-Tests.
Im letzten Schritt nehmen wir diese kleinen Sub-Tests und bringen sie in eine Reihenfolge. Wir überlegen, was wichtiger ist: Soll der Benutzer zuerst einen Suchbegriff eingeben oder ist es wichtiger, dass er ein Bild im Suchtreffer sieht? Wahrscheinlich sagen wir alle, dass der Benutzer zuerst den Suchbegriff eingeben muss. Ein Bild im Suchtreffer ist noch nicht so wichtig.
Damit haben wir die Frage beantwortet, was genau das Projekt zum heutigen Zeitpunkt ist. Im nächsten Schritt geht es darum, die Frage „Wann ist das Projekt fertig?“ zu beantworten. Dafür wenden wir eine weitere Methodik an, die auf dem User Story Mapping basiert. Diese Methodik nennt sich Dimensional Planning.
Wir nehmen von den Sub-Tests so wenig wie möglich und sagen, diese Summe der Sub-Tests bilden die Version 1. Das tun wir horizontal, über alle Aktivitäten, die ein Benutzer auf seiner Reise macht. Warum horizontal? Im Agile Manifest steht, wir wollen funktionierende Software liefern. Das bedeutet, die erste Version, die wir dem Kunden liefern, soll funktionierend und benutzbar sein.
Ich hatte letztens eine kleine Unterhaltung zum Thema MVP, was sich auch ein bisschen nach MVP anhört. Allerdings gefällt mir MVP nicht so gut, weil wir eine Version 2, 3, 4 und so weiter haben werden. Es wäre komisch, diese Versionen als MVP 2, MVP 3 zu bezeichnen. Deswegen nenne ich es lieber: Eine erste Version, die in sich geschlossen, funktionierend und benutzbar ist. Diese erste Version soll so klein wie möglich sein.
Nehmen wir unser Buchbeispiel: Die minimalste Version ist, dass der Benutzer auf das System kommt, nach einem Buch sucht und es findet, aber vielleicht nicht bezahlen kann. Vielleicht muss er sich erst anmelden oder eine E-Mail-Adresse hinterlegen, um bezahlen zu können. Das ist die erste Dimension. Die Dimension, die wir hier betrachten, ist also die Funktionalität.
Es gibt aber noch weitere Dimensionen. Eine Dimension ist die Zeit, in der wir das Projekt umsetzen möchten. Die zweite Dimension, die ich immer wieder beobachte, ist, dass Kunden oft eine bestimmte Funktionalität mit einer bestimmten Verfügbarkeit erwarten. Das bedeutet, wir sagen, diese Version kann kommen, wenn sie eine bestimmte Funktionalität hat, und der Kunde kann das Ganze dann nutzen.
Zusammenfassend lässt sich sagen, dass wir eine Dimension der Funktionalität haben, eine Dimension der Zeit und eine Dimension der Verfügbarkeit. Die Dimension der Zeit ist natürlich eng mit der Dimension der Funktionalität verknüpft: Je mehr Funktionalität ich in eine erste Version packe, desto länger dauert es, diese Version fertigzustellen.
Beim Dimensional Planning setzen wir Prioritäten. Wir gucken uns an, wie viel wir in einer Version schaffen können und überlegen, welche Teile wir vielleicht noch weglassen oder in eine spätere Version verschieben müssen. Der Kunde kann eine erste Version frühzeitig bekommen, und wir können so kontinuierlich an weiteren Versionen arbeiten.
Das wäre die Herangehensweise, wie man mit dem agilen Projektmanagement plant. Man setzt Prioritäten, verschiebt Dinge, die nicht unbedingt in der ersten Version nötig sind, und arbeitet dann iterativ an weiteren Versionen.
Ich hoffe, das hilft dir bei deiner Planung und gibt dir einen guten Überblick darüber, wie man in der agilen Welt die Frage „Wann ist das Projekt fertig?“ beantworten kann.
Das war’s für heute von No Bullshit Agile. Ich freue mich, wenn du beim nächsten Mal wieder dabei bist.
Bis dahin, bleib agil!
