Hallo, willkommen. Heute wollen wir uns doch nochmal mit Projektmanagement beschäftigen. Einfach weil wir relativ Feedback kriegen zu diesem Thema und weil wir auch immer wieder sehen, wie seltsam das Thema in Unternehmen angegangen wird. Es ist unleugbar, dass eigentlich. Agilität, agiler Ansatz, agiles Projektmanagement heute fast schon der Default. Das ist quasi eine Haltung in Unternehmen. Wer agil arbeitet, gilt als Modern. Wer nicht agil arbeitet, muss sich immer rechtfertigen. Oder zumindest wer nichts sagt, er arbeitet. Ob das denn real agil ist, werden wir später erklären. Wasserfall oder Spezifikation oder Lastenheft, sogar die Wörter, die wir heute fast gar nicht mehr hören, das klingt nach den 90er Jahren nach PowerPoint und Oldschool. Wir wollen uns heute die Frage stellen, gibt es Projekte, bei denen agil nicht die bessere Wahl ist, gibt es Projekte, bei denen vielleicht Wasserfall besser funktioniert und wie kann man solche Projekte erkennen? Und was letzten Endes kann falsch verstandene Agilität anrichten. Und Woogle merkt, wir wollen nicht irgendwie das Prinzip agiler Entwicklung oder Scrum oder Kanban oder irgendein ganz spezifisches Framework hier irgendwie schlechtreden, sondern wir wollen einfach. objektiv drauf schauen, wann funktioniert was und was für Vorteile kann man vielleicht auch von hybriden Ansätzen gewinnen. Aus der Perspektive von dem Manager kennt jeder die Situation, Projekte, die agil starten, aber das Budget explodiert trotzdem. Obwohl man irgendwann eingeredet bekommen hat, Agile ist ein schlanker Ansatz. Oft werden Deadlines verschoben, weil man halt doch irgendwie mit Deadlines arbeiten muss, was mit Agil nicht so wahnsinnig toll kompatibel ist. Und der Return on Investment bleibt sowieso unklar. Und letzten Endes wollen wir darauf hinaus, dass Entscheidungsträger immer abwägen müssen, was ist meine Ausgangssituation, was ist mein Mein Projekt-Setup, was ist auch meine Kultur im Unternehmen? Darüber haben wir auch schon mal eine Podcast-Episode gemacht, wie viel wichtiger Kultur ist eigentlich als der konkrete Projektmanagement-Ansatz. Und will ich zum Beispiel sowas wie. Schnelligkeit oder mehr Vorhersehbarkeit? Will ich Flexibilität oder will ich eine bestimmte Compliance quasi mit Regularien erreichen mit meinem Softwareprojekt? Das heißt, letzten Endes das Ziel dieser Episode ist, euch zu helfen, dass man eine Methodenwahl nicht nach einem Trend oder nach einem vielleicht empfundenen Druck jetzt besonders modern zu sein trifft, sondern nach dem echten Businessbedarf. Fangen wir an mit einer kleinen Begriffsklärung. Agil, was heißt eigentlich agil? Beginnen wir mal so, was heißt agil nicht? Agil heißt auf keinen Fall, dass man keinen Plan macht. Agile Projektpläne sehen nur einfach anders aus. Agile Projektpläne arbeiten nicht mit definierten Time-Programmen. Frames, weil die sowieso sehr oft nicht stimmen oder am Ende dann sich verschieben und man sehr viel Verwaltungsaufwand damit hat, sondern mit anderen Strukturierungsformen Agiles Projektmanagement heißt nicht, dass keine Dokumentationen geschrieben werden. Und agiles Projektmanagement heißt auch nicht, dass man nicht. die Notwendigkeit hat, Entscheidungen zu treffen. Im Gegenteil in agilen Projekten behaupte ich, und das ist vielleicht eine der ersten wichtigen Takeaways, in agilen Projekten brauche ich eine viel sauberere Entscheidungfindungsprozedur. Ich brauche viel entscheidungsfreudigere Menschen und auch Rollen, die viel mehr berechtigt sind, echte Entscheidungen zu treffen. Agilität. eine echte Agilität, ein echtes agiles Projektmanagement, erfordert total messerschaft definierte Rollen, erfordert eine sehr, sehr Präzise Priorisierung, weil im Gegensatz zu einem klassischen Projektmanagement mir ja gar nicht klar ist von vornherein, was ich alles umsetze.

hey, ich bin. beginne mit den Items, die die höchste Prio haben, die meinen höchsten Business Impact haben, vielleicht den besten Einfluss auf den ROI. Mit denen beginne ich und dann arbeite ich mich so das Backlog runter. Das ist schön, das kann man in einem Wasserfallprojekt nicht so machen, da wird mehr nach Architekturen und Strukturen gruppiert. Aber das bedeutet auf der anderen Seite auch, ich muss diese Priorisierung vornehmen. Viele agile Projekte haben einen Backlog.

ja, wir müssen ja eh alles umsetzen. Im Prinzip ist es schon dann kein agiles Projekt mehr. Agil heißt auch, dass der Scope flexibel gemanagt werden kann. Agilität verlangt enorm viel Abstimmung, und zwar Abschnitt. Stimmung zu Zeitpunkten, wo wir sie vielleicht nicht erwarten. Wenn ich mit einem Wasserfallprojekt arbeite, nochmal kurz für die Erinnerung, was bedeutet das? Das bedeutet ich Definiere erst, was mein Produkt können soll, dann setze ich es um, dann teste ich es, dann bring ich es live im Groben, sozusagen. Also wie die Phasen genau aussehen. Da kann man unterschiedliche Ansätze wählen. Man kann auch natürlich Phasen immer wieder neu durchlaufen. Aber im Wesentlichen ist die Idee eines nicht agierten Projekts, eines Wasserfallprojekts, dass ich meine Definition vorab mache. Wenn ich mich jetzt entscheide, agil zu arbeiten, dann heißt das, ich mache die Definition nur so weit, wie ich sie eigentlich für den nächsten Entwicklungszeitraum brauche und dann arbeite ich da quasi hinterher. Das heißt aber auch, und das muss man sich bewusst machen, In einem agilen Projekt muss ich zum Beispiel Abstimmungen mit Rechtsabteilungen oder was auch immer die langsamsten Teilnehmer in so einem Projekt sind, muss ich dann machen, wenn ich. quasi in die Richtung von diesem entsprechenden Feature komme. Wann das ist, weiß ich oft gar nicht. Und Rechtsabteilungen sind oft nicht flexibel genug, dass ich sage, hey, in meinem aktuellen Sprint muss ich quasi meinem keine Ahnung, meine Löschfunktion umsetzen, könnt ihr mir das mal schnell prüfen für mich. So funktioniert das normalerweise nicht, sodass ich in einem agil geführten Projekt mit sehr komplexem Environment oft Dinge.. verschieben dadurch, dass die externen Zulieferungen nicht passen. Wenn man die hohe Disziplin hat, ein Projekt agil zu führen, hat man auch extreme Benefits Wenn man diese Disziplin in der Organisation vielleicht gar nicht aufbringen kann, weil man A die Rollen nicht besetzt hat, in den Zulieferungsstrukturen so arbeiten kann, dann ist diese Pseudo-Agilität, die vielleicht damit chaotisch besser umschrieben ist, oft ein wirklich harter Nachteil. Diese Fehlerinterpretation des agil und chaotisch letztendlich es gleich ist oder agil und unstrukturiert oder wie auch immer, die führt manchmal zu scheinbarer Produktivität, weil man am Anfang bewegt sich sehr, sehr viel und huh, ich kann meine Software schon testen und sie hat schon drei Features und die drei Features deployen wir direkt, weil wir sind ja agil. Aber real kommt es eher zu einem Wertverlust, weil ich Downstream sozusagen nicht die Organisation zur Verfügung habe, die mit einem agilen Projekt wirklich hohe Qualität liefern kann. Das heißt, auch aus der Perspektive von einem Project Owner und einem Project Sponsor muss geprüft werden, liegt hier echte Transparenz vor, weil ich eben jetzt die App schon mal in der Hand habe oder weil ich mein Produkt im Web schon mal anschauen kann. Oder habe ich eigentlich das Problem, dass ich überhaupt nicht weiß, wo ich lande, wo ich Downstream hinkomme, welche Qualität ich wirklich erreichen werde und am Ende wird vielleicht Geld verbrannt unter das messbare Auto? Output entsteht. Wohlgemerkt, ein korrekt geführtes Agiles Projekt hat dieses Problem nicht. Aber viele Leute machen sich wirklich gar nicht bewusst, wie schwierig es ist, ein Projekt korrekt agil zu führen und bevor ich es chaotisch führe, also pseudoagil, führe ich es lieber als Wasserfall. Ist meine persönliche Meinung. So, was sind typische Symptome, dass agil falsch verstanden wird oder falsch umgesetzt oder Dass letzten Endes agil als Lösung für Probleme gesehen wird, die es gar nicht lösen kann. Auf der Business-Ebene letzten Endes sehe ich oft in subseudo-agilen Projekten, dass es keine klaren Requirements gibt. Weil man keinen keine Person hatte, die Requirements Engineering ausreichend beherrscht, weil man vielleicht ab front gar nicht weiß, was man genau umsetzen will, was weil man vielleicht gar nicht genau klären konnte, was realistisch ist oder was compliant wäre an Features in dem Produkt. Das heißt, wir beginnen in so einem Projekt ohne klare Requirements und das ist eben nicht agil. Das ist chaotisch. Aber es wird oft so verstanden, als wäre agil eine Lösung dafür, dass ich ein Projekt ohne Requirements schon mal starten kann und dann später mich schon selber einhole im Projektverlauf. funktioniert fast nie. Der einzige Effekt, den das hat, ist, dass Budget und Zeitplan natürlich völlig unvorhersehbar werden in so einem Setting. Wenn ich nicht von vornherein weiß, worauf ich eigentlich hinaus will, kann ich auch nicht wirklich abschätzen, wenn ich damit fertig bin. Gleichzeitig ist es aber so. dass ja in, sagen wir mal, traditionelleren Firmen, also jetzt nicht im hippen Startup, aber in mittelständischen Firmen dennoch von allen Seiten gefordert wird, dass Budget und Zeitplan klar sind. Das kann man machen. Man kann sagen, ich mache ein agiles Projekt, ich fixiere Budget und Zeitplan, also Deadline quasi. Ist auch oft das gleiche, weil ich ein Team habe, das über den Zeitraum einen gewissen gewisse Kosten nach sich ziehen, aber gerade dann brauche ich sehr, sehr klar formulierte Requirements, auch damit ich weiß, was ich weglassen kann. Zweite Symptom oder zweite Smell quasi für falsche, agile Projekte oder falsch verstandene Agilität ist, dass es keinen dedizierten Product Owner gibt. Ein Product Owner Ist eine der Kernvoraussetzungen für Agilität. Der Product Owner ist letzten Endes in jedem agilen Projekt, sei das Kanban, sei das Scrum, Die Person, die berechtigt ist, Produktentscheidungen zu treffen. In einem nicht-agilen Projekt, in einem Wasserfallprojekt, wo ich eine Spezifikationen schreibe, da kann ich vorher, bevor ich beginne, das umzusetzen, mich per Komitee oder Arbeitskreis oder wie auch immer die Strukturen in der Firma jeweils heißen mögen, Mich Hinsetzung tatsächlich ein Produktkonzept abstimmen in jede Richtung. Ich kann alle Beteiligten fragen, ich kann mir vom Boss quasi die Unterschrift holen, dass das genau das Produkt ist, das wir bauen wollen. In einem agilen Projekt kann ich das so nicht machen. Wenn ein Product Owner nicht berechtigt ist, Produktentscheidungen zu treffen, sondern von Ponsos CP Latus laufen muss und alle Stakeholder quasi jede kleine Entscheidung unterschreiben müssen, dann ist er kein Product Owner. Dann owned er gar nichts, dann ist er ein glorifizierter Sekretär. Also Product Owner dürfen nicht nur so heißen, sondern sie müssen notwendigerweise die Verantwortung und auch die Entscheidungsbefugnis haben, das Projekt zu steuern, Software zu Features zu streichen, zu definieren, umzusetzen. Klar werden sie für die großen Entscheidungen entsprechende Stakeholders hinzuziehen. Aber es ist unmöglich, dass alles eskaliert auf die Führungsebene und die Verantwortung unklar bleibt. Der Product Owner muss da sein, sonst ist es auch kein agiles Projekt. Dann nennen wir es agil, aber dann ist es nur chaotisch. Was auch oft vergessen wird und wofür auch der Product Autonomi zuständig ist, ist tatsächlich die Produktvision. Das heißt, nicht irgendwie ein fuzzy Feeling, was quasi... wie viel besser die Menschheit werden soll durch unser Softwareprodukt, sondern eine wirkliche Big-Picture-Vision, was wollen wir mit dem Produkt erreichen am Ende. Und welchen Business Value oder welchen Geschäftszielen soll sich dieses Produkt quasi unterordnen. Das ist auch eine wichtige Leitlinie dafür, wonach der Product Owner dann seine Entscheidungen treffen will. Es ist ein Riesenunterschied, ob ich sage, ich mache ein Produkt, das sich an Zielgruppe A oder Zielgruppe B richtet, junge Menschen oder alte Leute. Es ist ein Riesenunterschied, ob ich sage, ich möchte mit diesem Produkt primär Leute quasi in meinen Store funneln oder was auch immer oder ich möchte mit diesem Produkt individuellen Wert generieren, den Leute vielleicht auch zu bezahlen bereit sind. Ich brauche eine Produktvision, die zumindest mal Zielgruppe, Kernidee und Geschäftsziele enthält, damit ich alle Entscheidungen und Ressourcen und Und auch die Entwickler und die anderen am Projekt Beteiligten darauf ausrichten kann Wenn ich keine Produktvision habe, also kein großes, klares Ziel, das ich verfolge, aber auf der anderen Seite habe ich ein Team, das sich selbst steuert, was ja auch ein Anspruch ist von agilen Projekten. Dann werden die notwendigerweise, selbst wenn sie sehr, sehr sorgfältig arbeiten, primär lokal optimieren. Entwicklungsgeschwindigkeit und Qualität, vielleicht, was ja alles gute Dinge sind, aber sie haben eigentlich keine Chance, auf irgendein großes Ziel hinzuarbeiten und vielleicht Entscheidungen zu treffen, die uns ermöglichen, dieses große Ziel früher zu erreichen. Das coolste an ergeilen Projekten, und das kann man gar nicht oft genug sagen, ist die Möglichkeit, die wir Auf der Hälfte zu sagen, oh, wir haben einen viel besseren Weg mit anderen Features oder einem anderen Vorgehen genau dieses gleiche Ziel zu erreichen. Aber schneller mit weniger Kosten. Mit einem klassischen Projekt ist das unmöglich, kann ich auf der Hälfte von einem klassischen Projekt sagen, ich ändere nochmal Fundamentales. Das wird nicht klappen. Mit einem agilen Projekt kann ich das machen und diesen Vorteil muss ich natürlich versuchen zu enden. Dazu brauche ich ein Product-Onnet. Und dazu brauche ich eine Produktvision. Das nächste, was ich persönlich immer unterschätzt habe, ehrlich gesagt in meinen ersten agilen Projekten, ist aber auch schon lange her, ist, dass man keine Agilität erreichen kann, wenn man kein Cross-functional, kein cross-funktionales Team hat. In dem Moment, wo ich Abhängigkeiten habe in meinem Projekt, das heißt, in dem Moment, wo ich auf andere Abteilungen oder Funktionen warten muss, damit ich mit meiner Umsetzung weiterkomme. Bin ich eigentlich schon nicht mehr wirklich agil. Das bedeutet, in einem klassischen Projekt, ich nehme das Thema immer wieder gerne her, weil rechtliche Prüfungen so ein Pain in the ass sind, einem klassischen Projekt mache ich meine Spezifikation. Strukturiere das ordentlich durch und lege die wesentlichen Teile, zum Beispiel eine Rechtsabteilung oder eine externen Kanzlei vor oder was auch immer, zu sagen, hey, ist das Kon. Konform mit den Regelungen, die für meine Industrie gelten, ist das konform mit DSGVO, ist das konform mit allen rechtlichen Vorgaben, die eventuell auf das Projekt Anwendung finden müssen. In einem agilen Projekt, wenn rechtliche Prüfung ein Thema ist, ein kontinuiertes Thema, brauche ich eigentlich in meinem Team einen Juristen. Das ist cross-funktionales Team. Ein cross-funktionales Team heißt nicht einfach nur in meinem Entwicklungsteam ist auch eine. eine kleine QA-Person. Cross-funktionales Team heißt, in diesem Team sind alle Funktionen enthalten, die ich brauche, um das Produkt oder das Projekt in dem Fall erfolgreich umzusetzen. In dem Moment, wo ich auch nur eine Funktion, die ich regelmäßig brauche, nicht im Team habe, muss ich diese Funktion irgendwie anders dazu buchen und habe damit eine externe Abhängigkeit. Ist für ein agiles Projekt eigentlich oft ein Todesstoßen. Weil jetzt habe ich plötzlich einen coolen Ein cooles Backlog. Hab Sprint Velocity Schätzungen zum Beispiel kann Deadlines projizieren. Also Delivery ein Deadlines projizieren und so weiter und so fort. Aber die externen Abhängigkeiten, die ich zusätzlich drin habe, machen das alles obsolet. Ich kann überhaupt nicht sagen, ob ich das Sprint-Ziel erreiche, wenn ich nicht weiß, ob mir die Rechtsabteilung oder die Fachabteilung XYZ Rechtzeitig zuliefert. Wenn ich eine API brauche aus irgendeinem Firmensystem und die API gibt es noch nicht und der die API entwickelt, ist aber nicht Teil von meinem Team, warte ich auf ihn, wie lange auch immer. Und die ganze Illusion, dass man das mit dead Deadlines und Commitments und so weiter lösen könnte in der Firma. Sorry, den Zahn muss ich euch ziehen, habe ich noch nie gesehen. Die meisten Softwareprojekte in Firmen laufen relativ isoliert, die anderen Abteilungen haben Besseres zu tun, haben eigene Zahnen. Ziele und diese ganzen Zulieferungen sind mehr so auf Gnadenbasis und haben deswegen überhaupt keinerlei Committed-Deadlines. Und selbst wenn es committed Deadlines Gibt oder gäbe, könnten die ja immer noch aus Gründen, die vielleicht diese Abteilung gar nicht zu verantworten hat, gerissen werden. Und meine eigene Planbarkeit in meinem Projekt geht vollständig verloren. Also kross-funktionales Team, absolut essentiell, sonst ist es eigentlich kein agiles Projekt. Was ich in agieren Projekten auch trotzdem eigentlich immer erreichen will, ist, ich möchte in der Lage sein, Themen zu bündeln ein bisschen. Also ich möchte zwar meine Features und meine. meine Inkremente, meine Entwicklungsschritte so feingranular wie möglich halten, damit ich immer schön steuern kann und sagen, uh, das Feature gefällt mir gar nicht, das machen wir anders. Großer Vorteil von agilen Projekten. Möchte ich aber trotzdem auch Themen bündeln können. Also ich möchte im Prinzip sagen können, okay, wenn mir jetzt in diesem Sprint das Thema Login oder die Menüstruktur angehen. Dann lass uns mal die Themen, die dazugehören, ein bisschen zusammenbringen, damit wir nicht so viele Konflex.. Kontextwechsel haben. Damit also das Entwicklungsteam nicht fünfmal die gleiche Stelle anfasst und nicht fünfmal über bestimmte Dinge nachdenken muss. Man will ja eigentlich so Kontextwechsel ein bisschen minimieren. Wohlgemerkt unter Berücksichtigung der Priorität, aber nehmen wir mal an, alle diese Sachen haben gleiche Priorität, dann will ich sie eigentlich bündeln. In chaotischen Projekten ist es oft der Fall, dass ich es nicht bündeln kann, weil niemand da war. der tatsächlich in der Lage wäre, jetzt diese ganzen Themen gleichzeitig zu oder rechtzeitig zu definieren. Und dann entwickle ich letzten Endes immer das, was fertig definiert ist, weil ich mit der Definition permanent hinten dran bin. Und das bedingt dann relativ viele Kontextwechsel und macht die Entwicklung langsam. Hört sich jetzt vielleicht sehr abstrakt an, wenn man das mal selber erlebt hat, dass man sagt, wow, ich fasse jetzt das Menü an, ah, da hatte ich noch eine andere Story, die eigentlich gleich wichtig ist, und dann sagt der Produkt, oh naja, da bin ich noch nicht. dazu gekommen, aber ich habe auch keine Ressourcen, weil ich habe noch 50 andere Jobs. Das macht ein Projekt auch ineffizient. Was auch so ein anti-agiles Smell ist, auch sind riesige User-Stories mit zig querverweisen. Also Sehe ich oft das Phänomen, dass User Stories letzten Endes also so eine Art Mini-Spezifikation herhalten müssen, weil eben doch ein Feature vielleicht zu komplex ist oder zu viele Integrationspunkte hat oder zu viele architektonische Implikationen, als dass man es in einer einzelnen User-Story User Story oder in einzelnen isolierten User Stories abbilden kann. Normalerweise versucht man im agilen Projekt, User Stories so weit voneinander zu entkoppeln, wie man nur eben kann. Und oft geht das auch, aber das ist in einer gewissen Weise eine Kunst. Ein Product Owner bzw. ein Team, das das hier gut hinkriegt, User Stories zu isolieren, zu sagen, dieses Feature können wir wirklich völlig isoliert betrachten von diesem Feature, das ist rar und das ist ein wirklich Wichtiger Skill für agile Projekte, der aber oft nicht da ist. Und dann hat man letzten Endes Epics und darunter Stories mit zig querverweisen zu anderen Stories, wo man sagt, okay, und diesen Funktionalität machen wir dort und das machen wir da. Einfach Weil man versucht hat, eine Spezifikation zu schreiben und die auf 20 Storys dann aufzusplitten, damit es nicht wie eine Spezifikation aussieht. Spätestens dann muss man sagen, okay, vielleicht ist meine Kultur, vielleicht ist mein Personal, vielleicht ist mein Projekt-Setup so, dass eine Spezifikation vielleicht wirklich direkt ist Richtige Weg gewesen wäre und diese agile Idee, ich mache quasi grob Strukturierung mit Epics und dann gehe ich auf User Stories, die ich flexibel implementieren kann, wann auch immer sie dran sind, ist vielleicht einfach nicht möglich auf dieser Basis. Letzte anti-agile Smell, auf den ich ein bisschen eingehen will, ist Scope Cryp. Scope Cryp haben wir in jedem Projekt. Am Ende des Tages auch ein Wasserfallprojekt, da kann am Ende ein Manager kommen und sagen, wow, ich hätte aber gerne noch X, Y und Z. Und natürlich wird man unter Umständen das dann trotzdem machen. Je nachdem, wie wahrscheinlich auf welcher Ebene der Manager operiert. Oder manchmal ergeben sich auch Marktverschiebungen, wo man sagt, oh Mist, wir müssen jetzt unbedingt das noch mit einbauen, sonst haben wir keine Chance eigentlich gegen unsere Konkurrenz, dann können wir es auch lassen. Oft sind das so, gerade aus der Management-Ebene, kommt ich hätte gerne noch so eine kleine Änderung. Ich kann gar nicht mehr zählen, wie oft ich das gehört habe. Meistens sind das ziemlich. drastische Reworks, die man da hat, weil irgendjemand eine gute Idee hatte oder auch eine weniger gute Idee. Das Businessrisiko dahinter ist natürlich, hey, Budgetüberschreitung, Verzögerung. potenzieller Marktvorteilsverlust, wenn ich nicht rechtzeitig mit der App an die Stadt gehe. Also Scope Creep ist immer ein Problem. In einem agilen Projekt habe ich schon oft gesehen, dass die Agilität so ein bisschen als als Ausrede oder Vorwand für Scope Creep verwendet wird. Also letzten Endes wird der Agilität als glorifiziertes Scope Creep gesehen. Ich kann zu jedem Zeitpunkt auch was einkippen und einbauen und so weiter. Das sehe ich persönlich völlig anders. Der große Vorteil von agilen Projekten ist, dass ich agile Sachen wegblassen kann. Nicht unbedingt, dass ich agile Sachen reinbringen kann. Natürlich geht das auch in der Theorie, aber in dem Moment, wo ich sage, ich habe ein Delivery Date, mit diesem Produkt fertig werden, ist der Vorteil von Agil, ich kann so lange Sachen weglassen, bis ich diese Deadline tatsächlich halten kann. In dem Moment, wo das passiert, was ich gerade beschrieben habe, also ich habe einen Scope, ich habe eine Deadline, sei die realistisch, sei sie nicht, was auch immer, muss klar sein, in dem Moment, wo ich in diesen Scope jetzt noch Sachen rein tue, ist die Deadline auch Quatsch. Und ich Es ist faszinierend, wie viele Menschen denken, es ist ja ein agiles Projekt, da kann man das ja machen. Nein, auch ein agiles Projekt wird durch mehr Features größer. Und ein größeres Projekt, auch wenn es agil genannt wird, dauert durch mehr Größe, mehr. Scope länger. Und agil ist nicht die Wunderwaffe, mit der ich plötzlich beliebigen Scope in beliebige Timelines mit beliebigem Budget implementieren kann. Dieses gloriose Dreieck Timescope Budget, das gilt hier ganz genauso. Ich kann nicht Agilität als Vorwand dafür nehmen, dass ich den Scope ändere und die gleichen Deadlines erwarte. Wird aber doch trotzdem down gemacht. Und spätestens dann ist es eigentlich kein agiles Projekt mehr. Dann ist es, ja, ich weiß gar nicht, wie ich das nennen soll, auch kein Wasserfall, es ist ein Shit-Projekt. Gut, jetzt sind wir sehr intensiv darauf eingegangen, wann ein Projekt eigentlich nicht agil ist, obwohl es agil genannt wird. Wann macht es denn Sinn, dass wir im Vornell sagen, wir machen Wasserfall oder was anderes? Es gibt ja.. andere Ansätze auch.. Ich sage, ich gruppiere die jetzt mal alle unter Wasserfall, einen nicht agilen Ansatz. Wann macht es Sinn, das zu sagen? Und von vornherein auf das Label agil und aber auch auf all die herren Ansprüche zu verzichten, die damit einhergehen. Das kann schon dann Sinn machen, wenn ich total stabile, bekannte Anforderungen habe. Wenn ich gerade so interne Architekturprojekte, wo ich sage, ich muss API A mit API B ver.. verbinden, um Report C zu generieren, da brauche ich kein agiles Projekt aufsetzen. Da kann ich einmal komplett spezifizieren, was eigentlich passieren soll, was ich an Funktionalität erwarte, und dann kann ich das von A bis Z durcharbeiten. Dann sind die Prozesse klar, es ist nicht erwartet, dass irgendwelche Innovationen passieren. Ich habe Vorhersagbarkeit von Kosten, Ressourcen und Time to Market, weil solche Sachen sind meistens Projekte, die man auch schon in ähnlicher Weise gemacht hat. Das heißt, da kann man so eine Schätzungen machen, quasi das Wetter von gestern, das letzte Mal, als wir das gemacht haben, hat so lange gedauert und so viel gekostet. Dann kann ich total unagil arbeiten letzten Endes. Ich beschreibe einmal vollständig, was ich machen will und dann setze ich eine, zwei, drei, vier Wochen hin und setze das um. Das ist insbesondere eben wahr für relativ kleine Projekte, wo ich sage, ich habe eine sehr, sehr klare. Kleine Initiative und da brauche ich kein agiles Backlog Product Honor und all diese Dinge aufsetzen. Und oft sind solche Projekte auch welche, wo man tatsächlich diese Initiative vorher mit verschiedenen Leuten besprechen muss und klären muss, was die Anforderungen von den einzelnen Abteilungen sind und und was die Anforderungen von der rechtlichen IT-Security-Seite und so weiter sind. Und diese ganzen Klärungen kann ich viel schöner machen, wenn ich eine echte Spezifikation habe. Da muss man sich wirklich nichts vormachen. Eine Spezifikation ist ein tolles Kommunikationsmittel. Ein Backlog ist Ist schon ein deutlich weniger tolles Kommunikationsmittel. Deswegen werden die dann so oft in Excel exportiert und dreimal umformatiert und rumgeschickt, weil sie halt einfach nicht so einfach zu erfassen sind, gerade für IT-fremde Fachabteilungen. Zweiter Aspekt, wann Wasserfall oder nicht agile Ansätze Sinn machen können, ist, wenn ich wahnsinnig strikte regulatorische Vorgaben habe, die ich quasi parallel im Projekt die ganze Zeit prüfen und erfüllen muss, dann kann es total Sinnvoll sein, dass man sagt, okay, wir machen zumindest ein Hybridverfahren, wo ich sage, ich habe keine Spezifikation, wo relativ detailliert drinsteht, was das Produkt leisten soll, damit ich regulatorische Prüfungen oder rechtliche Prüfungen oder auch. Quasi Prüfung durch bestimmte Behörden initiieren kann, während das Projekt läuft. Das wird mit einem agilen Projekt unglaublich schwer sein. Also Bereich Medizinprodukte, Luftfahrt, Automotive, da kann man agil arbeiten, aber eben nur. Außerhalb des Bereiches, der von diesen Problematiken erfasst werden. Und da kann dann hybride Ansätze total Sinn machen. Fix-Preisprojekte. Ganz ehrlich, Leute, Fix-Preis-Projekte agil zu machen ist verrückt. Ich hab. Auch das noch nie funktionieren sehen. Bitte Feedback, schickt mir eure Erfolgsstories von agilen Fixpreis-Projekten und damit meine ich einen Fix-Preis. Klar kann man Fix-Preis-Projekte machen, die man sagt, ich habe einen Fix-Preis pro Sprint und wir definieren dann immer, was in den Sprint reinpasst. Das ist toll, das Agile Contracting, ganz anderes Thema, kann man alles machen.

hey, dieses Projekt kostet einmal 4,3 Millionen und jetzt machen wir es agil. Wie soll das gehen? Ein Fixpreis basiert auf einer fertigen, vollständigen Spezifikation. Und einen Fixpreis zu schätzen und auszugeben auf Bas einer unfertigen Spezifikation, hat sich in meiner Erfahrung, und das sind jetzt auch schon 25 Jahre immer als schlecht erwiesen. Und zwar schlecht meistens für den Vor den Softwareanbieter, also für denjenigen, der die Software entwickeln muss, weil so viel Risiko-Buffer kann man da gar nicht einplanen, wie durch diesen agilen Ansatz entsteht an der Stelle. Gut, die Frage ist, wie vermeidet man dann Budgetrisiko bei ambitionierten Projekten. Entweder man macht halt keinen Fixpreis, sondern quasi arbeitet mit Budgets und sagt, okay, das ist unser äußeres Limit und innerhalb dieses Budgets haben wir Gestaltungsspielraum und Dann letzten Endes führt man es aber extern als Time-and-Material-Projekt. Oder man macht agiles Contracting und sagt, ich habe Fixpreis für Work-Packages, die quasi einem Sprint oder sowas entsprechen. Oder man macht den Wahnsinn, dass man sagt man preis die the user story selber einzeln das ist meistens zu deutlich zu viel Verwaltungsaufwand und da führt zu deutlich zu viel Verzögerung oder man sagt halt von vornherein es muss ein Fixpreis sein es ist ein Fixed Scope wir wissen genau was wir tun wollen und dann Es ist wieder ein Wasserfallprojekt, dann kann ich das auch, brauche ich es auch nicht agil nennen.

Okay, an der Stelle macht es vielleicht Sinn, dass ich eher ein Wasserfallprojekt aufsetze. wenn ich auf Hardware-Bestellung warten muss oder auf Hardware-Entwicklung warten muss. Also wenn ich in einem Embedded-Bereich unterwegs bin und ich arbeite parallel damit, dass die Hardware überhaupt erst entwickelt muss werden. Das heißt, ich muss mit Emulatoren arbeiten und dann irgendwann auf der realen Hardware testen. Es ist agil relativ schwierig zu koordinieren, sowas. Wenn ich auf Behörden warten muss oder von Behörden abhänge, wenn ich von internationalen oder firmeninternen Partnern abhänge, dann habe ich externe Abhängigkeit. Die ich nicht kontrollieren kann. Und wenn ich ausreichend solche externen Abhängigkeiten habe, ist mein Projekt definitionsgemäß nicht mehr agil. Wenn ich dann noch das Agile-Label ranschreibe, wird es chaotisch. Dann schreibe ich lieber das. Label nicht dran und versuche mir eine andere Projektmanagement-Methodik anzueignen, die diesem Problem Rechnung trägt. Wasserfall erlaubt Klare Schnittstellenplanung, erlaubt da Risikoreduktion, erlaubt eine klare Auflistung und Planung der Zulieferung, erlaubt mir Zulieferungen anzufordern mit unglaublich viel Leadtime und es ist schockierend, wie viel Lead Time man manchmal braucht für die kleinsten Dinge. Und dann kann ich sagen, Okay, so kann ich das unter Kontrolle kriegen. Als agiles Projekt muss ich das nicht führen. Auch Projekte mit wahnsinnig hohem Dokumentationsbedarf oder Prüfungsbedarf sind oft sehr ungeeignet, um sie so richtig agil zu führen. Also wenn die Dokumentation Teil des Potentiens. ist, Teil des Projekts ist nicht nur ein Nebenprodukt, sondern ein Kernteil, weil ich zum Beispiel gegenüber dem BSI quasi eine Prüfung beim BSI machen will oder weil ich bestimmte Standards erfüllen müssen, die hohe Dokumentation Dokumentationsaufwände erfordern. In manchen Bereichen muss man tatsächlich bis runter zu Pseudocoden in Dokumentation schreiben. Auch das ist aufwendiger, also das kann man agil führen, aber es ist viel aufwendiger, wenn man das so agil partitioniert und das pro Story zu machen. Versucht, weil das Gesamtkunstwerk dann eben nicht die Summe des Storys ist. Da muss immer noch viel Arbeit investiert werden, damit es ein Gesamtbild ergibt, wenn ich am Ende der Entwicklung quasi die Produktdokumentation erstelle. Also Auditfähigkeit, Nachvollziehbarkeiten, Rechnung, Regulatorische Compliance sind immer so Trigger, wo ich sage, okay, eventuell muss ich zumindest ein Teilprojekt unagil führen. Eine Frage, die sich natürlich aufdrängt, ich habe ein paar Mal das Thema Kosten auch angesprochen, ist, habe ich denn jetzt. Kostentechnisch automatisch Impacts, wenn ich agil versus nicht agil arbeite, was ist teurer, was ist billiger, das lässt sich natürlich so schlecht, wirklich festzurren.. Aber Die Kostenstruktur ist bei agilen Projekten anders als bei Wasserfallprojekten oder nicht agilen Projekten. Die Kosten fallen anders an Und sie sind auf andere Art kontrollierbar. Und je nachdem, was man braucht, kann das eine oder das andere deutlich besser oder schlechter sein. Also wenn ich jetzt über agile Iterationen nachdenke, dann habe ich. Ein gewissen Overhead. Das ist nicht zu leugnen. Also wenn ich das gleiche Endprodukt nehme, was 100% definiert ist, und ich sage, einem Team setzt mir das agil um und einem anderen Team sage ich, setze mir das wasserfallmäßig um. Und auf beide Projekte setze ich fähige Projektmanager, Product Owner und so weiter. Dann ist Das agile Projekt wahrscheinlich teurer. Weil der Overhead der Strukturierung in User Stories und der Möglichkeit, quasi diese Sachen individuell zu releasen, Sprint-Reviews und so weiter. Das wird höhere laufende Kosten verursachen, die über die Gesamtprojektphase auch wahrscheinlich insgesamt höher sind. Wie viel höher.. hängt von extrem vielen Faktoren ab, aber agile Projekte sind nicht billiger, wenn man exakt den gleichen Scope zugrunde legt. Der Vorteil ist, in agilen Projekten habe ich sehr, sehr frühes Feedback über einzelne Features. Alles, was fertig ist, kann ich mir anschauen und ich habe Flexibilität und kann dann.. sagen, okay, das Feature ändern wir nochmal, dafür nehmen wir dieses Feature raus oder wir machen insgesamt den Scope kleiner und so weiter.. Und damit kann ich dann in der Realität natürlich geringere Kosten erzeugen oder geringere Kosten ein besseres Kostenmanagement machen im Projektverlauf, aber ab front sind die kalkulierten Kosten höher. Bei dem Big Bang-Thema, wo ich sage, hey, ich weiß genau, was am Ende rauskommen soll, und das entwickeln wir in einem Zug durch, habe ich normalerweise kalkulierbare Kosten und bin Risikooptimierter bei bekannten Anforderungen. Aber bevor Before die Kommentar-Section vorläuft. Großes Aber. Wann kenne ich schon wirklich die Anforderungen im Detail bis zum Ende? In einer Form die verlässliche Abschätzung des Aufwands möglich macht. Und das ist, warum agile Projekte in den Kostenthemen fast immer gewinnen. Wenn ich die Annahme treffe, ich weiß genau, was meine Anforderungen sind, ich kann sie genau abschätzen, habe ich kalkuliert. Kleinere Kosten bei Big Bang-Entwicklung. Diese Annahme ist aber fast nie wahr. Erstens ist fast nie alles bekannt und zweitens sind Entwickler unfassbar schlecht im Schätzen. Insbesondere im Schätzen von Zeitaufwand. Und drittens gibt es immer Unwägbarkeiten. Also, da muss ich sagen, die Kostenfrage sollte nicht einen entscheidenden Einfluss haben auf die auf die Projektstruktur. Ich kann nicht verlässlich sagen, dass Big Bang billiger ist. Ich kann eigentlich verlässlich sagen, dass es wahrscheinlich problematischere Kostenstruktur erzeugt. Es ist wirklich keine finanzielle Betrachtung aus meiner Sicht. Wie gesagt, wenn ich das gleiche Projekt schon mal umgesetzt habe, mit leicht anderen Vorzeichen und ich total sicher bin, dass ich weiß, was getan werden muss und ich total sicher bin, welche Aufwände dahinter sind, wird das Big Bang-Projekt billiger sein. Dann stellt sich natürlich logischerweise die Frage, Kann ich das irgendwie zusammenbringen? Kann ich irgendwie sagen, ich will best of both worlds. Und jemand, der jetzt irgendwie ein Certified Scrum Product Owner, der gerade aus seiner Schulung gekommen ist, wird natürlich sagen, nein, agil oder tot. Das stimmt in einer gewissen Weise. Also in dem Moment, wo ich, wenn Hybrid heißt, ich verwische beide Ansätze, dann habe ich von beiden das Schlechteste. Agilität lebt davon, dass man sie. wirklich konsequent umsetzt, nur dann erzeugt sie die Vorteile, die sie ohne Zweifel hat. Das gleiche gilt eigentlich in einer gewissen Weise auch für Wasserfallentwicklungen. Auch die hat ihre echten Benefits, nur wenn ich sie wirklich konsequent liebe und umsetze. Kann man es trotzdem irgendwie zusammen? bringen ich behaupte ja ich behaupte die meisten projekte die so im mittelstand stattfinden und die nicht irgendwie greenfield eine revolutionäre markterschütternde Software produzieren, haben einen relativ unstrittigen Kern. Es wird man, wenn man mit solchen Firmen interagiert, wird das immer relativ schnell klar, da gibt es ein Kernprodukt, wo alle sagen, okay, das müssen wir auf jeden Fall bauen. Und das ist auch, das ist quasi der Kern unserer Idee. Wenn das nicht dabei ist, dann brauchen wir es nicht machen. Und das enthält meistens schon auch die Kernmechanismen von diesem Produkt. Also nehmen wir mal an, die Firma möchte gerne eine App umsetzen oder irgendein Softwareprodukt, was nach außen wirkt. Dann habe ich eine bestimmte Idee, ich habe bestimmte Mechanismen, die unausweichlich da drin sein müssen. Und dann habe ich ganz, ganz viele Features außenrum, die vielleicht zum Teil zu Nice-to-Have-Features werden, also gar nicht mehr unbedingt umgesetzt werden müssen, die nicht zu dieser Kern-Indeal. Idee gehören und wenn wenn das der Fall ist, dann kann ich mir überlegen, hey, ist es nicht so, dass die Komplexität, die externe Komplexität, sage ich jetzt mal so, nicht die software immanente Komplexität In dieser Kernidee eigentlich schon vollständig enthalten ist. Wenn das der Fall ist, dann kann ich sagen, okay, ich mache ein klassisches Konzept, diese Kernidee. Ich mache eine vollständige Spezifikation. Dieser Kernidee, auch ruhig mit klassischen Spezifikationsmechanismen, ich sage jetzt mal Pflichtenheft oder ähnliche Tools, die sind bewährt, die sind auch nicht schlecht. Nein, man muss nicht gleich sagen, das ist furchtbar, weil es nicht ergibt sich Heißt und sie sind vor allen Dingen leicht konsumierbar für andere Fachabteilungen, für externe Prüfer, für Zulieferer und so weiter und so fort. Das heißt, ich könnte eine klassische Konzeptphase haben für mein Kernprodukt. Könnt ihr dieses Konzept verwenden, um regulatorische Prüfungen zu machen, vielleicht auch ein Fixpreis-Projekt anzukurbeln. Wenn ich so eine vollständige Spezifikation habe, lässt sich vielleicht ein Anbieter auf Fixpreis ein. Ob sich Fixpreis lohnt mit dem Risikoaufschlag, der notwendigerweise dann immer drin ist, Das ist vielleicht für eine andere Session mal ein interessantes Thema. Meistens haben Fix-Preis-Projekte sehr unangenehme Konsequenzen für beide Seiten, weswegen ich sie eigentlich wirklich gar nicht merke. Also so normale Fix-Preis-Projekte, wo ich sage, ich habe ein Produkt und einen Preis. Die haben wirklich sehr, sehr. viele Nachteile, aber ich könnte grundsätzlich auf Basis von so einer Kernproduktspezifikation ein Fixpreis-Projekt anleihen und dann könnte ich das agil umsetzen. Ich könnte dieses diese Spezifikation vielleicht sogar auch durch einen externen Dienstleister in User Stories konvertieren lassen, die unmittelbar Feedback erlauben. Dass ich zum Beispiel das Produkt intern schon promoten kann oder Leuten zeigen kann. Ich kann natürlich nicht auf Basis des Feedbacks Anpassungen vornehmen an der Kernidee. Dann bin ich wieder nicht mehr in meinem Wasserfallmodus. Aber ich kann es grundsätzlich mit agilen Mitteln. Umsetzen und kann dann sagen, okay, an das Kernprodukt schließe ich ein richtiges, agiles Projekt an, wo wir sagen, okay, wir haben das Kernprodukt live oder nicht live, sondern auf Halde, fertig. Wir wissen, die regulatorischen Prüfungen, Zulieferungen, alles ist fertig. Das haben wir über unseren Wasserfall abgebildet. Jetzt kann ich sagen, agil, wir gehen agil Richtung 2. 0. Weil jetzt brauchen wir die schnelle Anpassung an Marktfeedback. Und da muss ich auch sagen, wenn das Produkt mal am Markt ist, dann zu sagen, jetzt mache ich noch ein Vierjahres-Wasserfallprojekt für Version. Und zwei, das ist fast nie eine gute Idee. Weil jetzt muss ich wirklich flexibel sein und agil arbeiten können und mich anpassen und jedes Feature quasi am Markt prüfen, um zu sagen, wow, das war's nicht, das machen wir nochmal anders. Und das ist für mich ein sehr, sehr. Vielversprechendes Hybridmodell. Für die agile Umsetzung würde man dann auch natürlich kein Fixpreis-Projekt sagen. Und für diese agile Umsetzung ist aber oft keine erneute regulatorische Prüfung oder Rechtsprüfung oder Zulieferung notwendig, weil jetzt optimiere ich ja nur noch an meiner Auf Basis der Kernenidee, die ich quasi ursprünglich entwickelt habe. Alternativ kann man auch sagen, man hat iterative Entwicklung und sehr feste Meilensteine. Das bedeutet aber letzten Endes auch nur, dass ich ein etwas Wasserfalliges, spezifiziertes Dass ich meine spezifizierten Meilensteine agil runterbreche. Das ist eine andere Art, das zu betrachten und zu kombinieren. Kann auch ein sinnvoller Hybridansatz sein. Im Hybridansatz habe ich trotzdem eine wahnsinnig hohe Verantwortung beim Product-Oner. Ich kann deswegen nicht auf den Product-Oner verzichten, weil für den agilen Teil brauche ich. Und das muss dann auch der gleiche sein. Also muss vielleicht nicht, aber idealerweise ist auch eine Person, die federführend bei der Spezifikation beteiligt war, damit ich dann nicht ein Informationsdisconnect habe zwischen den beiden Teilen des Projekts. Letzten Endes geht es da. Darum sich wirklich vorab zu überlegen, was ist mein Projekt, was ist meine Kernidee, was sind meine Anforderungen an externen Zulieferungen, wie sieht mein Team aus, ist es kostfunktional und so weiter und so fort. Und dann eine Balance zu finden zwischen Planungssicherheit, Flexibilität und Marktorientierung. Voll agile Entwicklung, Kanban ist eigentlich die hundertprozentige Flexibilität, da kann ich quasi tagesweise ändern, was ich machen will. Und ich muss da quasi die Balance finden, was ich wirklich für mein Projekt brauche und auch herstellen kann auf Basis der Kultur und der Personalsituation, die ich habe. Also was für Leute habe ich und welche Rollen können die sinnvoll ausfüllen. Weil die Illusion, dass ich sage, ich nehme jemanden, Der seit 30 Jahren in der Firma ist, schreibt an ihn jetzt irgendwie Product Owner dran und dann wird das schon, ist halt auch nie wahr. Das Product Owner sein, in einem kostet funktionalen Team arbeiten, das Setzt bestimmte Charaktereigenschaften voraus, setzt bestimmte Fähigkeiten voraus, setzt bestimmte Fertigkeiten voraus, bestimmte Ausbildungen auch. Niemand ist auf dem Stand einfach ein guter Product Owner. Entweder ich kann diese Situation herstellen, dass ich die Leute habe in diesen, die für diese Rollen geeignet sind, oder ich kann es eben nicht machen. AG das Projekt mit völlig. Unagilen Menschen und es gibt unagile Menschen, die sind deswegen nicht weniger wert oder so, sondern dies ist halt eine Eigenschaft, die die haben, ist unglaublich schmerzhaft. Da kommt es zu so einer permanenten internen Sabotage. Und das will man natürlich nicht haben. Long Story Short, Agilität ist einfach ein Werkzeug. Es ist, ja, es ist auch eine Philosophie, es kommt auch sehr wenige Ideologie daher, aber betrachtet es als Werkzeug, kocht es auf einer kleinen Flamme und schaut wirklich Passt diese Methode zu meinem Projekt- und Business-Kontext? Ich habe unzählige agile Projekte geführt. Ich habe viel, viel weniger Wasserfallprojekte geführt, aber ich habe in den agilen Projekten wirklich bei der Hälfte gedacht, okay, du hättest eigentlich ein Wasserfallprojekt werden. wollen. Und jetzt bist du dummerweise in diese pseudoagile Welt geboren und solche Projekte haben es oft schwierig. Also ein bisschen Mut zur ehrlichen Analyse, was braucht dieses Wort dieses Projekt wirklich? Sind die Anforderungen klar und stabil? Brauche ich Flexibilität für Marktfeedback? Ist Budget und Risiko der Hauptfaktor hier? Also ist Budget overall das wichtigste Kriterium? Habe ich Ownership und Entscheidungskraft in meiner Firma? vorhanden, habe ich jemanden, den ich als Product Owner einsetzen könne könnte. Das sind Fragen, die man sich ehrlich stellen muss pro Projektbeginn. Und dann kann man die Weichen richtig stellen. Und ich Eine unserer Missionen bei NeoMo ist ja quasi dafür zu sorgen, dass komplexe Softwareprojekte insbesondere auch mit Bezug auf künstliche Intelligenz und Einbau von sehr, sehr Modernen, komplexen Softwarekomponenten erfolgreich laufen. Und sehr oft ist es nicht die komplexe Technologie, die das schwierig macht. Sehr oft ist es einfach ein blindes Reinrauschen in eine bestimmte Projektstruktur, die sich irgendwie organisch ergibt, stattdessen wenn sich wirklich hinsetzt und sagt mit Management Buy-in, also mit wirklich auch Buy-in vom Sponsor Lasst uns dieses Projekt ehrlich betrachten und lasst uns die Struktur aufsetzen, die es braucht. Oder die Struktur aufsetzen, die optimal ist, gegeben unsere Situation. Am Ende wollen wir den viel zitierten Business Value optimieren. Also wir wollen Wert schaffen für die Firma und gleichzeitig das Budget halbwegs unter Kontrolle halten und den Markteintritt nicht verpassen. Und die Methodik und die Projektstruktur sind Werkzeuge, die dieses Ziel erreichen können. Sie sind nicht Ideologien, die um jeden Preis einfach so oder so gelebt werden sollten.