NBA13: Agile Projektplanung

Hallo und herzlich willkommen bei NoBullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und ich 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 NoBullshit Agile. In der letzten Folge habe ich über Vertrauen geben gesprochen. Wenn dich das Thema interessiert, hör doch gerne mal rein und dies ist die Folge 13, und heute geht es um die agile Projektplanung. Bevor wir einsteigen, wie immer ein bisschen Housekeeping, zuallererst mal ich bin auf mastodon.social gewechselt. Vorher war mein mastodon-Account ja bei podcast.social. Das habe ich tatsächlich gemacht, weil auf mastodon.social tatsächlich mehr los ist und ich auch festgestellt habe, dass ich da mehr Leute erreiche. Bei mastodon gibt es ja im System schon vorgesehene Weiterleitung, das heißt also wenn du mir folgst, folgst du mir jetzt auch automatisch auf der neuen mastodon-Instanz. Das heißt du müsst es eigentlich nichts tun oder du musst eigentlich nichts tun, mastodon regelt das eigentlich für dich selber. Das zweite ist es gibt jetzt auf der Webseite NoBullshit Agile.de. Ein Agilomaten habe ich es genannt. Wie du gemerkt hast, ich versuche ja hier viel Fundament zu setzen und für mich ist das Fundament eben das Agile Manifest und die 12 Agilem Prinzipien. Und ich habe mir gedacht, es wäre doch ganz gut auf einer Webseite die A mal darzustellen, aber B eben auch Filter wahrzumachen, deswegen habe ich mir so Kategorien überlegt, Text. Und auf der Webseite sieht man dann erst mal alle vier Punkte aus dem Agile Manifest und alle 12 Agilem Prinzipien auf so Karten optisch dargestellt und du kannst die Filtern zum Beispiel, kann ich sagen, okay, zeigt mir mal alle Elemente aus dem Agile Manifest und den 12 Agilem Prinzipien, wo es um Effizienz geht. Und dann reduziert er die Anzahl dieser Karten und du siehst dann eben, okay, das sind eigentlich die drei Karten bei Effizienz. Es ist zum Beispiel jetzt gerade so, ich gucke da drauf, wo es rund um Effizienz geht, meine Idee ist, man diskutiert mit einem Team oder mit einer Kollegin oder mit einem Kunden und es geht vielleicht, bleiben wir ruhig bei dem Beispiel um Effizienz. Und dann hat man die Leitplanken, unser Fundament und kann sich eben angucken, okay, das sagt das Agile Manifest dazu und dort finde ich das in den Agilem Prinzipien wieder. Das heißt, es ist natürlich schwer, ein Podcast zu erklären. Schau da gerne mal rein, den Link dazu findest du wie immer in den Schonots und ich überleg tatsächlich, ob ich vielleicht zum kleines YouTube Video mache, um das mal zu erklären oder mal zu zeigen. Ja, soweit zum Housekeeping und dann kommen wir doch mal zum Kernthema für heute, nämlich die Agile Projektplanung. Die erste Leitfrage, die man sich da stellen kann, ist und die kennt ihr wahrscheinlich auch, wenn ihr mit Kunden sprecht, wann ist das Projekt denn fertig? Und genau diese Frage bekomme ich immer wieder und habe ich mir auch immer wieder versucht zu beantworten. Für mich ist die Grundsätzlich herangehensweise, wie geht man denn in der Agilität mit so einer Frage um? Also im klassischen Wasserfall würde man jetzt halt sagen, okay, wir machen ein Projektplan, wir haben Pflichtenheft und wir haben Lastenheft, wir machen ein Projektstrukturplan, ein PSP und können dann den kritischen Fahrt ermitteln über all die Elemente, weil wir für jedes Element auch da reinfolge definiert haben und berechnet haben, wie lange ein Element dauert. Und dann haben wir unseren kritischen Fahrt und der kritische Fahrt beantwortet genau diese Frage. Das Projekt ist in 14 Wochen fertig und wenn ich Projekt Verzug habe, gucke ich halt, wie kann ich den kritischen Fahrt optimieren. Das wäre so ganz klassisch, ne? Ein klassischen Projektmanagement, das Vorgehen. In der agilen Welt ist es anders. Wir wollen ja eben auf die Umwelteinflüsse reagieren. Wir wollen nicht einem Pflichten- und Lastenheft festhalten, sondern wir wollen halt das Learning, das wir während des Projekt haben, einfließen lassen. Also können wir so nicht vorgehen. Und wenn man die grundsätzliche Frage, wann ist das Projekt fertig, jetzt mal zerlegt, dann sehe ich da zwei Dinge, die man hinterfragen muss. Das erste ist, was genau ist denn das Projekt? Und das zweite ist, wann genau können wir überhaupt sagen, dass das Projekt fertig ist? Was ist das Projekt? Ja, wann ist denn ein Projekt fertig? Ich habe mal irgendwo auf Mastedon gelesen, da hatte jemand, als ich so eine Frage gestellt habe, gesagt, für mich ist das so, das Projekt ist fertig, wenn wir einen Stöpsel ziehen. Also wenn das Projekt, sag ich mal, sein Lebenszyklus beendet hat. Ja, dann kann man ganz sicher sagen, dass das Projekt fertig ist. Mir geht es darum, dass wir ja permanent an dem Projekt arbeiten wollen. Also Projekt oder Produkt, das nutze ich jetzt, ja, ich sage mal gleich die Worte. Und das bedeutet eben, dass man überhaupt nicht sagen kann, das Projekt ist fertig. Wir wollen ja weiterarbeiten. Wir haben vielleicht Projektphasen. Wir wollen vielleicht sagen, okay, diesen Teil machen wir zuerst und dann machen wir diesen Teil und dann machen wir den nächsten und so weiter und so fort. Wann genau können wir sagen, dass es fertig ist? Das hängt natürlich damit zusammen, dass wir, wie wir gerade gesehen haben, gar nicht definieren können, was das Projekt ist. Also können wir auch nicht sagen, wann das Projekt fertig ist. Das ist halt genau die Antwort auf diese Frage. Und es gibt zwei Methoden, die einem aber helfen, in der agilen Welt einen Überblick über das Projekt mit dem heutigen Kenntnisstand zu bekommen und das in Phasen zu zerteilen, um dann ganz konkret benennen zu können, diese Version, diese Phase ist dann fertig, weil das geht. Das ist ja ein komplettes Missverständnis, dass man in agilen Projekten nicht planen könnte oder nicht planen müsste. Ganz im Gegenteil, wir planen halt viel viel kleiner und viel viel öfter. Und deswegen lasst uns mal einsteigen in die erste Methode, die uns hilft, was genau ist in das Projekt überhaupt zu beschreiben. Diese Methode heißt User Story Mapping. Mit User Story Mapping haben wir eine schöne Methode, um zu sammeln, was wir an Anforderungen zum heutigen Zeitpunkt überhaupt haben. Das Verfahren funktioniert wie folgt, ihr schnappt euch ein großes Whiteboard und viele Post-Eits oder tut das elektronisch mit Miroboard oder mit einem Fig Jam oder Confluence Whiteboard oder was auch immer ihr da benutzt. Ich würde versuchen, das erst einmal an einem Whiteboard wirklich zu machen und ihr setzt euch mit einem Stake Holdern zusammen, also im Zweifel 2 mit dem Kunden und jemand aus dem Dev Team. Und wir sammeln auf eine methodische Art und Weise jetzt alle Anforderungen. Wir fangen an mit den sogenannten User Tests. Das sind die groben Aufgaben, die ein Benutzer unseres System erledigen möchte mit unserem System. Wir machen mal ein Beispiel, wir nehmen mal an, wir haben einen Job, in dem wir Bücher verkaufen und wir wollen jetzt diese Anforderungen für diesen Job beschreiben. Dann sind diese User Tests tatsächlich so was wie der Benutzer kommt auf unseren Job, der Benutzer hat eine Suche und sucht jetzt nach einem Buch, er wählt aus den Suchtreffern was aus und packt das in den Warenkorb. Und im Warenkorb klickt er dann auf bestellen und muss dann noch Payment durchführen und so weiter und so fort. Ihr seht also, das ist eine Reise, die der Benutzer da macht und die geht eben relativ sequenziell. Was ich auch sagen kann, das muss man nicht zu sklavisch machen, diese User Tests. Es ist vollkommen klar, dass bestimmte Benutzer vielleicht bestimmte User Tests überspringen oder dass da eine Weiche drin ist. Wir haben dann aber eben eine grobe Orientierung darüber, was sage ich mal im Durchschnitt ein Benutzer so macht. Da schreibt ihr euch jeweils diese einzelnen Schritte dann auf ein Post-It und klebt die schon mal ans Whiteboard. Im nächsten Schritt versuchen wir dann diese User Tests zu gruppieren und zwar nach sogenannten Aktivitäten. Also in unserem Beispiel könnte das so was sein wie Suchen, Details ansehen und kaufen. Das heißt, wir haben dann unsere User Tests nochmal nach gröberen Aktivitäten gruppiert. Im letzten Schritt füllen wir jetzt weitere Karten. Das werden die sogenannten Sub-Tests sein. Leider sind die Worte da nicht so trennschaft. Wir kennen eben zum Beispiel aus Jira ja auch Sub-Tests. Das hat damit jetzt überhaupt nichts zu tun. Wir zerlegen jetzt jeden einzelnen Schritt der User Tests in ganz, ganz kleine Happen. Also nehmen wir ruhig diesen ersten Schritt, den wir vorhin hatten. Der User sucht jetzt nach dem Buch und dann schreiben wir uns alle kleinen Schritte auf, die ein Benutzer dafür tut. Also er gibt einen Begriff in ein Suchfeld ein. Wir haben in dem Suchfeld noch eine automatische Vorschlagsfunktion. Er klickt auf einen Suchtreffer bzw. davor hätten wir noch, wir zeigen einen Suchergebnis an. In dem Suchergebnis zeigen wir die Anzahl der Treffer. Wir zeigen ein Bild von dem Buch, wir zeigen ein Titel von dem Buch, wir zeigen eine Beschreibung, wir zeigen den Preis. Ihr seht, das wollen wir so detailliert wie möglich machen. Also das sollen wirklich kleine Schritte sein und das tun wir eben für all die User Tests. Also wir würden dann auch beschreiben, was muss man alles tun, um ein Buch dann in den Warenkorb zu legen. Da muss ein Knopf sein. Ich brauche ein Warenkorb Icon. Das muss ich aktualisieren. Da muss eine neue Nummer dran. Es sind jetzt zwei Elementen im Warenkorb. Ich muss auf das Icon klicken können, um zum Warenkorb zu kommen und so weiter und so fort. Also wir zahacken uns das jetzt in ganz ganz viele kleine Tests. Du findest übrigens ein Link zu einem Artikel, den ich geschrieben habe in den Schoenots und da gibt es auch jeweils Schaubilder. Das heißt also, wenn dich das im Detail interessiert, klick gerne in den Schoenots auf den Link zum Artikel und dann siehst du Schaubilder dazu zu dem, was ich gerade beschreibe. Was haben wir jetzt im User Story Mapping? Wir haben auf dem Wideboard viele Post-Its. Die haben wahrscheinlich unterschiedliche Farben. Wir haben eine grobe Gruppierung. Das sind die Aktivitäten. Darunter eine etwas feinere Gliederung, die sogenannten User Tests und je User Tests, jetzt ganz viele Post-Its, die die kleinen Aktionen so detailliert wie möglich oder so kleinteilig wie möglich beschreiben. Was wir im letzten Schritt jetzt noch machen, ist, wir nehmen uns diese ganz kleinen Sub-Tests und bringen die noch in eine Reihenfolge. Wir nehmen also jedes einzelne Post-Its und überlegen uns, was ist jetzt wichtiger? Ist es, dass ein Benutzer eine Suche eingeben kann oder ist es wichtiger, dass er ein Bild im Treffer sieht? Wahrscheinlich würden wir alle sagen, okay, der erste Mal muss der Benutzer ein Suchbegriff eingeben. Ein Bild im Suchtreffer ist noch nicht so wichtig, ein Text im Suchtreffer, also der Titel des Buchs, das wäre noch wichtig. Und so bilden wir jetzt zwischen all diesen Sub-Tests sogar noch eine Reihenfolge. Gut, damit haben wir die Frage beantwortet, was genau ist das Projekt zum heutigen Zeitpunkt? Wir sehen es jetzt tatsächlich eben an dem Wideboard durch alle unsere Post-Its repräsentiert. Im nächsten Schritt geht es jetzt darum, die Frage zu beantworten, wann ist das Projekt fertig? Dafür wenden wir eine weitere Methodik an, die basiert jetzt auf diesem User-Story-Mapping, was wir da gemacht haben. Diese Methodik nennt sich Dimensional Planning. Wie gesagt, wir haben jetzt ein großes Wideboard für uns mit vielen Post-Its und wir haben sogar schon die einzelnen Sub-Tests in eine Reihenfolge gebracht. Und was wir jetzt machen ist Folgendes. Wir nehmen von den Sub-Tests so wenig wie irgendwie möglich und sagen, diese Summe der Sub-Tests bilden die Version 1 und das tun wir horizontal. Also über all die Aktivitäten, die ein Benutzer auf seiner Reise macht. Warum machen wir das horizontal? Im Agil-Manifest steht, wir wollen funktionierende Software liefern, das steht da nicht so explizit, aber das ist eine grundsätzliche Aussage dahinter. Wir wollen einen Wert liefern. Und diese erste Version, die wir dem Kunden liefern, die soll funktionieren, die soll benutzbar sein. Ich hatte letztens so eine kleine Unterhaltung zu dem Thema MVP und das klingt auch ein bisschen nach MVP. Allerdings gefällt mir MVP deswegen nicht, weil wir eine Version 2, eine Version 3, eine Version 4 und so weiter und sofort noch haben. Und es wäre komisch jetzt, dass MVP 2, MVP 3 zu nennen. Deswegen bin ich eher dafür zu sagen, okay, wir haben eine erste Version, die ist in sich geschlossen, sie funktioniert, sie ist benutzbar und sie schafft einen Wert. Und diese erste Version soll so klein wie nur irgendwie möglich sein. Also nehmen wir unser Buchbeispiel, was ist die minimalste Version, die funktioniert. Der Benutzer muss suchen können und wir zeigen im Suchergebnis nur den Titel von einem Buch und der Benutzer kann nur eine Sache direkt im Suchergebnis kaufen. Es gibt kein Warenkorb und nichts. Das klingt jetzt erst einmal nach viel zu wenig und das ist auch viel zu wenig. Aber der große Vorteil ist, das können wir wirklich in Produktion bringen. Das können wir wirklich live schalten und Ergebnisse sammeln. Weil genau das wollen wir in der Agilität. Wir wollen mit dieser ersten Version Ergebnisse sammeln. Wir wollen Kundenfeedback einsammeln. Wir wollen Feedback von unseren Kunden einsammeln. Wir wollen aufgrund von Analytics Daten Feedback einsammeln. Wir wollen wissen, was funktioniert und was fehlt. Das ist die Version 1, was wir auch in einem Dimensional Planning machen. Wir nehmen die weiteren Post-its, die wir haben und ordnen wieder horizontal aus jeder einzelnen Aktivität. Post-its zu der Version 2. Man darf übrigens auch Aktivitäten auslassen. Also Warenkorb war ja jetzt vorhin eine und ich habe gesagt in der Version 1 haben wir kein Warenkorb, sondern wir bestellen direkt aus dem Suchergebnis. Und das macht man halt, bis man möglichst viele kleine Version hat und alle Post-its aufgeteilt hat. Wir wissen aber auch, dass es unklar ist, ob die Version 2, so wie wir sie uns heute überlegen, so wirklich die Version 2 ist, wenn die Version 1 in Produktion ist. Denn wir wollen, wie gesagt, die Ergebnisse einfließen lassen. Das heißt, in dieser Übersicht Dimensional Planning ändern wir auch permanent Dinge wie Verschiebenkarten von der Version 2, die Version 3. Vielleicht gibt es sogar neue Karten, die wir schreiben, weil wir feststellen, daran hatten wir bei der ersten Planung gar nicht gedacht. Und so entsteht dann eine Version 2, die wir liefern können, die wieder ein Feedback-Zyklus auslöst und Einfluss auf die Version 3 und die Version 4 hat. Und so geht das Spiel immer weiter, um jetzt zu der ursprünglichen Frage zurückzukommen. "Wann ist das Projekt fertig?" Die Frage können wir anders formulieren. Wir können nämlich ganz konkret beantworten, wann ist die Version 1 fertig? Denn das können wir planen. Wir wissen aus Erfahrungen, aus anderen Messmethoden. Da könnt ihr anwenden, was ihr wollt. Ungefähr, das dauert jetzt zwei Kalenderwochen. Und das kann man tatsächlich mit einem Kunden besprechen und das kann man auch planen. Wir wissen aber auch, und wenn wir den Kunden da permanent involvieren in diese Diskussion, dass wir nicht wissen, wann Version 3 fertig ist, wir können das nicht wissen, weil wir gar nicht wissen, was wirklich in Version 3 drin sein wird, wenn wir Version 3 anfangen, aufgrund des Feedback-Zyklus. Und da seht ihr eben auch, dass ein Feedback-Zyklus total Sinn macht und es eben überhaupt keinen Sinn macht, Pflichten und Lastenheft zu haben. Okay, vielleicht nochmal zum Abschluss eine kurze Zusammenfassung. Die Frage, die immer wieder kommt, ganz natürlich kommt, ist, okay, wann ist das Projekt denn fertig? Und wir wollen das Agil planen und wir wollen die Frage Agil beantworten. Wir haben dann gelernt, okay, wir müssen mal überlegen, was ist denn genau das Projekt? Und haben festgestellt, zum heutigen Zeitpunkt könnte man das Projekt benennen. Wir wissen aber auch, dass wir eigentlich Feedback-Zyklen brauchen und wir wissen auch, dass das, was wir heute denken, was das Projekt ist, dass das in vier Wochen, in zwei Monaten, in fünf Monaten nicht mehr das Projekt ist. Und die Frage, wann ist das Projekt fertig, können wir aus einem inlichen Grund nicht beantworten. Wir können, aber mit zwei Methodiken, die grundsätzlich dahinter liegende Frage beantworten. Wir machen uns einen Überblick mit der Methodik User Story Mapping, was ist nach heutigen Wissen alles Gegenstand von dem Projekt und nutzen dann eine zweite Methodik, dimensional planning, um Schluss endlich Versionen zu bauen, um dann festzulegen, diese Version ist die erste, wir haben ein Feedback-Zyklus, und dieser Feedback-Zyklus hat Einfluss auf die nächsten Version. Und für eine Version, für die erste Version, wenn wir ganz am Anfang stehen, können wir auch einen Zeitplan nennen. Das Ganze basiert grundsätzlich auf dem Agil Manifest und die zwölf Agilen Prinzipien. Das hat nichts mit Iteration oder Sprint aus Scrum zum Beispiel zu tun. Eine Version 1 kann 2 Sprints sein, kann halber Sprint sein, kann 3 Sprints sein, das hat mit Sprints und Inter-Iteration überhaupt nichts zu tun. Es geht um eine Version und diese Version soll so klein wie möglich sein und wir wollen sie liefern. Vielleicht nochmal kurz an die Scrum-Leute an dieser Stelle. Wenn eurer Sprint relativ lang ist, also vielleicht sogar vier Wochen, dann werdet ihr höchstwahrscheinlich feststellen, dass das, was ich hier unter einer Version verstehe, schneller als ein Sprint ist. Und dann macht diese ganze Scrum-Logik an der Stelle einfach überhaupt keinen Sinn. Zum Agil Manifest und den zwölf Agilen Prinzipien. Hier nochmal der Hinweis, den Agilomaten hatte ich erwähnt. Es gibt das Agil Manifest, die vier Punkte und die zwölf Agilen Prinzipien. Als Spielkarten, die habe ich mal gemacht, auch dazu findest du einen Link in den Schonus, die kannst du bestellen in einem Shop. Da geht es mir nicht um Geld verdienen, sondern ich finde, es ist schön, die auch haptisch vor sich zu haben, um mit dem Team zum Beispiel dran zu arbeiten. Wie gesagt, die Spielkarten, da packe ich auch noch mal einen Link in die Schonus. Ja, ansonsten freue ich mich wie immer über Feedback. Du erreichst mich zum Beispiel per Mail unter nobs@gmail.com. Alternativ kannst du mich gerne auf Mastodon anquatschen. Den Link zu meinem Mastodon Profil, den findest du auch in den Schonus. Und es gibt ja einen Forum, wo ich mich darüber freue, wenn wir uns zu bestimmten Themen austauschen. Den Link zu dem Forum bzw. zu dem Forum Eintrag für genau diese Folge vom Podcast, den findest du auch in den Schonus. Habt eine ganz tolle Woche und bis zum nächsten Mal. Bye. [Musik] [SLURM]