NBA17: Wer agil ist muss nicht planen?

Hallo und herzlich willkommen bei NoBullshitAdjai. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier 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 dabei auf der Praxis, daher auch der Name NoBullshitAdjai. In der letzten Folge habe ich darüber gesprochen, warum kleine Story Sinn machen. Wenn dich das interessiert, hör gerne rein. Den Link dazu findest du in den Shownutz. Das ist die Folge 17 und heute geht es um eine Aussage, die ich immer mal höre, nämlich wer Agilismus nicht planen. Nach all den Jahren, wo ich mich mit Agilität beschäftige, ist es wirklich merkwürdig so was zu hören. Schlussendlich, und da kommen wir jetzt in der Folge dann Stück für Stück auch hin, bedeutet Agilität permanentes Plan. Also es ist überhaupt nicht so für mich zumindest, dass man befreit ist von der Planung oder nicht planen darf oder nicht planen muss, sondern die Art des Plans ändert sich. Ich frage mich dann immer wieder, woher kommt wohl diese Aussage. Es wäre halt echt interessant, wenn ihr das auch kennt, was ihr wohl glaubt. Und es wäre auch interessant mal zu hören, wenn ihr solche Aussagen auch bekommt, von wem bekommt ihr die. Wenn wir über Agilität reden und darüber, warum wir überhaupt Agil sein wollen, finde ich, ist der Kern des ganzen. Wir erkennen an, dass wir nicht im Luftleeren Raum Projekte machen, sondern einfach in einer Umgebung, in einem Umfeld. Wir haben unsere Kunden, wir haben deren Kunden, wir haben einen Markt, wir haben Technologien, wir haben Feedback. Das ist ja alles etwas, was ich anerkennen will, die Idee zu sagen, okay, wir bauen ein Schiff, so ein schönes Beispiel aus der klassischen Projektwelt und wir definieren einfach, wie groß das Schiff ist und welche Leistung es bringen soll und was es transportieren soll. Und dann können wir mit diesen Daten den Bau dieses Schiffes einfach komplett durchplanen. Der mag für so ein Schiff ja stimmen. Aber für das, was wir tun oder vor allen Dingen für den Grund, warum wir sagen, so können wir Projekte nicht machen, wir müssen was anderes finden, nämlich die Agilität, funktioniert das ja überhaupt nicht. Und Kern des ganzen ist eben, dass wir Umwelteinflüsse berücksichtigen wollen. Also was ist ein Umwelteinfluss? Naja, wir denken uns sicherlich an dem Anfang von einem Projekt etwas aus und sagen, wir wollen folgendes Ziel erreichen oder damit folgendes Problem beheben. Und das ist auch gut und richtig. Das ist schon der erste Teil des Plans. Wir wollen und müssen wissen, was sind die Anforderungen. Deswegen schreiben wir dann ja auch Stories. Wir wissen aber auch, dass wir jetzt nicht sechs Monate daran arbeiten, es dem Kunden in die Hand geben, der benutzt ist und es ist alles so, wie er es sich gedacht hat oder wie es der Markt jetzt erfordert. Wenn Leute dem widersprechen, dann würde ich immer dazu tendieren, rückzufragen, ob denn in solchen Situationen Agilität überhaupt nötig ist. Wenn man mal davon ausgeht, dass man so ein Umfeld hat, in so einem Umfeld lebt, dann ist sofort klar, wie man planen muss. Und man muss in kleinen Schritten planen und man muss Feedbackzyklen haben. Genau das ist das, was mir hilft, so ein Projekt erfolgreich zu machen. Das heißt aber auch, ich kann nicht zum Start von einem Projekt einen großen Plan erstellen und denken, ich kann diesem Plan verfolgen und werde dann wirklich das erreichen, was nötig ist. Und deswegen kommt wahrscheinlich so ein bisschen dieses Gerücht auf. Gut, wenn man Agile-Projekte macht, brauchen wir gar nicht erst zu planen. Dieses Argument oder dieses Gerücht ist aus mehreren Gründen schlecht. Also wenn ich neue Kunden habe oder neue Ansprechpartner bei Kunden und wir uns über das Thema Projektplan unterhalten, ist es mein Auftrag mit dem Kunden auch, ja ich sage mal so eine Einführung in Agilität zu machen, ihn wirklich dazu edukaten, wie das schöne dängliche Wort dann ist, um ihm zu erklären, was denn planen jetzt wirklich bedeutet und wie wir planen. Und ich erkläre dann eben, dass wir permanent planen, dass es halt Nachteile gibt, einfach zu sagen, okay, das ist das Projekt. Wir rechnen jetzt aufgrund von irgendwelchen Erfahrungen oder Werten in einem Tool jetzt ein Zeitplan aus und sagen, okay, und dann liefern wir das und das wird genau das tun, was du möchtest. Das wird es höchstwahrscheinlich, aber es ist halt dann eben auch so, dass es passieren kann, dass wir zwar das liefern, was der Kunde möchte, aber nicht das, was er braucht. Und in diesem Gespräch mit dem Kunden kommt immer wieder diese Angst, also es ist vielleicht ein bisschen dramatisch formuliert, aus Kunden sich dazu, ja, aber Agil und dann haben wir gar keinen Plan und dann ist es halt tatsächlich mein Auftrag, dem Kunden zu erklären, wie man denn in der Agilität plant. Steht übrigens auch im Agil Manifest, da steht halt ganz explizit, reagieren auf Veränderungen mehr als befolgen eines Plans. Das heißt, das Fundament, an dem wir uns ja eigentlich alle orientieren, ob wir jetzt Scrum machen, kann man XP, ein Mischmarsch aus diesen Motoden, es sollte ja immer das Agil Manifest die Basis sein für unsere Entscheidung, ist es sogar schon festgehalten, dass wir eben auf Veränderungen reagieren wollen und nicht ein einmal aufgestellten Plan befolgen. Da steht aber auch nicht, macht keinen Plan. Es gibt ein schönes Zitat, das wird Eisenhower zugesagt, ob das wirklich so ist, wie das mit Zitaten immer ist, keine Ahnung, aber das Zitat an sich ist trotzdem schön. Zitat lautet "Plans are worthless, planning is everything". Und das wäre tatsächlich mein Tipp und so würde ich auch immer vorgehen, das Plan hat an sich ein Riesenwert und das permanente Plan sich immer wieder damit beschäftigen, was ist jetzt als nächstes, wo wir heute dastehen, der nächste sinnvolle Schritt, was ist, die nächste Story, passt diese Story noch, müssen wir die anpassen, weil die Anforderung sich verändert hat. Das schafft unheimlich viel Wert, wir steigen immer tiefer in das Projekt ein und das wollen wir einfließen lassen. Also auch Eisenhower sagt in seinem Zitat "Halt nicht an dem Plan fest, der hat keinen Wert, aber nutze das Plan, das schafft einen Wert". Wie auch immer, ihr für euch in eurer Situation an das Thema Plan dran geht. Mein großer Tipp ist, plant ein, dass ihr auf Veränderungen reagieren wollt und müsst. Veränderungen sind wichtig und wir wollen die einfließen lassen. Jeden Feedback-Zyklus, den wir einbauen, bauen wir ein, um einen Feedback zu bekommen und wenn wir einen Feedback bekommen und das nicht nutzen, dann brauchen wir das Feedback gar nicht erst einsammeln und wenn wir keinen Feedback einsammeln, liefern wir etwas, das entspricht dann vielleicht dem, was auf dem Papier steht und ihr könnt euch damit mit dem Kunden in einem Change-Prozess darüber streiten, ob das jetzt Anforderung war oder nicht, aber es entspricht eben wirklich nicht dem, was schlussendlich dem Kunden ein Wertschafft, was am Markt besteht. Steht natürlich eine ganz große Frage im Raum, ich habe die vorhin schon mal kurz angedeutet, wenn ich denn keinen klassischen Projektplan aufstellen kann und das können wir nicht sehen, das was ich gerade alles erzählt habe, wie kommt man dann zu Deadlines, wie kann ich dem Kunden sagen, ab dann und dann kannst du das, was du hier beauftragt hast, nutzen, denn die Frage stellt der Kunde und das ist auch vollkommen berechtigt, dass der Kunde diese Frage stellt und die Antwort liegt an einer ein bisschen anderen Ecke. Ich habe dazu tatsächlich eine Folge aufgenommen, das ist die Folge 13, Agile Projektplanung, ich fasse das hier aber gerne nochmal kurz zusammen. Die grundsätzliche Idee muss sein, alle Anforderungen, so gut es eben geht, zu sammeln und gemeinsam mit dem Kunden zu schauen, was sind die ersten Elemente, ich sage jetzt mal die ersten Stories, die einen Wert schaffen. Das muss nicht sein, was sind die kleinsten, das können auch komplizierte Dinge sein, die Frage ist tatsächlich, was sind die ersten Dinge, die wir liefern können und diese ersten Dinge wollen wir auch liefern, so schnell es geht. Das braucht Erfahrung, um die herauszuwählen, das ist nichts, was man einfach so sich aus der Hand schüttelt, aber wenn man die Erfahrung hat und der Kunde da auch mitmacht und der Kunde auch den Mehrwert an diesem Vorgehen sieht, dann kann man diese erste Version nenn ich es mal, die aus drei Stories besteht oder fünf liefern und dann den Feedback-Zyklus starten und ich kann für diese ersten Stories eine Deadline nennen, ich kann für diese ersten Stories für diese eine Version ein Angebot machen und dann ist man an der Stelle, dass man das, was der Kunde sich wünscht, ich brauche eine Deadline und ja vielleicht sogar ein Preis, einen Riesenschritt weiter, wenn der Kunde versteht, dass er einen Mehrwert daraus hat, dass er dann die Chance hat die nächsten Schritte im Projekt nochmal neu zu definieren, aufgrund des Feedbacks zum Beispiel und aufgrund der Erfahrung, die wir alle in diesem Projekt machen, habe ich die Erfahrung gemacht, dass Kunden sagen, okay das ist schlau, lass uns das gerne mal machen. Detail ist dazu, wie macht man denn zusammen mit dem Kunden so eine Planung, wie gesagt sind in der Folge 13 von mir besprochen, die Stichworte sind der User Story Mapping und Dimensional Planning. Du kannst dir ja mal deine letzten Projekte, die fertig sind, anschauen und mal gucken, ob es da Funktionen gibt, die du geliefert hast und die der Kunde dann höchstwahrscheinlich auch abgenommen hat, die eigentlich vom Kunden gar nicht benutzt sind. Und das zweite was du mal machen kannst, ist schau dir mal deine fertigen Projekte an, wie viel Changes waren denn dann, wie viel Vertragsänderungen gab es denn noch, weil der Kunde gesagt hat, oh ja stimmt, hatte ich eigentlich so definiert, aber jetzt wo ich sehe und wo ich es benutze, macht es eigentlich Sinn, das anders zu machen. Und meine Erfahrung nach ist es dann tatsächlich so, dass es echt viele, viele Dinge gibt, wo ich sage, okay das hätte man, wenn man das Projekt Agila gemacht hätte, verhindern können, das hätte man kostengünstiger machen können. Ich kenne wirklich Projekte, wo Funktionen dann einfach später auch gar nicht benutzt sind, die haben wir dann entwickelt, das ist nicht so, dass dem Kunden das verheimliche, aber der Kunde selber sagt dann auch, okay also diese Funktionalität, die wird jetzt gar nicht benutzt oder ich brauche die doch nicht, hätte eigentlich was anderes gebrauchen können. Also das kann man wirklich ganz, ganz oft sehen und mit so einer Agilenplanung und dem planvollen Vorgehen hätte man die gar nicht erst entwickelt, das wäre halt kein Waste entstanden. Es ist halt auch so, dass ein Projekt eigentlich nie fertig ist. Ich habe mal so ein Zitat gesehen irgendwo im Internet, ich weiß gar nicht mehr wo, aber ein Projekt sagt dann jemand halt, ist erst für ihn dann fertig, wenn es begraben wird und da stimmt ja auch, eigentlich wollen wir auch permanent weiter dran arbeiten. Für Abschnitte kann ich natürlich definieren, wann soll ein Abschnitt fertig sein, aber das gesamte Projekt ist ja erst dann fertig, wenn man es einstampft, weil der Lebenszyklus zum Beispiel einfach erreicht ist, es ersetzt wird durch was anderes so oder so. Ja, das heißt also kleine Zusammenfassung, für mich in der Praxis Schlussendlich Agilität bedeutet ganz viel Plan, also überhaupt nicht irgendwas von wegen, wenn man Agileprojekte macht, dann muss man auch nicht planen. Also ich kann jedem Kunden da auch die Angst nehmen, wenn der Agentur Projekte Agil macht und das vernünftig macht, wird die Agentur permanent planen, gemeinsam mit dem Kunden. Das geht gar nicht anders. Das heißt also dieser Mythos ist in meinen Augen einfach wirklich ein absoluter Mythos. Wir planen eigentlich viel mehr als man das in einem klassischen Projekt jemals tut, im klassischen Projekt plan ich ganz am Anfang und dann muss ich vielleicht bestimmte Dinge noch mal anpassen, aber ich halte einmal den Plan fest und das ist halt gar nicht Agil und Agil ist permanent zu planen. Ja, ich denke damit sind wir dann für heute auch durch. Wie immer interessiert mich deine Meinung zu dem Thema oder welche Erfahrung du gemacht hast, deswegen gibt mir gerne Feedback. Dazu kannst du mich zum Beispiel per Mail erreichen unter nobias@gmail.com oder du findest mich auch auf Mastodon und es gibt Begleitungen zu der Webseite und dem Podcast auch im Forum. Alle Links, wie immer findest du in den Schonuts. Habt noch eine ganz tolle Woche und bis zum nächsten Mal. [Musik] [Musik] [Abspann]