WEBVTT
00:00:00.001 --> 00:00:00.719
Hallo, willkommen.
00:00:00.800 --> 00:00:03.680
Heute wollen wir uns doch nochmal mit Projektmanagement beschäftigen.
00:00:03.919 --> 00:00:12.640
Einfach weil wir relativ Feedback kriegen zu diesem Thema und weil wir auch immer wieder sehen, wie seltsam das Thema in Unternehmen angegangen wird.
00:00:13.439 --> 00:00:14.800
Es ist unleugbar, dass eigentlich.
00:00:15.400 --> 00:00:20.280
Agilität, agiler Ansatz, agiles Projektmanagement heute fast schon der Default.
00:00:20.760 --> 00:00:23.160
Das ist quasi eine Haltung in Unternehmen.
00:00:23.239 --> 00:00:25.000
Wer agil arbeitet, gilt als Modern.
00:00:25.160 --> 00:00:27.719
Wer nicht agil arbeitet, muss sich immer rechtfertigen.
00:00:28.199 --> 00:00:29.879
Oder zumindest wer nichts sagt, er arbeitet.
00:00:30.800 --> 00:00:33.439
Ob das denn real agil ist, werden wir später erklären.
00:00:34.000 --> 00:00:44.479
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.
00:00:45.000 --> 00:00:53.880
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?
00:00:54.299 --> 00:00:57.899
Und was letzten Endes kann falsch verstandene Agilität anrichten.
00:00:57.979 --> 00:01:08.939
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.
00:01:09.459 --> 00:01:17.620
objektiv drauf schauen, wann funktioniert was und was für Vorteile kann man vielleicht auch von hybriden Ansätzen gewinnen.
00:01:17.939 --> 00:01:24.099
Aus der Perspektive von dem Manager kennt jeder die Situation, Projekte, die agil starten, aber das Budget explodiert trotzdem.
00:01:24.219 --> 00:01:29.180
Obwohl man irgendwann eingeredet bekommen hat, Agile ist ein schlanker Ansatz.
00:01:29.500 --> 00:01:35.980
Oft werden Deadlines verschoben, weil man halt doch irgendwie mit Deadlines arbeiten muss, was mit Agil nicht so wahnsinnig toll kompatibel ist.
00:01:36.140 --> 00:01:38.700
Und der Return on Investment bleibt sowieso unklar.
00:01:39.120 --> 00:01:49.239
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?
00:01:49.319 --> 00:01:56.759
Darüber haben wir auch schon mal eine Podcast-Episode gemacht, wie viel wichtiger Kultur ist eigentlich als der konkrete Projektmanagement-Ansatz.
00:01:57.000 --> 00:01:58.840
Und will ich zum Beispiel sowas wie.
00:01:59.019 --> 00:02:01.099
Schnelligkeit oder mehr Vorhersehbarkeit?
00:02:01.180 --> 00:02:08.860
Will ich Flexibilität oder will ich eine bestimmte Compliance quasi mit Regularien erreichen mit meinem Softwareprojekt?
00:02:09.120 --> 00:02:23.280
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.
00:02:23.139 --> 00:02:25.139
Fangen wir an mit einer kleinen Begriffsklärung.
00:02:25.299 --> 00:02:26.900
Agil, was heißt eigentlich agil?
00:02:27.139 --> 00:02:28.979
Beginnen wir mal so, was heißt agil nicht?
00:02:29.299 --> 00:02:32.500
Agil heißt auf keinen Fall, dass man keinen Plan macht.
00:02:32.739 --> 00:02:34.979
Agile Projektpläne sehen nur einfach anders aus.
00:02:35.139 --> 00:02:37.780
Agile Projektpläne arbeiten nicht mit definierten Time-Programmen.
00:02:38.139 --> 00:02:53.319
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.
00:02:53.479 --> 00:02:55.960
Und agiles Projektmanagement heißt auch nicht, dass man nicht.
00:02:56.879 --> 00:02:58.879
die Notwendigkeit hat, Entscheidungen zu treffen.
00:02:59.039 --> 00:03:11.539
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.
00:03:11.780 --> 00:03:18.019
Ich brauche viel entscheidungsfreudigere Menschen und auch Rollen, die viel mehr berechtigt sind, echte Entscheidungen zu treffen.
00:03:18.098 --> 00:03:18.580
Agilität.
00:03:19.098 --> 00:03:36.680
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.
00:03:36.840 --> 00:03:41.800
hey, ich bin.
00:03:42.159 --> 00:03:50.159
beginne mit den Items, die die höchste Prio haben, die meinen höchsten Business Impact haben, vielleicht den besten Einfluss auf den ROI.
00:03:50.479 --> 00:03:53.840
Mit denen beginne ich und dann arbeite ich mich so das Backlog runter.
00:03:54.240 --> 00:04:01.039
Das ist schön, das kann man in einem Wasserfallprojekt nicht so machen, da wird mehr nach Architekturen und Strukturen gruppiert.
00:04:01.360 --> 00:04:04.879
Aber das bedeutet auf der anderen Seite auch, ich muss diese Priorisierung vornehmen.
00:04:05.120 --> 00:04:07.919
Viele agile Projekte haben einen Backlog.
00:04:07.699 --> 00:04:12.739
ja, wir müssen ja eh alles umsetzen.
00:04:13.060 --> 00:04:15.139
Im Prinzip ist es schon dann kein agiles Projekt mehr.
00:04:15.219 --> 00:04:19.379
Agil heißt auch, dass der Scope flexibel gemanagt werden kann.
00:04:19.699 --> 00:04:22.500
Agilität verlangt enorm viel Abstimmung, und zwar Abschnitt.
00:04:22.939 --> 00:04:26.779
Stimmung zu Zeitpunkten, wo wir sie vielleicht nicht erwarten.
00:04:26.939 --> 00:04:30.860
Wenn ich mit einem Wasserfallprojekt arbeite, nochmal kurz für die Erinnerung, was bedeutet das?
00:04:30.939 --> 00:04:37.540
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.
00:04:37.620 --> 00:04:38.980
Also wie die Phasen genau aussehen.
00:04:39.300 --> 00:04:41.939
Da kann man unterschiedliche Ansätze wählen.
00:04:42.019 --> 00:04:45.300
Man kann auch natürlich Phasen immer wieder neu durchlaufen.
00:04:45.459 --> 00:04:52.259
Aber im Wesentlichen ist die Idee eines nicht agierten Projekts, eines Wasserfallprojekts, dass ich meine Definition vorab mache.
00:04:52.639 --> 00:05:03.920
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.
00:05:04.560 --> 00:05:17.079
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.
00:05:18.759 --> 00:05:22.360
quasi in die Richtung von diesem entsprechenden Feature komme.
00:05:23.319 --> 00:05:24.920
Wann das ist, weiß ich oft gar nicht.
00:05:25.000 --> 00:05:35.180
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.
00:05:35.259 --> 00:05:42.300
So funktioniert das normalerweise nicht, sodass ich in einem agil geführten Projekt mit sehr komplexem Environment oft Dinge.
00:05:42.620 --> 00:05:42.699
.
00:05:42.800 --> 00:05:45.680
verschieben dadurch, dass die externen Zulieferungen nicht passen.
00:05:46.000 --> 00:06:12.339
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.
00:06:13.139 --> 00:06:31.019
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.
00:06:31.339 --> 00:06:44.879
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.
00:06:45.500 --> 00:06:58.300
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.
00:06:58.199 --> 00:07:08.040
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?
00:07:07.839 --> 00:07:08.639
Output entsteht.
00:07:08.800 --> 00:07:12.560
Wohlgemerkt, ein korrekt geführtes Agiles Projekt hat dieses Problem nicht.
00:07:12.959 --> 00:07:26.639
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.
00:07:26.720 --> 00:07:28.399
Ist meine persönliche Meinung.
00:07:29.040 --> 00:07:39.800
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.
00:07:40.519 --> 00:07:47.240
Auf der Business-Ebene letzten Endes sehe ich oft in subseudo-agilen Projekten, dass es keine klaren Requirements gibt.
00:07:47.639 --> 00:08:04.418
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.
00:08:04.579 --> 00:08:09.939
Das heißt, wir beginnen in so einem Projekt ohne klare Requirements und das ist eben nicht agil.
00:08:10.420 --> 00:08:12.339
Das ist chaotisch.
00:08:12.819 --> 00:08:24.899
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.
00:08:25.279 --> 00:08:26.319
funktioniert fast nie.
00:08:27.038 --> 00:08:34.080
Der einzige Effekt, den das hat, ist, dass Budget und Zeitplan natürlich völlig unvorhersehbar werden in so einem Setting.
00:08:34.399 --> 00:08:40.399
Wenn ich nicht von vornherein weiß, worauf ich eigentlich hinaus will, kann ich auch nicht wirklich abschätzen, wenn ich damit fertig bin.
00:08:40.639 --> 00:08:42.480
Gleichzeitig ist es aber so.
00:08:42.820 --> 00:08:54.580
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.
00:08:54.919 --> 00:08:55.958
Das kann man machen.
00:08:56.120 --> 00:09:00.440
Man kann sagen, ich mache ein agiles Projekt, ich fixiere Budget und Zeitplan, also Deadline quasi.
00:09:00.600 --> 00:09:12.379
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.
00:09:12.980 --> 00:09:22.820
Zweite Symptom oder zweite Smell quasi für falsche, agile Projekte oder falsch verstandene Agilität ist, dass es keinen dedizierten Product Owner gibt.
00:09:23.379 --> 00:09:30.779
Ein Product Owner Ist eine der Kernvoraussetzungen für Agilität.
00:09:31.659 --> 00:09:40.159
Der Product Owner ist letzten Endes in jedem agilen Projekt, sei das Kanban, sei das Scrum, Die Person, die berechtigt ist, Produktentscheidungen zu treffen.
00:09:40.559 --> 00:10:02.360
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.
00:10:02.600 --> 00:10:10.360
Ich kann alle Beteiligten fragen, ich kann mir vom Boss quasi die Unterschrift holen, dass das genau das Produkt ist, das wir bauen wollen.
00:10:10.519 --> 00:10:12.279
In einem agilen Projekt kann ich das so nicht machen.
00:10:12.720 --> 00:10:22.960
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.
00:10:23.039 --> 00:10:26.399
Dann owned er gar nichts, dann ist er ein glorifizierter Sekretär.
00:10:27.059 --> 00:10:44.559
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.
00:10:44.720 --> 00:10:50.879
Klar werden sie für die großen Entscheidungen entsprechende Stakeholders hinzuziehen.
00:10:51.200 --> 00:10:56.879
Aber es ist unmöglich, dass alles eskaliert auf die Führungsebene und die Verantwortung unklar bleibt.
00:10:56.960 --> 00:11:00.159
Der Product Owner muss da sein, sonst ist es auch kein agiles Projekt.
00:11:00.240 --> 00:11:03.039
Dann nennen wir es agil, aber dann ist es nur chaotisch.
00:11:03.379 --> 00:11:08.659
Was auch oft vergessen wird und wofür auch der Product Autonomi zuständig ist, ist tatsächlich die Produktvision.
00:11:08.899 --> 00:11:12.500
Das heißt, nicht irgendwie ein fuzzy Feeling, was quasi.
00:11:12.740 --> 00:11:13.059
.
00:11:13.059 --> 00:11:13.379
.
00:11:13.299 --> 00:11:22.259
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.
00:11:22.259 --> 00:11:27.698
Und welchen Business Value oder welchen Geschäftszielen soll sich dieses Produkt quasi unterordnen.
00:11:27.778 --> 00:11:33.659
Das ist auch eine wichtige Leitlinie dafür, wonach der Product Owner dann seine Entscheidungen treffen will.
00:11:33.740 --> 00:11:40.779
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.
00:11:40.940 --> 00:11:54.919
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.
00:11:55.078 --> 00:12:25.299
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.
00:12:25.899 --> 00:12:30.940
Dann werden die notwendigerweise, selbst wenn sie sehr, sehr sorgfältig arbeiten, primär lokal optimieren.
00:12:31.179 --> 00:12:43.299
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.
00:12:43.460 --> 00:12:57.419
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.
00:12:57.620 --> 00:12:59.778
Aber schneller mit weniger Kosten.
00:13:00.100 --> 00:13:05.220
Mit einem klassischen Projekt ist das unmöglich, kann ich auf der Hälfte von einem klassischen Projekt sagen, ich ändere nochmal Fundamentales.
00:13:05.620 --> 00:13:06.339
Das wird nicht klappen.
00:13:06.500 --> 00:13:10.899
Mit einem agilen Projekt kann ich das machen und diesen Vorteil muss ich natürlich versuchen zu enden.
00:13:10.980 --> 00:13:12.179
Dazu brauche ich ein Product-Onnet.
00:13:12.299 --> 00:13:13.899
Und dazu brauche ich eine Produktvision.
00:13:14.458 --> 00:13:27.740
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.
00:13:27.820 --> 00:13:38.458
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.
00:13:39.019 --> 00:13:41.500
Bin ich eigentlich schon nicht mehr wirklich agil.
00:13:41.799 --> 00:13:53.480
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.
00:13:54.339 --> 00:14:02.500
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.
00:14:03.740 --> 00:14:14.460
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.
00:14:14.620 --> 00:14:24.759
In einem agilen Projekt, wenn rechtliche Prüfung ein Thema ist, ein kontinuiertes Thema, brauche ich eigentlich in meinem Team einen Juristen.
00:14:25.240 --> 00:14:27.000
Das ist cross-funktionales Team.
00:14:27.159 --> 00:14:31.879
Ein cross-funktionales Team heißt nicht einfach nur in meinem Entwicklungsteam ist auch eine.
00:14:32.159 --> 00:14:33.519
eine kleine QA-Person.
00:14:34.159 --> 00:14:43.200
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.
00:14:43.440 --> 00:14:54.679
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.
00:14:54.840 --> 00:14:58.360
Ist für ein agiles Projekt eigentlich oft ein Todesstoßen.
00:14:58.519 --> 00:15:02.279
Weil jetzt habe ich plötzlich einen coolen Ein cooles Backlog.
00:15:02.519 --> 00:15:07.320
Hab Sprint Velocity Schätzungen zum Beispiel kann Deadlines projizieren.
00:15:07.639 --> 00:15:10.919
Also Delivery ein Deadlines projizieren und so weiter und so fort.
00:15:11.318 --> 00:15:18.039
Aber die externen Abhängigkeiten, die ich zusätzlich drin habe, machen das alles obsolet.
00:15:18.159 --> 00:15:28.559
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.
00:15:28.720 --> 00:15:37.600
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.
00:15:37.759 --> 00:15:44.679
Und die ganze Illusion, dass man das mit dead Deadlines und Commitments und so weiter lösen könnte in der Firma.
00:15:45.399 --> 00:15:48.278
Sorry, den Zahn muss ich euch ziehen, habe ich noch nie gesehen.
00:15:48.919 --> 00:15:55.480
Die meisten Softwareprojekte in Firmen laufen relativ isoliert, die anderen Abteilungen haben Besseres zu tun, haben eigene Zahnen.
00:15:55.839 --> 00:16:03.198
Ziele und diese ganzen Zulieferungen sind mehr so auf Gnadenbasis und haben deswegen überhaupt keinerlei Committed-Deadlines.
00:16:03.278 --> 00:16:11.220
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.
00:16:11.299 --> 00:16:14.259
Und meine eigene Planbarkeit in meinem Projekt geht vollständig verloren.
00:16:14.340 --> 00:16:19.139
Also kross-funktionales Team, absolut essentiell, sonst ist es eigentlich kein agiles Projekt.
00:16:19.320 --> 00:16:27.240
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.
00:16:27.320 --> 00:16:30.120
Also ich möchte zwar meine Features und meine.
00:16:31.120 --> 00:16:38.559
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.
00:16:38.960 --> 00:16:41.279
Großer Vorteil von agilen Projekten.
00:16:41.259 --> 00:16:44.379
Möchte ich aber trotzdem auch Themen bündeln können.
00:16:44.458 --> 00:16:53.039
Also ich möchte im Prinzip sagen können, okay, wenn mir jetzt in diesem Sprint das Thema Login oder die Menüstruktur angehen.
00:16:53.200 --> 00:16:57.759
Dann lass uns mal die Themen, die dazugehören, ein bisschen zusammenbringen, damit wir nicht so viele Konflex.
00:16:58.000 --> 00:16:58.080
.
00:16:58.039 --> 00:16:59.159
Kontextwechsel haben.
00:16:59.320 --> 00:17:06.838
Damit also das Entwicklungsteam nicht fünfmal die gleiche Stelle anfasst und nicht fünfmal über bestimmte Dinge nachdenken muss.
00:17:06.920 --> 00:17:09.400
Man will ja eigentlich so Kontextwechsel ein bisschen minimieren.
00:17:09.199 --> 00:17:15.278
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.
00:17:15.599 --> 00:17:20.880
In chaotischen Projekten ist es oft der Fall, dass ich es nicht bündeln kann, weil niemand da war.
00:17:20.880 --> 00:17:26.240
der tatsächlich in der Lage wäre, jetzt diese ganzen Themen gleichzeitig zu oder rechtzeitig zu definieren.
00:17:26.400 --> 00:17:32.079
Und dann entwickle ich letzten Endes immer das, was fertig definiert ist, weil ich mit der Definition permanent hinten dran bin.
00:17:32.299 --> 00:17:37.019
Und das bedingt dann relativ viele Kontextwechsel und macht die Entwicklung langsam.
00:17:37.259 --> 00:17:46.779
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.
00:17:47.059 --> 00:17:50.579
dazu gekommen, aber ich habe auch keine Ressourcen, weil ich habe noch 50 andere Jobs.
00:17:50.740 --> 00:17:52.819
Das macht ein Projekt auch ineffizient.
00:17:53.059 --> 00:17:59.059
Was auch so ein anti-agiles Smell ist, auch sind riesige User-Stories mit zig querverweisen.
00:17:59.140 --> 00:18:18.180
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.
00:18:18.660 --> 00:18:25.700
Normalerweise versucht man im agilen Projekt, User Stories so weit voneinander zu entkoppeln, wie man nur eben kann.
00:18:25.940 --> 00:18:29.298
Und oft geht das auch, aber das ist in einer gewissen Weise eine Kunst.
00:18:29.538 --> 00:18:30.659
Ein Product Owner bzw.
00:18:30.980 --> 00:18:43.079
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.
00:18:43.240 --> 00:18:51.880
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.
00:18:52.359 --> 00:18:59.440
Einfach Weil man versucht hat, eine Spezifikation zu schreiben und die auf 20 Storys dann aufzusplitten, damit es nicht wie eine Spezifikation aussieht.
00:18:59.519 --> 00:19:22.039
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.
00:19:22.880 --> 00:19:25.599
Letzte anti-agile Smell, auf den ich ein bisschen eingehen will, ist Scope Cryp.
00:19:25.680 --> 00:19:27.119
Scope Cryp haben wir in jedem Projekt.
00:19:27.680 --> 00:19:34.720
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.
00:19:35.039 --> 00:19:37.680
Und natürlich wird man unter Umständen das dann trotzdem machen.
00:19:38.119 --> 00:19:41.319
Je nachdem, wie wahrscheinlich auf welcher Ebene der Manager operiert.
00:19:41.559 --> 00:19:50.920
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.
00:19:51.200 --> 00:19:55.920
Oft sind das so, gerade aus der Management-Ebene, kommt ich hätte gerne noch so eine kleine Änderung.
00:19:56.240 --> 00:19:58.640
Ich kann gar nicht mehr zählen, wie oft ich das gehört habe.
00:19:58.799 --> 00:19:59.920
Meistens sind das ziemlich.
00:20:00.160 --> 00:20:06.799
drastische Reworks, die man da hat, weil irgendjemand eine gute Idee hatte oder auch eine weniger gute Idee.
00:20:06.880 --> 00:20:11.599
Das Businessrisiko dahinter ist natürlich, hey, Budgetüberschreitung, Verzögerung.
00:20:11.919 --> 00:20:15.279
potenzieller Marktvorteilsverlust, wenn ich nicht rechtzeitig mit der App an die Stadt gehe.
00:20:15.359 --> 00:20:17.440
Also Scope Creep ist immer ein Problem.
00:20:17.679 --> 00:20:27.559
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.
00:20:27.640 --> 00:20:30.839
Also letzten Endes wird der Agilität als glorifiziertes Scope Creep gesehen.
00:20:30.920 --> 00:20:34.200
Ich kann zu jedem Zeitpunkt auch was einkippen und einbauen und so weiter.
00:20:34.539 --> 00:20:36.380
Das sehe ich persönlich völlig anders.
00:20:36.619 --> 00:20:40.859
Der große Vorteil von agilen Projekten ist, dass ich agile Sachen wegblassen kann.
00:20:41.099 --> 00:20:43.900
Nicht unbedingt, dass ich agile Sachen reinbringen kann.
00:20:44.299 --> 00:20:57.460
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.
00:20:57.539 --> 00:21:10.259
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.
00:21:11.220 --> 00:21:17.140
Und ich Es ist faszinierend, wie viele Menschen denken, es ist ja ein agiles Projekt, da kann man das ja machen.
00:21:17.220 --> 00:21:20.339
Nein, auch ein agiles Projekt wird durch mehr Features größer.
00:21:20.980 --> 00:21:26.740
Und ein größeres Projekt, auch wenn es agil genannt wird, dauert durch mehr Größe, mehr.
00:21:27.259 --> 00:21:28.460
Scope länger.
00:21:28.779 --> 00:21:35.740
Und agil ist nicht die Wunderwaffe, mit der ich plötzlich beliebigen Scope in beliebige Timelines mit beliebigem Budget implementieren kann.
00:21:35.900 --> 00:21:40.940
Dieses gloriose Dreieck Timescope Budget, das gilt hier ganz genauso.
00:21:42.019 --> 00:21:47.140
Ich kann nicht Agilität als Vorwand dafür nehmen, dass ich den Scope ändere und die gleichen Deadlines erwarte.
00:21:47.299 --> 00:21:49.140
Wird aber doch trotzdem down gemacht.
00:21:49.220 --> 00:21:51.539
Und spätestens dann ist es eigentlich kein agiles Projekt mehr.
00:21:51.619 --> 00:21:56.099
Dann ist es, ja, ich weiß gar nicht, wie ich das nennen soll, auch kein Wasserfall, es ist ein Shit-Projekt.
00:21:56.859 --> 00:22:03.180
Gut, jetzt sind wir sehr intensiv darauf eingegangen, wann ein Projekt eigentlich nicht agil ist, obwohl es agil genannt wird.
00:22:03.339 --> 00:22:07.180
Wann macht es denn Sinn, dass wir im Vornell sagen, wir machen Wasserfall oder was anderes?
00:22:07.259 --> 00:22:07.819
Es gibt ja.
00:22:08.140 --> 00:22:08.460
.
00:22:08.179 --> 00:22:09.538
andere Ansätze auch.
00:22:08.460 --> 00:22:08.779
.
00:22:09.619 --> 00:22:12.898
Ich sage, ich gruppiere die jetzt mal alle unter Wasserfall, einen nicht agilen Ansatz.
00:22:13.298 --> 00:22:14.898
Wann macht es Sinn, das zu sagen?
00:22:14.980 --> 00:22:21.380
Und von vornherein auf das Label agil und aber auch auf all die herren Ansprüche zu verzichten, die damit einhergehen.
00:22:21.519 --> 00:22:27.119
Das kann schon dann Sinn machen, wenn ich total stabile, bekannte Anforderungen habe.
00:22:27.599 --> 00:22:32.960
Wenn ich gerade so interne Architekturprojekte, wo ich sage, ich muss API A mit API B ver.
00:22:33.038 --> 00:22:33.119
.
00:22:33.259 --> 00:22:37.419
verbinden, um Report C zu generieren, da brauche ich kein agiles Projekt aufsetzen.
00:22:37.579 --> 00:22:47.099
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.
00:22:47.839 --> 00:22:52.400
Dann sind die Prozesse klar, es ist nicht erwartet, dass irgendwelche Innovationen passieren.
00:22:52.558 --> 00:23:00.640
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.
00:23:00.720 --> 00:23:08.680
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.
00:23:08.839 --> 00:23:12.200
Dann kann ich total unagil arbeiten letzten Endes.
00:23:12.278 --> 00:23:16.839
Ich beschreibe einmal vollständig, was ich machen will und dann setze ich eine, zwei, drei, vier Wochen hin und setze das um.
00:23:16.919 --> 00:23:22.038
Das ist insbesondere eben wahr für relativ kleine Projekte, wo ich sage, ich habe eine sehr, sehr klare.
00:23:22.440 --> 00:23:27.960
Kleine Initiative und da brauche ich kein agiles Backlog Product Honor und all diese Dinge aufsetzen.
00:23:28.119 --> 00:23:45.339
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.
00:23:45.419 --> 00:23:48.859
Und diese ganzen Klärungen kann ich viel schöner machen, wenn ich eine echte Spezifikation habe.
00:23:49.019 --> 00:23:50.460
Da muss man sich wirklich nichts vormachen.
00:23:50.619 --> 00:23:53.099
Eine Spezifikation ist ein tolles Kommunikationsmittel.
00:23:53.179 --> 00:23:56.660
Ein Backlog ist Ist schon ein deutlich weniger tolles Kommunikationsmittel.
00:23:56.900 --> 00:24:08.419
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.
00:24:09.419 --> 00:24:38.419
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.
00:24:39.259 --> 00:24:44.859
Quasi Prüfung durch bestimmte Behörden initiieren kann, während das Projekt läuft.
00:24:44.940 --> 00:24:46.940
Das wird mit einem agilen Projekt unglaublich schwer sein.
00:24:47.019 --> 00:24:53.740
Also Bereich Medizinprodukte, Luftfahrt, Automotive, da kann man agil arbeiten, aber eben nur.
00:24:54.160 --> 00:24:57.279
Außerhalb des Bereiches, der von diesen Problematiken erfasst werden.
00:24:57.359 --> 00:25:00.079
Und da kann dann hybride Ansätze total Sinn machen.
00:25:01.039 --> 00:25:02.480
Fix-Preisprojekte.
00:25:02.720 --> 00:25:06.319
Ganz ehrlich, Leute, Fix-Preis-Projekte agil zu machen ist verrückt.
00:25:06.559 --> 00:25:07.279
Ich hab.
00:25:07.519 --> 00:25:09.440
Auch das noch nie funktionieren sehen.
00:25:10.240 --> 00:25:16.480
Bitte Feedback, schickt mir eure Erfolgsstories von agilen Fixpreis-Projekten und damit meine ich einen Fix-Preis.
00:25:16.638 --> 00:25:22.079
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.
00:25:22.359 --> 00:25:25.480
Das ist toll, das Agile Contracting, ganz anderes Thema, kann man alles machen.
00:25:25.638 --> 00:25:31.000
hey, dieses Projekt kostet einmal 4,3 Millionen und jetzt machen wir es agil.
00:25:31.558 --> 00:25:32.759
Wie soll das gehen?
00:25:33.079 --> 00:25:37.000
Ein Fixpreis basiert auf einer fertigen, vollständigen Spezifikation.
00:25:37.679 --> 00:25:49.440
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.
00:25:49.519 --> 00:26:02.038
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.
00:26:03.798 --> 00:26:08.798
Gut, die Frage ist, wie vermeidet man dann Budgetrisiko bei ambitionierten Projekten.
00:26:08.960 --> 00:26:25.579
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.
00:26:25.740 --> 00:26:33.579
Oder man macht agiles Contracting und sagt, ich habe Fixpreis für Work-Packages, die quasi einem Sprint oder sowas entsprechen.
00:26:33.740 --> 00:26:55.019
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.
00:26:55.579 --> 00:27:05.980
Okay, an der Stelle macht es vielleicht Sinn, dass ich eher ein Wasserfallprojekt aufsetze.
00:27:07.058 --> 00:27:11.380
wenn ich auf Hardware-Bestellung warten muss oder auf Hardware-Entwicklung warten muss.
00:27:11.460 --> 00:27:19.220
Also wenn ich in einem Embedded-Bereich unterwegs bin und ich arbeite parallel damit, dass die Hardware überhaupt erst entwickelt muss werden.
00:27:19.720 --> 00:27:23.240
Das heißt, ich muss mit Emulatoren arbeiten und dann irgendwann auf der realen Hardware testen.
00:27:23.319 --> 00:27:25.720
Es ist agil relativ schwierig zu koordinieren, sowas.
00:27:25.880 --> 00:27:33.799
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.
00:27:34.319 --> 00:27:36.000
Die ich nicht kontrollieren kann.
00:27:36.480 --> 00:27:43.440
Und wenn ich ausreichend solche externen Abhängigkeiten habe, ist mein Projekt definitionsgemäß nicht mehr agil.
00:27:43.680 --> 00:27:46.960
Wenn ich dann noch das Agile-Label ranschreibe, wird es chaotisch.
00:27:47.759 --> 00:27:48.720
Dann schreibe ich lieber das.
00:27:49.240 --> 00:27:56.119
Label nicht dran und versuche mir eine andere Projektmanagement-Methodik anzueignen, die diesem Problem Rechnung trägt.
00:27:56.599 --> 00:28:12.038
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.
00:28:12.200 --> 00:28:16.480
Und dann kann ich sagen, Okay, so kann ich das unter Kontrolle kriegen.
00:28:16.558 --> 00:28:18.638
Als agiles Projekt muss ich das nicht führen.
00:28:18.880 --> 00:28:26.240
Auch Projekte mit wahnsinnig hohem Dokumentationsbedarf oder Prüfungsbedarf sind oft sehr ungeeignet, um sie so richtig agil zu führen.
00:28:26.398 --> 00:28:28.079
Also wenn die Dokumentation Teil des Potentiens.
00:28:28.599 --> 00:28:45.759
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.
00:28:46.720 --> 00:28:50.558
In manchen Bereichen muss man tatsächlich bis runter zu Pseudocoden in Dokumentation schreiben.
00:28:50.720 --> 00:28:58.079
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.
00:28:58.440 --> 00:29:02.119
Versucht, weil das Gesamtkunstwerk dann eben nicht die Summe des Storys ist.
00:29:02.200 --> 00:29:09.960
Da muss immer noch viel Arbeit investiert werden, damit es ein Gesamtbild ergibt, wenn ich am Ende der Entwicklung quasi die Produktdokumentation erstelle.
00:29:10.519 --> 00:29:19.119
Also Auditfähigkeit, Nachvollziehbarkeiten, Rechnung, Regulatorische Compliance sind immer so Trigger, wo ich sage, okay, eventuell muss ich zumindest ein Teilprojekt unagil führen.
00:29:19.759 --> 00:29:26.000
Eine Frage, die sich natürlich aufdrängt, ich habe ein paar Mal das Thema Kosten auch angesprochen, ist, habe ich denn jetzt.
00:29:26.259 --> 00:29:37.538
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.
00:29:27.839 --> 00:29:27.919
.
00:29:38.179 --> 00:29:46.220
Aber Die Kostenstruktur ist bei agilen Projekten anders als bei Wasserfallprojekten oder nicht agilen Projekten.
00:29:46.460 --> 00:29:52.420
Die Kosten fallen anders an Und sie sind auf andere Art kontrollierbar.
00:29:52.500 --> 00:29:57.619
Und je nachdem, was man braucht, kann das eine oder das andere deutlich besser oder schlechter sein.
00:29:57.700 --> 00:30:02.019
Also wenn ich jetzt über agile Iterationen nachdenke, dann habe ich.
00:30:02.259 --> 00:30:03.779
Ein gewissen Overhead.
00:30:03.940 --> 00:30:05.538
Das ist nicht zu leugnen.
00:30:05.619 --> 00:30:15.619
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.
00:30:16.299 --> 00:30:22.299
Und auf beide Projekte setze ich fähige Projektmanager, Product Owner und so weiter.
00:30:22.460 --> 00:30:25.160
Dann ist Das agile Projekt wahrscheinlich teurer.
00:30:25.319 --> 00:30:35.680
Weil der Overhead der Strukturierung in User Stories und der Möglichkeit, quasi diese Sachen individuell zu releasen, Sprint-Reviews und so weiter.
00:30:35.920 --> 00:30:41.839
Das wird höhere laufende Kosten verursachen, die über die Gesamtprojektphase auch wahrscheinlich insgesamt höher sind.
00:30:42.000 --> 00:30:42.880
Wie viel höher.
00:30:43.039 --> 00:30:43.119
.
00:30:43.059 --> 00:30:52.180
hängt von extrem vielen Faktoren ab, aber agile Projekte sind nicht billiger, wenn man exakt den gleichen Scope zugrunde legt.
00:30:52.140 --> 00:30:56.460
Der Vorteil ist, in agilen Projekten habe ich sehr, sehr frühes Feedback über einzelne Features.
00:30:56.619 --> 00:31:01.339
Alles, was fertig ist, kann ich mir anschauen und ich habe Flexibilität und kann dann.
00:31:01.579 --> 00:31:01.900
.
00:31:01.660 --> 00:31:07.420
sagen, okay, das Feature ändern wir nochmal, dafür nehmen wir dieses Feature raus oder wir machen insgesamt den Scope kleiner und so weiter.
00:31:01.900 --> 00:31:02.220
.
00:31:07.500 --> 00:31:21.180
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.
00:31:21.519 --> 00:31:34.880
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.
00:31:35.119 --> 00:31:38.440
Aber bevor Before die Kommentar-Section vorläuft.
00:31:38.599 --> 00:31:39.480
Großes Aber.
00:31:40.200 --> 00:31:44.119
Wann kenne ich schon wirklich die Anforderungen im Detail bis zum Ende?
00:31:43.960 --> 00:31:47.640
In einer Form die verlässliche Abschätzung des Aufwands möglich macht.
00:31:47.799 --> 00:31:51.880
Und das ist, warum agile Projekte in den Kostenthemen fast immer gewinnen.
00:31:52.519 --> 00:31:58.599
Wenn ich die Annahme treffe, ich weiß genau, was meine Anforderungen sind, ich kann sie genau abschätzen, habe ich kalkuliert.
00:31:59.680 --> 00:32:01.839
Kleinere Kosten bei Big Bang-Entwicklung.
00:32:02.000 --> 00:32:04.160
Diese Annahme ist aber fast nie wahr.
00:32:04.400 --> 00:32:11.680
Erstens ist fast nie alles bekannt und zweitens sind Entwickler unfassbar schlecht im Schätzen.
00:32:12.240 --> 00:32:14.319
Insbesondere im Schätzen von Zeitaufwand.
00:32:14.400 --> 00:32:16.559
Und drittens gibt es immer Unwägbarkeiten.
00:32:16.720 --> 00:32:25.240
Also, da muss ich sagen, die Kostenfrage sollte nicht einen entscheidenden Einfluss haben auf die auf die Projektstruktur.
00:32:25.559 --> 00:32:28.440
Ich kann nicht verlässlich sagen, dass Big Bang billiger ist.
00:32:28.519 --> 00:32:32.839
Ich kann eigentlich verlässlich sagen, dass es wahrscheinlich problematischere Kostenstruktur erzeugt.
00:32:33.079 --> 00:32:37.079
Es ist wirklich keine finanzielle Betrachtung aus meiner Sicht.
00:32:37.640 --> 00:32:50.240
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.
00:32:50.559 --> 00:32:55.559
Dann stellt sich natürlich logischerweise die Frage, Kann ich das irgendwie zusammenbringen?
00:32:55.720 --> 00:32:58.599
Kann ich irgendwie sagen, ich will best of both worlds.
00:32:59.480 --> 00:33:10.799
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.
00:33:11.920 --> 00:33:13.359
Das stimmt in einer gewissen Weise.
00:33:13.440 --> 00:33:18.880
Also in dem Moment, wo ich, wenn Hybrid heißt, ich verwische beide Ansätze, dann habe ich von beiden das Schlechteste.
00:33:19.519 --> 00:33:21.519
Agilität lebt davon, dass man sie.
00:33:22.039 --> 00:33:27.319
wirklich konsequent umsetzt, nur dann erzeugt sie die Vorteile, die sie ohne Zweifel hat.
00:33:27.559 --> 00:33:31.559
Das gleiche gilt eigentlich in einer gewissen Weise auch für Wasserfallentwicklungen.
00:33:31.640 --> 00:33:35.240
Auch die hat ihre echten Benefits, nur wenn ich sie wirklich konsequent liebe und umsetze.
00:33:35.480 --> 00:33:36.599
Kann man es trotzdem irgendwie zusammen?
00:33:36.960 --> 00:33:55.880
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.
00:33:56.440 --> 00:34:06.119
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.
00:34:06.359 --> 00:34:09.000
Und das ist auch, das ist quasi der Kern unserer Idee.
00:34:09.239 --> 00:34:12.360
Wenn das nicht dabei ist, dann brauchen wir es nicht machen.
00:34:12.440 --> 00:34:15.719
Und das enthält meistens schon auch die Kernmechanismen von diesem Produkt.
00:34:15.800 --> 00:34:21.960
Also nehmen wir mal an, die Firma möchte gerne eine App umsetzen oder irgendein Softwareprodukt, was nach außen wirkt.
00:34:22.119 --> 00:34:26.940
Dann habe ich eine bestimmte Idee, ich habe bestimmte Mechanismen, die unausweichlich da drin sein müssen.
00:34:27.099 --> 00:34:38.378
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.
00:34:38.579 --> 00:34:57.579
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.
00:34:59.019 --> 00:35:04.780
Wenn das der Fall ist, dann kann ich sagen, okay, ich mache ein klassisches Konzept, diese Kernidee.
00:35:05.099 --> 00:35:08.300
Ich mache eine vollständige Spezifikation.
00:35:08.820 --> 00:35:20.099
Dieser Kernidee, auch ruhig mit klassischen Spezifikationsmechanismen, ich sage jetzt mal Pflichtenheft oder ähnliche Tools, die sind bewährt, die sind auch nicht schlecht.
00:35:20.179 --> 00:35:33.820
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.
00:35:33.900 --> 00:35:38.139
Das heißt, ich könnte eine klassische Konzeptphase haben für mein Kernprodukt.
00:35:38.659 --> 00:35:44.019
Könnt ihr dieses Konzept verwenden, um regulatorische Prüfungen zu machen, vielleicht auch ein Fixpreis-Projekt anzukurbeln.
00:35:44.099 --> 00:35:48.340
Wenn ich so eine vollständige Spezifikation habe, lässt sich vielleicht ein Anbieter auf Fixpreis ein.
00:35:48.659 --> 00:35:56.539
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.
00:35:56.780 --> 00:36:02.139
Meistens haben Fix-Preis-Projekte sehr unangenehme Konsequenzen für beide Seiten, weswegen ich sie eigentlich wirklich gar nicht merke.
00:36:02.219 --> 00:36:06.619
Also so normale Fix-Preis-Projekte, wo ich sage, ich habe ein Produkt und einen Preis.
00:36:07.099 --> 00:36:08.139
Die haben wirklich sehr, sehr.
00:36:08.579 --> 00:36:17.699
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.
00:36:17.940 --> 00:36:27.900
Ich könnte dieses diese Spezifikation vielleicht sogar auch durch einen externen Dienstleister in User Stories konvertieren lassen, die unmittelbar Feedback erlauben.
00:36:28.000 --> 00:36:32.320
Dass ich zum Beispiel das Produkt intern schon promoten kann oder Leuten zeigen kann.
00:36:32.480 --> 00:36:36.000
Ich kann natürlich nicht auf Basis des Feedbacks Anpassungen vornehmen an der Kernidee.
00:36:36.639 --> 00:36:40.079
Dann bin ich wieder nicht mehr in meinem Wasserfallmodus.
00:36:40.239 --> 00:36:42.400
Aber ich kann es grundsätzlich mit agilen Mitteln.
00:36:42.920 --> 00:36:54.039
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.
00:36:54.199 --> 00:36:57.480
Wir wissen, die regulatorischen Prüfungen, Zulieferungen, alles ist fertig.
00:36:57.760 --> 00:36:59.840
Das haben wir über unseren Wasserfall abgebildet.
00:37:00.079 --> 00:37:03.360
Jetzt kann ich sagen, agil, wir gehen agil Richtung 2.
00:37:03.440 --> 00:37:03.519
0.
00:37:03.920 --> 00:37:06.480
Weil jetzt brauchen wir die schnelle Anpassung an Marktfeedback.
00:37:06.559 --> 00:37:12.480
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.
00:37:12.599 --> 00:37:14.440
Und zwei, das ist fast nie eine gute Idee.
00:37:14.599 --> 00:37:25.559
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.
00:37:25.719 --> 00:37:27.320
Und das ist für mich ein sehr, sehr.
00:37:27.659 --> 00:37:29.019
Vielversprechendes Hybridmodell.
00:37:29.099 --> 00:37:33.179
Für die agile Umsetzung würde man dann auch natürlich kein Fixpreis-Projekt sagen.
00:37:33.579 --> 00:37:48.019
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.
00:37:48.179 --> 00:37:52.019
Alternativ kann man auch sagen, man hat iterative Entwicklung und sehr feste Meilensteine.
00:37:52.099 --> 00:38:00.300
Das bedeutet aber letzten Endes auch nur, dass ich ein etwas Wasserfalliges, spezifiziertes Dass ich meine spezifizierten Meilensteine agil runterbreche.
00:38:00.380 --> 00:38:02.699
Das ist eine andere Art, das zu betrachten und zu kombinieren.
00:38:03.019 --> 00:38:05.179
Kann auch ein sinnvoller Hybridansatz sein.
00:38:05.579 --> 00:38:09.500
Im Hybridansatz habe ich trotzdem eine wahnsinnig hohe Verantwortung beim Product-Oner.
00:38:09.579 --> 00:38:12.380
Ich kann deswegen nicht auf den Product-Oner verzichten, weil für den agilen Teil brauche ich.
00:38:13.300 --> 00:38:15.300
Und das muss dann auch der gleiche sein.
00:38:15.460 --> 00:38:26.260
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.
00:38:26.420 --> 00:38:27.300
Letzten Endes geht es da.
00:38:27.579 --> 00:38:38.539
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.
00:38:38.940 --> 00:38:46.219
Und dann eine Balance zu finden zwischen Planungssicherheit, Flexibilität und Marktorientierung.
00:38:46.539 --> 00:38:53.659
Voll agile Entwicklung, Kanban ist eigentlich die hundertprozentige Flexibilität, da kann ich quasi tagesweise ändern, was ich machen will.
00:38:53.300 --> 00:39:02.420
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.
00:39:02.500 --> 00:39:06.340
Also was für Leute habe ich und welche Rollen können die sinnvoll ausfüllen.
00:39:06.420 --> 00:39:14.619
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.
00:39:15.179 --> 00:39:29.659
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.
00:39:29.980 --> 00:39:32.539
Niemand ist auf dem Stand einfach ein guter Product Owner.
00:39:34.019 --> 00:39:41.139
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.
00:39:41.380 --> 00:39:42.980
AG das Projekt mit völlig.
00:39:43.340 --> 00:39:54.619
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.
00:39:54.699 --> 00:39:57.099
Da kommt es zu so einer permanenten internen Sabotage.
00:39:57.579 --> 00:39:59.460
Und das will man natürlich nicht haben.
00:39:59.860 --> 00:40:02.659
Long Story Short, Agilität ist einfach ein Werkzeug.
00:40:02.980 --> 00:40:15.760
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?
00:40:15.760 --> 00:40:18.880
Ich habe unzählige agile Projekte geführt.
00:40:18.880 --> 00:40:27.199
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.
00:40:27.559 --> 00:40:27.960
wollen.
00:40:28.039 --> 00:40:35.400
Und jetzt bist du dummerweise in diese pseudoagile Welt geboren und solche Projekte haben es oft schwierig.
00:40:35.920 --> 00:40:41.119
Also ein bisschen Mut zur ehrlichen Analyse, was braucht dieses Wort dieses Projekt wirklich?
00:40:41.440 --> 00:40:43.199
Sind die Anforderungen klar und stabil?
00:40:43.980 --> 00:40:46.539
Brauche ich Flexibilität für Marktfeedback?
00:40:46.860 --> 00:40:49.420
Ist Budget und Risiko der Hauptfaktor hier?
00:40:49.579 --> 00:40:53.019
Also ist Budget overall das wichtigste Kriterium?
00:40:53.340 --> 00:40:56.780
Habe ich Ownership und Entscheidungskraft in meiner Firma?
00:40:56.940 --> 00:41:02.059
vorhanden, habe ich jemanden, den ich als Product Owner einsetzen könne könnte.
00:41:03.099 --> 00:41:06.619
Das sind Fragen, die man sich ehrlich stellen muss pro Projektbeginn.
00:41:06.780 --> 00:41:08.780
Und dann kann man die Weichen richtig stellen.
00:41:08.858 --> 00:41:25.780
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.
00:41:26.260 --> 00:41:31.619
Und sehr oft ist es nicht die komplexe Technologie, die das schwierig macht.
00:41:31.699 --> 00:41:50.679
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.
00:41:51.320 --> 00:41:57.239
Oder die Struktur aufsetzen, die optimal ist, gegeben unsere Situation.
00:41:58.199 --> 00:42:03.599
Am Ende wollen wir den viel zitierten Business Value optimieren.
00:42:04.000 --> 00:42:14.000
Also wir wollen Wert schaffen für die Firma und gleichzeitig das Budget halbwegs unter Kontrolle halten und den Markteintritt nicht verpassen.
00:42:14.119 --> 00:42:21.719
Und die Methodik und die Projektstruktur sind Werkzeuge, die dieses Ziel erreichen können.
00:42:21.880 --> 00:42:27.559
Sie sind nicht Ideologien, die um jeden Preis einfach so oder so gelebt werden sollten.
00:00:00.001 --> 00:00:00.719
Hallo, willkommen.
00:00:00.800 --> 00:00:03.680
Heute wollen wir uns doch nochmal mit Projektmanagement beschäftigen.
00:00:03.919 --> 00:00:12.640
Einfach weil wir relativ Feedback kriegen zu diesem Thema und weil wir auch immer wieder sehen, wie seltsam das Thema in Unternehmen angegangen wird.
00:00:13.439 --> 00:00:14.800
Es ist unleugbar, dass eigentlich.
00:00:15.400 --> 00:00:20.280
Agilität, agiler Ansatz, agiles Projektmanagement heute fast schon der Default.
00:00:20.760 --> 00:00:23.160
Das ist quasi eine Haltung in Unternehmen.
00:00:23.239 --> 00:00:25.000
Wer agil arbeitet, gilt als Modern.
00:00:25.160 --> 00:00:27.719
Wer nicht agil arbeitet, muss sich immer rechtfertigen.
00:00:28.199 --> 00:00:29.879
Oder zumindest wer nichts sagt, er arbeitet.
00:00:30.800 --> 00:00:33.439
Ob das denn real agil ist, werden wir später erklären.
00:00:34.000 --> 00:00:44.479
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.
00:00:45.000 --> 00:00:53.880
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?
00:00:54.299 --> 00:00:57.899
Und was letzten Endes kann falsch verstandene Agilität anrichten.
00:00:57.979 --> 00:01:08.939
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.
00:01:09.459 --> 00:01:17.620
objektiv drauf schauen, wann funktioniert was und was für Vorteile kann man vielleicht auch von hybriden Ansätzen gewinnen.
00:01:17.939 --> 00:01:24.099
Aus der Perspektive von dem Manager kennt jeder die Situation, Projekte, die agil starten, aber das Budget explodiert trotzdem.
00:01:24.219 --> 00:01:29.180
Obwohl man irgendwann eingeredet bekommen hat, Agile ist ein schlanker Ansatz.
00:01:29.500 --> 00:01:35.980
Oft werden Deadlines verschoben, weil man halt doch irgendwie mit Deadlines arbeiten muss, was mit Agil nicht so wahnsinnig toll kompatibel ist.
00:01:36.140 --> 00:01:38.700
Und der Return on Investment bleibt sowieso unklar.
00:01:39.120 --> 00:01:49.239
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?
00:01:49.319 --> 00:01:56.759
Darüber haben wir auch schon mal eine Podcast-Episode gemacht, wie viel wichtiger Kultur ist eigentlich als der konkrete Projektmanagement-Ansatz.
00:01:57.000 --> 00:01:58.840
Und will ich zum Beispiel sowas wie.
00:01:59.019 --> 00:02:01.099
Schnelligkeit oder mehr Vorhersehbarkeit?
00:02:01.180 --> 00:02:08.860
Will ich Flexibilität oder will ich eine bestimmte Compliance quasi mit Regularien erreichen mit meinem Softwareprojekt?
00:02:09.120 --> 00:02:23.280
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.
00:02:23.139 --> 00:02:25.139
Fangen wir an mit einer kleinen Begriffsklärung.
00:02:25.299 --> 00:02:26.900
Agil, was heißt eigentlich agil?
00:02:27.139 --> 00:02:28.979
Beginnen wir mal so, was heißt agil nicht?
00:02:29.299 --> 00:02:32.500
Agil heißt auf keinen Fall, dass man keinen Plan macht.
00:02:32.739 --> 00:02:34.979
Agile Projektpläne sehen nur einfach anders aus.
00:02:35.139 --> 00:02:37.780
Agile Projektpläne arbeiten nicht mit definierten Time-Programmen.
00:02:38.139 --> 00:02:53.319
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.
00:02:53.479 --> 00:02:55.960
Und agiles Projektmanagement heißt auch nicht, dass man nicht.
00:02:56.879 --> 00:02:58.879
die Notwendigkeit hat, Entscheidungen zu treffen.
00:02:59.039 --> 00:03:11.539
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.
00:03:11.780 --> 00:03:18.019
Ich brauche viel entscheidungsfreudigere Menschen und auch Rollen, die viel mehr berechtigt sind, echte Entscheidungen zu treffen.
00:03:18.098 --> 00:03:18.580
Agilität.
00:03:19.098 --> 00:03:36.680
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.
00:03:36.840 --> 00:03:41.800
hey, ich bin.
00:03:42.159 --> 00:03:50.159
beginne mit den Items, die die höchste Prio haben, die meinen höchsten Business Impact haben, vielleicht den besten Einfluss auf den ROI.
00:03:50.479 --> 00:03:53.840
Mit denen beginne ich und dann arbeite ich mich so das Backlog runter.
00:03:54.240 --> 00:04:01.039
Das ist schön, das kann man in einem Wasserfallprojekt nicht so machen, da wird mehr nach Architekturen und Strukturen gruppiert.
00:04:01.360 --> 00:04:04.879
Aber das bedeutet auf der anderen Seite auch, ich muss diese Priorisierung vornehmen.
00:04:05.120 --> 00:04:07.919
Viele agile Projekte haben einen Backlog.
00:04:07.699 --> 00:04:12.739
ja, wir müssen ja eh alles umsetzen.
00:04:13.060 --> 00:04:15.139
Im Prinzip ist es schon dann kein agiles Projekt mehr.
00:04:15.219 --> 00:04:19.379
Agil heißt auch, dass der Scope flexibel gemanagt werden kann.
00:04:19.699 --> 00:04:22.500
Agilität verlangt enorm viel Abstimmung, und zwar Abschnitt.
00:04:22.939 --> 00:04:26.779
Stimmung zu Zeitpunkten, wo wir sie vielleicht nicht erwarten.
00:04:26.939 --> 00:04:30.860
Wenn ich mit einem Wasserfallprojekt arbeite, nochmal kurz für die Erinnerung, was bedeutet das?
00:04:30.939 --> 00:04:37.540
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.
00:04:37.620 --> 00:04:38.980
Also wie die Phasen genau aussehen.
00:04:39.300 --> 00:04:41.939
Da kann man unterschiedliche Ansätze wählen.
00:04:42.019 --> 00:04:45.300
Man kann auch natürlich Phasen immer wieder neu durchlaufen.
00:04:45.459 --> 00:04:52.259
Aber im Wesentlichen ist die Idee eines nicht agierten Projekts, eines Wasserfallprojekts, dass ich meine Definition vorab mache.
00:04:52.639 --> 00:05:03.920
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.
00:05:04.560 --> 00:05:17.079
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.
00:05:18.759 --> 00:05:22.360
quasi in die Richtung von diesem entsprechenden Feature komme.
00:05:23.319 --> 00:05:24.920
Wann das ist, weiß ich oft gar nicht.
00:05:25.000 --> 00:05:35.180
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.
00:05:35.259 --> 00:05:42.300
So funktioniert das normalerweise nicht, sodass ich in einem agil geführten Projekt mit sehr komplexem Environment oft Dinge.
00:05:42.620 --> 00:05:42.699
.
00:05:42.800 --> 00:05:45.680
verschieben dadurch, dass die externen Zulieferungen nicht passen.
00:05:46.000 --> 00:06:12.339
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.
00:06:13.139 --> 00:06:31.019
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.
00:06:31.339 --> 00:06:44.879
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.
00:06:45.500 --> 00:06:58.300
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.
00:06:58.199 --> 00:07:08.040
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?
00:07:07.839 --> 00:07:08.639
Output entsteht.
00:07:08.800 --> 00:07:12.560
Wohlgemerkt, ein korrekt geführtes Agiles Projekt hat dieses Problem nicht.
00:07:12.959 --> 00:07:26.639
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.
00:07:26.720 --> 00:07:28.399
Ist meine persönliche Meinung.
00:07:29.040 --> 00:07:39.800
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.
00:07:40.519 --> 00:07:47.240
Auf der Business-Ebene letzten Endes sehe ich oft in subseudo-agilen Projekten, dass es keine klaren Requirements gibt.
00:07:47.639 --> 00:08:04.418
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.
00:08:04.579 --> 00:08:09.939
Das heißt, wir beginnen in so einem Projekt ohne klare Requirements und das ist eben nicht agil.
00:08:10.420 --> 00:08:12.339
Das ist chaotisch.
00:08:12.819 --> 00:08:24.899
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.
00:08:25.279 --> 00:08:26.319
funktioniert fast nie.
00:08:27.038 --> 00:08:34.080
Der einzige Effekt, den das hat, ist, dass Budget und Zeitplan natürlich völlig unvorhersehbar werden in so einem Setting.
00:08:34.399 --> 00:08:40.399
Wenn ich nicht von vornherein weiß, worauf ich eigentlich hinaus will, kann ich auch nicht wirklich abschätzen, wenn ich damit fertig bin.
00:08:40.639 --> 00:08:42.480
Gleichzeitig ist es aber so.
00:08:42.820 --> 00:08:54.580
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.
00:08:54.919 --> 00:08:55.958
Das kann man machen.
00:08:56.120 --> 00:09:00.440
Man kann sagen, ich mache ein agiles Projekt, ich fixiere Budget und Zeitplan, also Deadline quasi.
00:09:00.600 --> 00:09:12.379
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.
00:09:12.980 --> 00:09:22.820
Zweite Symptom oder zweite Smell quasi für falsche, agile Projekte oder falsch verstandene Agilität ist, dass es keinen dedizierten Product Owner gibt.
00:09:23.379 --> 00:09:30.779
Ein Product Owner Ist eine der Kernvoraussetzungen für Agilität.
00:09:31.659 --> 00:09:40.159
Der Product Owner ist letzten Endes in jedem agilen Projekt, sei das Kanban, sei das Scrum, Die Person, die berechtigt ist, Produktentscheidungen zu treffen.
00:09:40.559 --> 00:10:02.360
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.
00:10:02.600 --> 00:10:10.360
Ich kann alle Beteiligten fragen, ich kann mir vom Boss quasi die Unterschrift holen, dass das genau das Produkt ist, das wir bauen wollen.
00:10:10.519 --> 00:10:12.279
In einem agilen Projekt kann ich das so nicht machen.
00:10:12.720 --> 00:10:22.960
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.
00:10:23.039 --> 00:10:26.399
Dann owned er gar nichts, dann ist er ein glorifizierter Sekretär.
00:10:27.059 --> 00:10:44.559
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.
00:10:44.720 --> 00:10:50.879
Klar werden sie für die großen Entscheidungen entsprechende Stakeholders hinzuziehen.
00:10:51.200 --> 00:10:56.879
Aber es ist unmöglich, dass alles eskaliert auf die Führungsebene und die Verantwortung unklar bleibt.
00:10:56.960 --> 00:11:00.159
Der Product Owner muss da sein, sonst ist es auch kein agiles Projekt.
00:11:00.240 --> 00:11:03.039
Dann nennen wir es agil, aber dann ist es nur chaotisch.
00:11:03.379 --> 00:11:08.659
Was auch oft vergessen wird und wofür auch der Product Autonomi zuständig ist, ist tatsächlich die Produktvision.
00:11:08.899 --> 00:11:12.500
Das heißt, nicht irgendwie ein fuzzy Feeling, was quasi.
00:11:12.740 --> 00:11:13.059
.
00:11:13.059 --> 00:11:13.379
.
00:11:13.299 --> 00:11:22.259
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.
00:11:22.259 --> 00:11:27.698
Und welchen Business Value oder welchen Geschäftszielen soll sich dieses Produkt quasi unterordnen.
00:11:27.778 --> 00:11:33.659
Das ist auch eine wichtige Leitlinie dafür, wonach der Product Owner dann seine Entscheidungen treffen will.
00:11:33.740 --> 00:11:40.779
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.
00:11:40.940 --> 00:11:54.919
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.
00:11:55.078 --> 00:12:25.299
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.
00:12:25.899 --> 00:12:30.940
Dann werden die notwendigerweise, selbst wenn sie sehr, sehr sorgfältig arbeiten, primär lokal optimieren.
00:12:31.179 --> 00:12:43.299
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.
00:12:43.460 --> 00:12:57.419
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.
00:12:57.620 --> 00:12:59.778
Aber schneller mit weniger Kosten.
00:13:00.100 --> 00:13:05.220
Mit einem klassischen Projekt ist das unmöglich, kann ich auf der Hälfte von einem klassischen Projekt sagen, ich ändere nochmal Fundamentales.
00:13:05.620 --> 00:13:06.339
Das wird nicht klappen.
00:13:06.500 --> 00:13:10.899
Mit einem agilen Projekt kann ich das machen und diesen Vorteil muss ich natürlich versuchen zu enden.
00:13:10.980 --> 00:13:12.179
Dazu brauche ich ein Product-Onnet.
00:13:12.299 --> 00:13:13.899
Und dazu brauche ich eine Produktvision.
00:13:14.458 --> 00:13:27.740
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.
00:13:27.820 --> 00:13:38.458
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.
00:13:39.019 --> 00:13:41.500
Bin ich eigentlich schon nicht mehr wirklich agil.
00:13:41.799 --> 00:13:53.480
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.
00:13:54.339 --> 00:14:02.500
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.
00:14:03.740 --> 00:14:14.460
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.
00:14:14.620 --> 00:14:24.759
In einem agilen Projekt, wenn rechtliche Prüfung ein Thema ist, ein kontinuiertes Thema, brauche ich eigentlich in meinem Team einen Juristen.
00:14:25.240 --> 00:14:27.000
Das ist cross-funktionales Team.
00:14:27.159 --> 00:14:31.879
Ein cross-funktionales Team heißt nicht einfach nur in meinem Entwicklungsteam ist auch eine.
00:14:32.159 --> 00:14:33.519
eine kleine QA-Person.
00:14:34.159 --> 00:14:43.200
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.
00:14:43.440 --> 00:14:54.679
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.
00:14:54.840 --> 00:14:58.360
Ist für ein agiles Projekt eigentlich oft ein Todesstoßen.
00:14:58.519 --> 00:15:02.279
Weil jetzt habe ich plötzlich einen coolen Ein cooles Backlog.
00:15:02.519 --> 00:15:07.320
Hab Sprint Velocity Schätzungen zum Beispiel kann Deadlines projizieren.
00:15:07.639 --> 00:15:10.919
Also Delivery ein Deadlines projizieren und so weiter und so fort.
00:15:11.318 --> 00:15:18.039
Aber die externen Abhängigkeiten, die ich zusätzlich drin habe, machen das alles obsolet.
00:15:18.159 --> 00:15:28.559
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.
00:15:28.720 --> 00:15:37.600
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.
00:15:37.759 --> 00:15:44.679
Und die ganze Illusion, dass man das mit dead Deadlines und Commitments und so weiter lösen könnte in der Firma.
00:15:45.399 --> 00:15:48.278
Sorry, den Zahn muss ich euch ziehen, habe ich noch nie gesehen.
00:15:48.919 --> 00:15:55.480
Die meisten Softwareprojekte in Firmen laufen relativ isoliert, die anderen Abteilungen haben Besseres zu tun, haben eigene Zahnen.
00:15:55.839 --> 00:16:03.198
Ziele und diese ganzen Zulieferungen sind mehr so auf Gnadenbasis und haben deswegen überhaupt keinerlei Committed-Deadlines.
00:16:03.278 --> 00:16:11.220
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.
00:16:11.299 --> 00:16:14.259
Und meine eigene Planbarkeit in meinem Projekt geht vollständig verloren.
00:16:14.340 --> 00:16:19.139
Also kross-funktionales Team, absolut essentiell, sonst ist es eigentlich kein agiles Projekt.
00:16:19.320 --> 00:16:27.240
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.
00:16:27.320 --> 00:16:30.120
Also ich möchte zwar meine Features und meine.
00:16:31.120 --> 00:16:38.559
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.
00:16:38.960 --> 00:16:41.279
Großer Vorteil von agilen Projekten.
00:16:41.259 --> 00:16:44.379
Möchte ich aber trotzdem auch Themen bündeln können.
00:16:44.458 --> 00:16:53.039
Also ich möchte im Prinzip sagen können, okay, wenn mir jetzt in diesem Sprint das Thema Login oder die Menüstruktur angehen.
00:16:53.200 --> 00:16:57.759
Dann lass uns mal die Themen, die dazugehören, ein bisschen zusammenbringen, damit wir nicht so viele Konflex.
00:16:58.000 --> 00:16:58.080
.
00:16:58.039 --> 00:16:59.159
Kontextwechsel haben.
00:16:59.320 --> 00:17:06.838
Damit also das Entwicklungsteam nicht fünfmal die gleiche Stelle anfasst und nicht fünfmal über bestimmte Dinge nachdenken muss.
00:17:06.920 --> 00:17:09.400
Man will ja eigentlich so Kontextwechsel ein bisschen minimieren.
00:17:09.199 --> 00:17:15.278
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.
00:17:15.599 --> 00:17:20.880
In chaotischen Projekten ist es oft der Fall, dass ich es nicht bündeln kann, weil niemand da war.
00:17:20.880 --> 00:17:26.240
der tatsächlich in der Lage wäre, jetzt diese ganzen Themen gleichzeitig zu oder rechtzeitig zu definieren.
00:17:26.400 --> 00:17:32.079
Und dann entwickle ich letzten Endes immer das, was fertig definiert ist, weil ich mit der Definition permanent hinten dran bin.
00:17:32.299 --> 00:17:37.019
Und das bedingt dann relativ viele Kontextwechsel und macht die Entwicklung langsam.
00:17:37.259 --> 00:17:46.779
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.
00:17:47.059 --> 00:17:50.579
dazu gekommen, aber ich habe auch keine Ressourcen, weil ich habe noch 50 andere Jobs.
00:17:50.740 --> 00:17:52.819
Das macht ein Projekt auch ineffizient.
00:17:53.059 --> 00:17:59.059
Was auch so ein anti-agiles Smell ist, auch sind riesige User-Stories mit zig querverweisen.
00:17:59.140 --> 00:18:18.180
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.
00:18:18.660 --> 00:18:25.700
Normalerweise versucht man im agilen Projekt, User Stories so weit voneinander zu entkoppeln, wie man nur eben kann.
00:18:25.940 --> 00:18:29.298
Und oft geht das auch, aber das ist in einer gewissen Weise eine Kunst.
00:18:29.538 --> 00:18:30.659
Ein Product Owner bzw.
00:18:30.980 --> 00:18:43.079
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.
00:18:43.240 --> 00:18:51.880
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.
00:18:52.359 --> 00:18:59.440
Einfach Weil man versucht hat, eine Spezifikation zu schreiben und die auf 20 Storys dann aufzusplitten, damit es nicht wie eine Spezifikation aussieht.
00:18:59.519 --> 00:19:22.039
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.
00:19:22.880 --> 00:19:25.599
Letzte anti-agile Smell, auf den ich ein bisschen eingehen will, ist Scope Cryp.
00:19:25.680 --> 00:19:27.119
Scope Cryp haben wir in jedem Projekt.
00:19:27.680 --> 00:19:34.720
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.
00:19:35.039 --> 00:19:37.680
Und natürlich wird man unter Umständen das dann trotzdem machen.
00:19:38.119 --> 00:19:41.319
Je nachdem, wie wahrscheinlich auf welcher Ebene der Manager operiert.
00:19:41.559 --> 00:19:50.920
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.
00:19:51.200 --> 00:19:55.920
Oft sind das so, gerade aus der Management-Ebene, kommt ich hätte gerne noch so eine kleine Änderung.
00:19:56.240 --> 00:19:58.640
Ich kann gar nicht mehr zählen, wie oft ich das gehört habe.
00:19:58.799 --> 00:19:59.920
Meistens sind das ziemlich.
00:20:00.160 --> 00:20:06.799
drastische Reworks, die man da hat, weil irgendjemand eine gute Idee hatte oder auch eine weniger gute Idee.
00:20:06.880 --> 00:20:11.599
Das Businessrisiko dahinter ist natürlich, hey, Budgetüberschreitung, Verzögerung.
00:20:11.919 --> 00:20:15.279
potenzieller Marktvorteilsverlust, wenn ich nicht rechtzeitig mit der App an die Stadt gehe.
00:20:15.359 --> 00:20:17.440
Also Scope Creep ist immer ein Problem.
00:20:17.679 --> 00:20:27.559
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.
00:20:27.640 --> 00:20:30.839
Also letzten Endes wird der Agilität als glorifiziertes Scope Creep gesehen.
00:20:30.920 --> 00:20:34.200
Ich kann zu jedem Zeitpunkt auch was einkippen und einbauen und so weiter.
00:20:34.539 --> 00:20:36.380
Das sehe ich persönlich völlig anders.
00:20:36.619 --> 00:20:40.859
Der große Vorteil von agilen Projekten ist, dass ich agile Sachen wegblassen kann.
00:20:41.099 --> 00:20:43.900
Nicht unbedingt, dass ich agile Sachen reinbringen kann.
00:20:44.299 --> 00:20:57.460
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.
00:20:57.539 --> 00:21:10.259
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.
00:21:11.220 --> 00:21:17.140
Und ich Es ist faszinierend, wie viele Menschen denken, es ist ja ein agiles Projekt, da kann man das ja machen.
00:21:17.220 --> 00:21:20.339
Nein, auch ein agiles Projekt wird durch mehr Features größer.
00:21:20.980 --> 00:21:26.740
Und ein größeres Projekt, auch wenn es agil genannt wird, dauert durch mehr Größe, mehr.
00:21:27.259 --> 00:21:28.460
Scope länger.
00:21:28.779 --> 00:21:35.740
Und agil ist nicht die Wunderwaffe, mit der ich plötzlich beliebigen Scope in beliebige Timelines mit beliebigem Budget implementieren kann.
00:21:35.900 --> 00:21:40.940
Dieses gloriose Dreieck Timescope Budget, das gilt hier ganz genauso.
00:21:42.019 --> 00:21:47.140
Ich kann nicht Agilität als Vorwand dafür nehmen, dass ich den Scope ändere und die gleichen Deadlines erwarte.
00:21:47.299 --> 00:21:49.140
Wird aber doch trotzdem down gemacht.
00:21:49.220 --> 00:21:51.539
Und spätestens dann ist es eigentlich kein agiles Projekt mehr.
00:21:51.619 --> 00:21:56.099
Dann ist es, ja, ich weiß gar nicht, wie ich das nennen soll, auch kein Wasserfall, es ist ein Shit-Projekt.
00:21:56.859 --> 00:22:03.180
Gut, jetzt sind wir sehr intensiv darauf eingegangen, wann ein Projekt eigentlich nicht agil ist, obwohl es agil genannt wird.
00:22:03.339 --> 00:22:07.180
Wann macht es denn Sinn, dass wir im Vornell sagen, wir machen Wasserfall oder was anderes?
00:22:07.259 --> 00:22:07.819
Es gibt ja.
00:22:08.140 --> 00:22:08.460
.
00:22:08.179 --> 00:22:09.538
andere Ansätze auch.
00:22:08.460 --> 00:22:08.779
.
00:22:09.619 --> 00:22:12.898
Ich sage, ich gruppiere die jetzt mal alle unter Wasserfall, einen nicht agilen Ansatz.
00:22:13.298 --> 00:22:14.898
Wann macht es Sinn, das zu sagen?
00:22:14.980 --> 00:22:21.380
Und von vornherein auf das Label agil und aber auch auf all die herren Ansprüche zu verzichten, die damit einhergehen.
00:22:21.519 --> 00:22:27.119
Das kann schon dann Sinn machen, wenn ich total stabile, bekannte Anforderungen habe.
00:22:27.599 --> 00:22:32.960
Wenn ich gerade so interne Architekturprojekte, wo ich sage, ich muss API A mit API B ver.
00:22:33.038 --> 00:22:33.119
.
00:22:33.259 --> 00:22:37.419
verbinden, um Report C zu generieren, da brauche ich kein agiles Projekt aufsetzen.
00:22:37.579 --> 00:22:47.099
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.
00:22:47.839 --> 00:22:52.400
Dann sind die Prozesse klar, es ist nicht erwartet, dass irgendwelche Innovationen passieren.
00:22:52.558 --> 00:23:00.640
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.
00:23:00.720 --> 00:23:08.680
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.
00:23:08.839 --> 00:23:12.200
Dann kann ich total unagil arbeiten letzten Endes.
00:23:12.278 --> 00:23:16.839
Ich beschreibe einmal vollständig, was ich machen will und dann setze ich eine, zwei, drei, vier Wochen hin und setze das um.
00:23:16.919 --> 00:23:22.038
Das ist insbesondere eben wahr für relativ kleine Projekte, wo ich sage, ich habe eine sehr, sehr klare.
00:23:22.440 --> 00:23:27.960
Kleine Initiative und da brauche ich kein agiles Backlog Product Honor und all diese Dinge aufsetzen.
00:23:28.119 --> 00:23:45.339
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.
00:23:45.419 --> 00:23:48.859
Und diese ganzen Klärungen kann ich viel schöner machen, wenn ich eine echte Spezifikation habe.
00:23:49.019 --> 00:23:50.460
Da muss man sich wirklich nichts vormachen.
00:23:50.619 --> 00:23:53.099
Eine Spezifikation ist ein tolles Kommunikationsmittel.
00:23:53.179 --> 00:23:56.660
Ein Backlog ist Ist schon ein deutlich weniger tolles Kommunikationsmittel.
00:23:56.900 --> 00:24:08.419
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.
00:24:09.419 --> 00:24:38.419
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.
00:24:39.259 --> 00:24:44.859
Quasi Prüfung durch bestimmte Behörden initiieren kann, während das Projekt läuft.
00:24:44.940 --> 00:24:46.940
Das wird mit einem agilen Projekt unglaublich schwer sein.
00:24:47.019 --> 00:24:53.740
Also Bereich Medizinprodukte, Luftfahrt, Automotive, da kann man agil arbeiten, aber eben nur.
00:24:54.160 --> 00:24:57.279
Außerhalb des Bereiches, der von diesen Problematiken erfasst werden.
00:24:57.359 --> 00:25:00.079
Und da kann dann hybride Ansätze total Sinn machen.
00:25:01.039 --> 00:25:02.480
Fix-Preisprojekte.
00:25:02.720 --> 00:25:06.319
Ganz ehrlich, Leute, Fix-Preis-Projekte agil zu machen ist verrückt.
00:25:06.559 --> 00:25:07.279
Ich hab.
00:25:07.519 --> 00:25:09.440
Auch das noch nie funktionieren sehen.
00:25:10.240 --> 00:25:16.480
Bitte Feedback, schickt mir eure Erfolgsstories von agilen Fixpreis-Projekten und damit meine ich einen Fix-Preis.
00:25:16.638 --> 00:25:22.079
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.
00:25:22.359 --> 00:25:25.480
Das ist toll, das Agile Contracting, ganz anderes Thema, kann man alles machen.
00:25:25.638 --> 00:25:31.000
hey, dieses Projekt kostet einmal 4,3 Millionen und jetzt machen wir es agil.
00:25:31.558 --> 00:25:32.759
Wie soll das gehen?
00:25:33.079 --> 00:25:37.000
Ein Fixpreis basiert auf einer fertigen, vollständigen Spezifikation.
00:25:37.679 --> 00:25:49.440
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.
00:25:49.519 --> 00:26:02.038
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.
00:26:03.798 --> 00:26:08.798
Gut, die Frage ist, wie vermeidet man dann Budgetrisiko bei ambitionierten Projekten.
00:26:08.960 --> 00:26:25.579
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.
00:26:25.740 --> 00:26:33.579
Oder man macht agiles Contracting und sagt, ich habe Fixpreis für Work-Packages, die quasi einem Sprint oder sowas entsprechen.
00:26:33.740 --> 00:26:55.019
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.
00:26:55.579 --> 00:27:05.980
Okay, an der Stelle macht es vielleicht Sinn, dass ich eher ein Wasserfallprojekt aufsetze.
00:27:07.058 --> 00:27:11.380
wenn ich auf Hardware-Bestellung warten muss oder auf Hardware-Entwicklung warten muss.
00:27:11.460 --> 00:27:19.220
Also wenn ich in einem Embedded-Bereich unterwegs bin und ich arbeite parallel damit, dass die Hardware überhaupt erst entwickelt muss werden.
00:27:19.720 --> 00:27:23.240
Das heißt, ich muss mit Emulatoren arbeiten und dann irgendwann auf der realen Hardware testen.
00:27:23.319 --> 00:27:25.720
Es ist agil relativ schwierig zu koordinieren, sowas.
00:27:25.880 --> 00:27:33.799
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.
00:27:34.319 --> 00:27:36.000
Die ich nicht kontrollieren kann.
00:27:36.480 --> 00:27:43.440
Und wenn ich ausreichend solche externen Abhängigkeiten habe, ist mein Projekt definitionsgemäß nicht mehr agil.
00:27:43.680 --> 00:27:46.960
Wenn ich dann noch das Agile-Label ranschreibe, wird es chaotisch.
00:27:47.759 --> 00:27:48.720
Dann schreibe ich lieber das.
00:27:49.240 --> 00:27:56.119
Label nicht dran und versuche mir eine andere Projektmanagement-Methodik anzueignen, die diesem Problem Rechnung trägt.
00:27:56.599 --> 00:28:12.038
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.
00:28:12.200 --> 00:28:16.480
Und dann kann ich sagen, Okay, so kann ich das unter Kontrolle kriegen.
00:28:16.558 --> 00:28:18.638
Als agiles Projekt muss ich das nicht führen.
00:28:18.880 --> 00:28:26.240
Auch Projekte mit wahnsinnig hohem Dokumentationsbedarf oder Prüfungsbedarf sind oft sehr ungeeignet, um sie so richtig agil zu führen.
00:28:26.398 --> 00:28:28.079
Also wenn die Dokumentation Teil des Potentiens.
00:28:28.599 --> 00:28:45.759
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.
00:28:46.720 --> 00:28:50.558
In manchen Bereichen muss man tatsächlich bis runter zu Pseudocoden in Dokumentation schreiben.
00:28:50.720 --> 00:28:58.079
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.
00:28:58.440 --> 00:29:02.119
Versucht, weil das Gesamtkunstwerk dann eben nicht die Summe des Storys ist.
00:29:02.200 --> 00:29:09.960
Da muss immer noch viel Arbeit investiert werden, damit es ein Gesamtbild ergibt, wenn ich am Ende der Entwicklung quasi die Produktdokumentation erstelle.
00:29:10.519 --> 00:29:19.119
Also Auditfähigkeit, Nachvollziehbarkeiten, Rechnung, Regulatorische Compliance sind immer so Trigger, wo ich sage, okay, eventuell muss ich zumindest ein Teilprojekt unagil führen.
00:29:19.759 --> 00:29:26.000
Eine Frage, die sich natürlich aufdrängt, ich habe ein paar Mal das Thema Kosten auch angesprochen, ist, habe ich denn jetzt.
00:29:26.259 --> 00:29:37.538
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.
00:29:27.839 --> 00:29:27.919
.
00:29:38.179 --> 00:29:46.220
Aber Die Kostenstruktur ist bei agilen Projekten anders als bei Wasserfallprojekten oder nicht agilen Projekten.
00:29:46.460 --> 00:29:52.420
Die Kosten fallen anders an Und sie sind auf andere Art kontrollierbar.
00:29:52.500 --> 00:29:57.619
Und je nachdem, was man braucht, kann das eine oder das andere deutlich besser oder schlechter sein.
00:29:57.700 --> 00:30:02.019
Also wenn ich jetzt über agile Iterationen nachdenke, dann habe ich.
00:30:02.259 --> 00:30:03.779
Ein gewissen Overhead.
00:30:03.940 --> 00:30:05.538
Das ist nicht zu leugnen.
00:30:05.619 --> 00:30:15.619
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.
00:30:16.299 --> 00:30:22.299
Und auf beide Projekte setze ich fähige Projektmanager, Product Owner und so weiter.
00:30:22.460 --> 00:30:25.160
Dann ist Das agile Projekt wahrscheinlich teurer.
00:30:25.319 --> 00:30:35.680
Weil der Overhead der Strukturierung in User Stories und der Möglichkeit, quasi diese Sachen individuell zu releasen, Sprint-Reviews und so weiter.
00:30:35.920 --> 00:30:41.839
Das wird höhere laufende Kosten verursachen, die über die Gesamtprojektphase auch wahrscheinlich insgesamt höher sind.
00:30:42.000 --> 00:30:42.880
Wie viel höher.
00:30:43.039 --> 00:30:43.119
.
00:30:43.059 --> 00:30:52.180
hängt von extrem vielen Faktoren ab, aber agile Projekte sind nicht billiger, wenn man exakt den gleichen Scope zugrunde legt.
00:30:52.140 --> 00:30:56.460
Der Vorteil ist, in agilen Projekten habe ich sehr, sehr frühes Feedback über einzelne Features.
00:30:56.619 --> 00:31:01.339
Alles, was fertig ist, kann ich mir anschauen und ich habe Flexibilität und kann dann.
00:31:01.579 --> 00:31:01.900
.
00:31:01.660 --> 00:31:07.420
sagen, okay, das Feature ändern wir nochmal, dafür nehmen wir dieses Feature raus oder wir machen insgesamt den Scope kleiner und so weiter.
00:31:01.900 --> 00:31:02.220
.
00:31:07.500 --> 00:31:21.180
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.
00:31:21.519 --> 00:31:34.880
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.
00:31:35.119 --> 00:31:38.440
Aber bevor Before die Kommentar-Section vorläuft.
00:31:38.599 --> 00:31:39.480
Großes Aber.
00:31:40.200 --> 00:31:44.119
Wann kenne ich schon wirklich die Anforderungen im Detail bis zum Ende?
00:31:43.960 --> 00:31:47.640
In einer Form die verlässliche Abschätzung des Aufwands möglich macht.
00:31:47.799 --> 00:31:51.880
Und das ist, warum agile Projekte in den Kostenthemen fast immer gewinnen.
00:31:52.519 --> 00:31:58.599
Wenn ich die Annahme treffe, ich weiß genau, was meine Anforderungen sind, ich kann sie genau abschätzen, habe ich kalkuliert.
00:31:59.680 --> 00:32:01.839
Kleinere Kosten bei Big Bang-Entwicklung.
00:32:02.000 --> 00:32:04.160
Diese Annahme ist aber fast nie wahr.
00:32:04.400 --> 00:32:11.680
Erstens ist fast nie alles bekannt und zweitens sind Entwickler unfassbar schlecht im Schätzen.
00:32:12.240 --> 00:32:14.319
Insbesondere im Schätzen von Zeitaufwand.
00:32:14.400 --> 00:32:16.559
Und drittens gibt es immer Unwägbarkeiten.
00:32:16.720 --> 00:32:25.240
Also, da muss ich sagen, die Kostenfrage sollte nicht einen entscheidenden Einfluss haben auf die auf die Projektstruktur.
00:32:25.559 --> 00:32:28.440
Ich kann nicht verlässlich sagen, dass Big Bang billiger ist.
00:32:28.519 --> 00:32:32.839
Ich kann eigentlich verlässlich sagen, dass es wahrscheinlich problematischere Kostenstruktur erzeugt.
00:32:33.079 --> 00:32:37.079
Es ist wirklich keine finanzielle Betrachtung aus meiner Sicht.
00:32:37.640 --> 00:32:50.240
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.
00:32:50.559 --> 00:32:55.559
Dann stellt sich natürlich logischerweise die Frage, Kann ich das irgendwie zusammenbringen?
00:32:55.720 --> 00:32:58.599
Kann ich irgendwie sagen, ich will best of both worlds.
00:32:59.480 --> 00:33:10.799
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.
00:33:11.920 --> 00:33:13.359
Das stimmt in einer gewissen Weise.
00:33:13.440 --> 00:33:18.880
Also in dem Moment, wo ich, wenn Hybrid heißt, ich verwische beide Ansätze, dann habe ich von beiden das Schlechteste.
00:33:19.519 --> 00:33:21.519
Agilität lebt davon, dass man sie.
00:33:22.039 --> 00:33:27.319
wirklich konsequent umsetzt, nur dann erzeugt sie die Vorteile, die sie ohne Zweifel hat.
00:33:27.559 --> 00:33:31.559
Das gleiche gilt eigentlich in einer gewissen Weise auch für Wasserfallentwicklungen.
00:33:31.640 --> 00:33:35.240
Auch die hat ihre echten Benefits, nur wenn ich sie wirklich konsequent liebe und umsetze.
00:33:35.480 --> 00:33:36.599
Kann man es trotzdem irgendwie zusammen?
00:33:36.960 --> 00:33:55.880
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.
00:33:56.440 --> 00:34:06.119
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.
00:34:06.359 --> 00:34:09.000
Und das ist auch, das ist quasi der Kern unserer Idee.
00:34:09.239 --> 00:34:12.360
Wenn das nicht dabei ist, dann brauchen wir es nicht machen.
00:34:12.440 --> 00:34:15.719
Und das enthält meistens schon auch die Kernmechanismen von diesem Produkt.
00:34:15.800 --> 00:34:21.960
Also nehmen wir mal an, die Firma möchte gerne eine App umsetzen oder irgendein Softwareprodukt, was nach außen wirkt.
00:34:22.119 --> 00:34:26.940
Dann habe ich eine bestimmte Idee, ich habe bestimmte Mechanismen, die unausweichlich da drin sein müssen.
00:34:27.099 --> 00:34:38.378
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.
00:34:38.579 --> 00:34:57.579
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.
00:34:59.019 --> 00:35:04.780
Wenn das der Fall ist, dann kann ich sagen, okay, ich mache ein klassisches Konzept, diese Kernidee.
00:35:05.099 --> 00:35:08.300
Ich mache eine vollständige Spezifikation.
00:35:08.820 --> 00:35:20.099
Dieser Kernidee, auch ruhig mit klassischen Spezifikationsmechanismen, ich sage jetzt mal Pflichtenheft oder ähnliche Tools, die sind bewährt, die sind auch nicht schlecht.
00:35:20.179 --> 00:35:33.820
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.
00:35:33.900 --> 00:35:38.139
Das heißt, ich könnte eine klassische Konzeptphase haben für mein Kernprodukt.
00:35:38.659 --> 00:35:44.019
Könnt ihr dieses Konzept verwenden, um regulatorische Prüfungen zu machen, vielleicht auch ein Fixpreis-Projekt anzukurbeln.
00:35:44.099 --> 00:35:48.340
Wenn ich so eine vollständige Spezifikation habe, lässt sich vielleicht ein Anbieter auf Fixpreis ein.
00:35:48.659 --> 00:35:56.539
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.
00:35:56.780 --> 00:36:02.139
Meistens haben Fix-Preis-Projekte sehr unangenehme Konsequenzen für beide Seiten, weswegen ich sie eigentlich wirklich gar nicht merke.
00:36:02.219 --> 00:36:06.619
Also so normale Fix-Preis-Projekte, wo ich sage, ich habe ein Produkt und einen Preis.
00:36:07.099 --> 00:36:08.139
Die haben wirklich sehr, sehr.
00:36:08.579 --> 00:36:17.699
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.
00:36:17.940 --> 00:36:27.900
Ich könnte dieses diese Spezifikation vielleicht sogar auch durch einen externen Dienstleister in User Stories konvertieren lassen, die unmittelbar Feedback erlauben.
00:36:28.000 --> 00:36:32.320
Dass ich zum Beispiel das Produkt intern schon promoten kann oder Leuten zeigen kann.
00:36:32.480 --> 00:36:36.000
Ich kann natürlich nicht auf Basis des Feedbacks Anpassungen vornehmen an der Kernidee.
00:36:36.639 --> 00:36:40.079
Dann bin ich wieder nicht mehr in meinem Wasserfallmodus.
00:36:40.239 --> 00:36:42.400
Aber ich kann es grundsätzlich mit agilen Mitteln.
00:36:42.920 --> 00:36:54.039
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.
00:36:54.199 --> 00:36:57.480
Wir wissen, die regulatorischen Prüfungen, Zulieferungen, alles ist fertig.
00:36:57.760 --> 00:36:59.840
Das haben wir über unseren Wasserfall abgebildet.
00:37:00.079 --> 00:37:03.360
Jetzt kann ich sagen, agil, wir gehen agil Richtung 2.
00:37:03.440 --> 00:37:03.519
0.
00:37:03.920 --> 00:37:06.480
Weil jetzt brauchen wir die schnelle Anpassung an Marktfeedback.
00:37:06.559 --> 00:37:12.480
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.
00:37:12.599 --> 00:37:14.440
Und zwei, das ist fast nie eine gute Idee.
00:37:14.599 --> 00:37:25.559
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.
00:37:25.719 --> 00:37:27.320
Und das ist für mich ein sehr, sehr.
00:37:27.659 --> 00:37:29.019
Vielversprechendes Hybridmodell.
00:37:29.099 --> 00:37:33.179
Für die agile Umsetzung würde man dann auch natürlich kein Fixpreis-Projekt sagen.
00:37:33.579 --> 00:37:48.019
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.
00:37:48.179 --> 00:37:52.019
Alternativ kann man auch sagen, man hat iterative Entwicklung und sehr feste Meilensteine.
00:37:52.099 --> 00:38:00.300
Das bedeutet aber letzten Endes auch nur, dass ich ein etwas Wasserfalliges, spezifiziertes Dass ich meine spezifizierten Meilensteine agil runterbreche.
00:38:00.380 --> 00:38:02.699
Das ist eine andere Art, das zu betrachten und zu kombinieren.
00:38:03.019 --> 00:38:05.179
Kann auch ein sinnvoller Hybridansatz sein.
00:38:05.579 --> 00:38:09.500
Im Hybridansatz habe ich trotzdem eine wahnsinnig hohe Verantwortung beim Product-Oner.
00:38:09.579 --> 00:38:12.380
Ich kann deswegen nicht auf den Product-Oner verzichten, weil für den agilen Teil brauche ich.
00:38:13.300 --> 00:38:15.300
Und das muss dann auch der gleiche sein.
00:38:15.460 --> 00:38:26.260
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.
00:38:26.420 --> 00:38:27.300
Letzten Endes geht es da.
00:38:27.579 --> 00:38:38.539
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.
00:38:38.940 --> 00:38:46.219
Und dann eine Balance zu finden zwischen Planungssicherheit, Flexibilität und Marktorientierung.
00:38:46.539 --> 00:38:53.659
Voll agile Entwicklung, Kanban ist eigentlich die hundertprozentige Flexibilität, da kann ich quasi tagesweise ändern, was ich machen will.
00:38:53.300 --> 00:39:02.420
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.
00:39:02.500 --> 00:39:06.340
Also was für Leute habe ich und welche Rollen können die sinnvoll ausfüllen.
00:39:06.420 --> 00:39:14.619
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.
00:39:15.179 --> 00:39:29.659
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.
00:39:29.980 --> 00:39:32.539
Niemand ist auf dem Stand einfach ein guter Product Owner.
00:39:34.019 --> 00:39:41.139
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.
00:39:41.380 --> 00:39:42.980
AG das Projekt mit völlig.
00:39:43.340 --> 00:39:54.619
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.
00:39:54.699 --> 00:39:57.099
Da kommt es zu so einer permanenten internen Sabotage.
00:39:57.579 --> 00:39:59.460
Und das will man natürlich nicht haben.
00:39:59.860 --> 00:40:02.659
Long Story Short, Agilität ist einfach ein Werkzeug.
00:40:02.980 --> 00:40:15.760
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?
00:40:15.760 --> 00:40:18.880
Ich habe unzählige agile Projekte geführt.
00:40:18.880 --> 00:40:27.199
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.
00:40:27.559 --> 00:40:27.960
wollen.
00:40:28.039 --> 00:40:35.400
Und jetzt bist du dummerweise in diese pseudoagile Welt geboren und solche Projekte haben es oft schwierig.
00:40:35.920 --> 00:40:41.119
Also ein bisschen Mut zur ehrlichen Analyse, was braucht dieses Wort dieses Projekt wirklich?
00:40:41.440 --> 00:40:43.199
Sind die Anforderungen klar und stabil?
00:40:43.980 --> 00:40:46.539
Brauche ich Flexibilität für Marktfeedback?
00:40:46.860 --> 00:40:49.420
Ist Budget und Risiko der Hauptfaktor hier?
00:40:49.579 --> 00:40:53.019
Also ist Budget overall das wichtigste Kriterium?
00:40:53.340 --> 00:40:56.780
Habe ich Ownership und Entscheidungskraft in meiner Firma?
00:40:56.940 --> 00:41:02.059
vorhanden, habe ich jemanden, den ich als Product Owner einsetzen könne könnte.
00:41:03.099 --> 00:41:06.619
Das sind Fragen, die man sich ehrlich stellen muss pro Projektbeginn.
00:41:06.780 --> 00:41:08.780
Und dann kann man die Weichen richtig stellen.
00:41:08.858 --> 00:41:25.780
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.
00:41:26.260 --> 00:41:31.619
Und sehr oft ist es nicht die komplexe Technologie, die das schwierig macht.
00:41:31.699 --> 00:41:50.679
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.
00:41:51.320 --> 00:41:57.239
Oder die Struktur aufsetzen, die optimal ist, gegeben unsere Situation.
00:41:58.199 --> 00:42:03.599
Am Ende wollen wir den viel zitierten Business Value optimieren.
00:42:04.000 --> 00:42:14.000
Also wir wollen Wert schaffen für die Firma und gleichzeitig das Budget halbwegs unter Kontrolle halten und den Markteintritt nicht verpassen.
00:42:14.119 --> 00:42:21.719
Und die Methodik und die Projektstruktur sind Werkzeuge, die dieses Ziel erreichen können.
00:42:21.880 --> 00:42:27.559
Sie sind nicht Ideologien, die um jeden Preis einfach so oder so gelebt werden sollten.
