Multi-Team Projektmanagement: Wasserfall notwendig oder Agilität möglich?
Ein Projekt definiert sich u.a. durch die Einzigartigkeit. Etwas, was zuvor so noch nicht gemacht wurde. Je größer das einzelne Projekt ist, desto schwieriger ist es, dieses zu managen und den Erfolg zu sichern. Ein maßgeblicher Faktor der Komplexität stellt auch die Anzahl der involvierten Teams und Mitarbeiter dar. Zwar trägt jeder seinen Teil zum Projekt bei, aber jeder hat auch Fragen und Fortschritt zu reporten. Und all diese Fäden werden von einem Projektmanager/in zusammengehalten.
Doch wie werden solche großen Multi-Team-Projekte gemanagt? Worauf kommt es an und was sind die größten Herausforderungen? Wie hält man alle Projektbeteiligten konstant auf dem aktuellen Stand, ohne jeden dauerhaft zu nerven? Wie viel muss bei solchen Projekten dokumentiert werden? Und wie stellt man eine gute Balance zwischen ständig ändernden Anforderungen und möglichen Overengineering sicher?
Diese und weitere Fragen stellen wir unserem Gast Stephan Strack.
Bonus: Wie viel Projektmanager werden benötigt, damit eine Frau ein Kind auf die Welt bringen kann?
Das schnelle Feedback zur Episode:
Links
- Stephan Strack: https://www.linkedin.com/in/stephan-strack-4b594b70/
- Veeva Systems: https://www.veeva.com/eu/de/
- Cynefin-Framework: https://de.wikipedia.org/wiki/Cynefin-Framework
- Manifest für Agile Softwareentwicklung: https://agilemanifesto.org/iso/de/manifesto.html
- Henry Cavill: https://de.wikipedia.org/wiki/Henry_Cavill
- Protobuf: https://de.wikipedia.org/wiki/Protocol_Buffers
- Factorio: https://www.factorio.com/
- Suits: https://de.wikipedia.org/wiki/Suits_(Fernsehserie)
Sprungmarken
Hosts
- Wolfgang Gassler (https://mastodon.social/@woolf)
- Andy Grunwald (https://twitter.com/andygrunwald)
Feedback (gerne auch als Voice Message)
- EngKiosk Community: https://engineeringkiosk.dev/join-discord
- Email: stehtisch@engineeringkiosk.dev
- Mastodon: https://podcasts.social/@engkiosk
- Twitter: https://twitter.com/EngKiosk
- WhatsApp +49 15678 136776
Transkript
Wolfi Gassler (00:00:04 - 00:01:04) 
In der Softwareentwicklung ist Agilität hier nicht mehr der neue Hype, sondern eigentlich schon fast der Alltag. Wir arbeiten alle agil und wir befinden uns nicht mehr in dieser alten Zeit des Wasserfallmodells, sondern im agilen Scrum-Ansatz. Aber wie sieht denn das Ganze in großen Multiteamprojekten aus, wenn man hunderte Leute aus den unterschiedlichsten Bereichen von der CEO bis zum Entwickler unter einen Hut bringen muss? Funktionieren dort diese agilen Methoden? Und welche besonderen Herausforderungen ergeben sich bei Projekten, in denen 10, 20 Teams oder vielleicht sogar die ganze Firma eingebunden ist? Wir sprechen mit Stefan, der schon Projekte mit hunderten Beteiligten erfolgreich über die Bühne gebracht hat. Stefan erzählt uns, wie effiziente Kommunikation und Dokumentation abläuft, wie man Stakeholder am Laufenden hält, wie man mit Anforderungen umgeht, die ständig im Fluss sind und wie verhindert man eigentlich dieses Over-Engineering in der Planungsphase von solchen großen Projekten. Und für mich auch ganz spannend sprechen wir gegen Ende auch noch, wie die Remote-Kultur die Umsetzung von großen Projekten beeinflusst. Und los geht's!
Andy Grunwald (00:01:08 - 00:01:22)
Wolfgang, du warst ja schon in deiner Karriere in einigen Projekten involviert. Ich meine, dein längstes Projekt war sehr wahrscheinlich dein Doktortitel, aber vielleicht war es auch nicht das größte. Deswegen, lass mich doch mal bitte wissen, was war das größte Projekt, in dem du jemals eingewogen warst?
Wolfi Gassler (00:01:23 - 00:03:47)
Es ist die Frage, wie du das natürlich misst, jetzt die Größe. Den weltweiten Impact hat natürlich meine Doktorarbeit gehabt, den größten Impact natürlich, der hat die Welt verändert, natürlich meine Doktorarbeit. Aber wenn es jetzt darum geht, um die Größe im Sinne von Personen oder finanziellen Impact oder sowas in der Richtung, dann war das ein Projekt, was ich vor relativ vielen Jahren gemacht habe oder beziehungsweise eingebunden war, ein kleiner Teil natürlich bei so einem großen Projekt. Und da ist es darum gegangen, wirklich eine Kernkomponente auszutauschen in einer großen Firma, also dass da wirklich dann etwas geändert wird, wo ganz viele Leute daran arbeiten. Also man kann sich das so vorstellen, wie wenn jetzt, keine Ahnung, Google oder so ihre Suchmaschine austauschen würde. Also wirklich der Kern an sich, wo alle irgendwie daran arbeiten. Und wenn man so großen Projekten arbeitet, dann können ganz kleine Änderungen auch schon einen extremen Impact haben oder Auswirkungen haben auf ganz viele Teams. Also wenn man jetzt sich vorstellt, Google würde die User-ID ändern, wie die User-ID kodiert wird, wie viel Bit die hat oder sowas. Da würde natürlich automatisch Alle Systeme bei Google, die irgendwie mit der User-ID zu tun haben, die müssten geändert werden. Also du hast einen riesen Impact natürlich im negativen Sinne auf ganz viele Teams, die alle irgendwas ändern müssen. Und so ein Projekt war das eigentlich. Ich glaube, es waren irgendwie, keine Ahnung, 10, 20 Teams dann eigentlich involviert, technische Teams sicher ein paar hundert Leute. Und das macht es dann natürlich nicht einfacher, in so einem Projekt zu arbeiten, da was weiterzubringen. Und glücklicherweise war ich ja nur irgendwie auf der technischen Seite involviert in das Ganze. Und man muss da von der technischen Seite auch definitiv viel machen. Also gerade wenn man in Richtung Senior- oder Staff-Level geht, ist man genau in solchen Projekten eingebunden. Und man macht dann vielleicht nicht das klassische Projektmanagement, aber man muss natürlich trotzdem extrem viel beisteuern in so einem Projekt und kommunizieren mit den ganzen Teams. Cross-Team ist ja die Aufgabe von dem klassischen Staff- oder Staff-Plus und muss eben auf dem Level extrem viel kontributieren. Was aber wirklich schwierig ist, ist eigentlich dieses Projekt zu managen. Und nachdem ich ja das nicht gemacht habe, zum Glück, trotzdem aber das super spannend finde, dieses ganze Thema, haben wir einfach diesen Kopf von diesem Projekt damals eingeladen zu uns ins Podcast-Studio. Also quasi der Kindergartenonkel damals von diesem Projekt, der uns Tech-Hister an die Hand genommen hat und uns durch dieses Projekt geführt hat. Hi, Stefan.
Stephan Strack (00:03:48 - 00:04:24)
Hallo, Andi. Hallo, Wolfgang. Tja, schön, dass ich da sein kann. War wirklich ein großes Projekt. Kindergartenonkel. Ja, ist krass. Vielleicht ein Teil der Rolle auch, aber viel war mehr organisieren, Klarheit schaffen und dafür zu sorgen, dass die Dinge zeitnah zusammenhängend umgesetzt werden können. War schon beeindruckendes Projekt. Ich glaube, wir hatten Glück, dass wir klein angefangen haben. Am Anfang waren es neun Leute und am Ende waren es so vier mal Daumen, 120 vielleicht, die dann mit angepackt haben, es über die Ziellinie zu schieben. Also konnte gut in der Entwicklung des Projekts selber lernen, mit der Größe zurechtzukommen, aber es war schon viel Arbeit.
Andy Grunwald (00:04:24 - 00:04:56)
In dieser Podcast Episode sprechen wir aber nicht wirklich über den Inhalt des Projektes, sondern über den Management Part dieses Projektes. Aber erstmal zu dir. Stefan, wer bist du? Du kommst aus Düsseldorf. Du hast ebenso wie ich ein wundervolles Fach studiert Wirtschaftsinformatik. Du hattest deinen Start in der Softwareentwicklung, so hast du zumindest deine berufliche Laufbahn begonnen. Und 2015 bist du irgendwie falsch abgebogen ins Projektmanagement. Da bist du jetzt anscheinend auch gelandet.
Wolfi Gassler (00:04:56 - 00:05:00)
Man meint, was heißt falsch abgebogen? Vielleicht ist es richtig abgebogen.
Andy Grunwald (00:05:00 - 00:05:08)
Nee, kennst du das, wenn man im Internet falsch abbiegt und dann was total Skurriles, so ein Redneck-Meme sieht? Dann denkt man sich auch, heute ist genug fürs Internet.
Wolfi Gassler (00:05:08 - 00:05:11)
Projektmanagement ist für dich so dieses Meme.
Andy Grunwald (00:05:12 - 00:05:50)
Ja, warum erzähle ich dir nach der Vorstellung. Aber aktuell arbeitest du als Projektmanager bei Viva Systems, was sich selbst als The Industry Cloud for Life Science beschreibt. Ihr macht, soviel ich herausfinden konnte, Cloud-Anwendungen für die Pharma- und Biowissenschaftsbranche. Du liebst elektronische Musik über 150 Beats per Minute und ich weiß nicht, ob du es wusstest, aber du hast eine Gemeinsamkeit mit dem Schauspieler, der The Witcher und Superman spielt, Henry Cavill, nämlich du glaubst an Computer über Konsolen fürs Gaming. Ist das korrekt?
Stephan Strack (00:05:50 - 00:06:23)
Ja, das ist korrekt. Das kann ich so unterschreiben. Zum Falschabbiegen. Ich glaube, ich bin richtig abgewogen. Lass mich das kurz erläutern. Als ich Softwareentwickler war, war ich Projektmanager ausgesetzt, von denen ich geglaubt habe, die hätten ihren Job besser machen können. Das hat mich am Ende so frustriert, dass ich gesagt habe, mir reicht's. Ich werde ein besserer Projektmanager als den, den ich ausgesetzt bin. Und bin dann losmarschiert mit dem Glauben, ich könnte Gutes für die Entwickler tun, wenn sie einen guten Projekt- und Produktmanager und Productowner hätten, wäre ihre Arbeit viel leichter.
Andy Grunwald (00:06:23 - 00:06:36)
Warum sage ich falsch abgebogen? Ganz einfach. Viele Leute und ab und zu auch ich denken, dass Projektmanager Leute sind, die denken, dass neun Frauen ein Kind in einem Monat zur Welt bringen könnte. Bist du auch so einer?
Stephan Strack (00:06:37 - 00:06:56)
Nein, die neuen Leute machen definitiv mehr Chaos, als dass sie dann die Probleme tatsächlich lösen. Also ich glaube auch, dass ein kleines, gut aufgestelltes Team besser in der Lage ist, mit mehreren Problemen zurechtzukommen. Und dass man manchmal eben auch warten muss, bis Dinge fertig sind. Manchmal ist einfach warten die bessere Lösung, als mehr Durcheinander zu verursachen.
Wolfi Gassler (00:06:56 - 00:07:03)
Hat es dir irgendwas gebracht, dass du aus der Softwareentwicklungsecke kommst, für die Arbeit dann als Projektmanager?
Stephan Strack (00:07:04 - 00:07:53)
Viel, richtig viel. Es ist einfach ein Gut, technische Lösungen immer noch durchschauen zu können und auch zu verstehen, was einem die Entwickler sagen. Auch zu verstehen, was Schmerzen im Release-Prozess sind oder dass, wenn der Release-Prozess lange dauert oder nicht stabil funktioniert, dass das ein Riesenproblem darstellt. Auch noch ein Rieberreisepunkt in der täglichen Arbeit ist. Aber auch, wenn man mal tief in die Anforderungen absteigen muss, also wenn man sich jetzt wirklich über Parameter auf dem API-Call streiten muss oder über Naming-Conventions mitdiskutieren muss, Dann ist das gut, wenn man das selber mal gemacht hat oder auch weiß, wie sich das dann im Code verhält. Das hilft natürlich auch die Relevanz der Diskussion einfach beurteilt. Ist das jetzt ein Naming-Problem? Ist das ein tatsächliches Logging-Problem? Oder haben wir hier ein Problem auf der Infrastruktur? dass man das einfach sauber trennen kann und auch sofort Bescheid weiß, hilft einfach immens in solchen Diskussionen.
Wolfi Gassler (00:07:53 - 00:08:08)
Bei so großen Projekten, wenn wir jetzt irgendwie davon sprechen, wir haben da zehn Teams oder vielleicht noch mehr Teams eingebunden, wo würdest du sagen, ist so der größte Schmerz, wenn man mit so vielen Teams in irgendeiner Form kollaborieren muss oder da irgendwie ein Projekt durchbringen muss?
Stephan Strack (00:08:09 - 00:09:03)
Die Frequenz an Themen. Es fühlt sich so an, als würdest du 50 verschiedene Gerichte gleichzeitig grillen. Die haben alle unterschiedliche Garzeiten, du musst zu unterschiedlichen Punkten nachgucken und das macht es sehr, sehr schwierig. Du hast einfach unterschiedliche Laufzeiten in den Arbeiten und es kommen immer wieder unterschiedliche Themen vor. Mal gibt es eine Erfolgsmeldung, mal gibt es ein Problem und dann musst du wieder loslaufen und mit drei anderen Leuten reden und dann verursachst du Änderungen im Schedule, die du dann selber wieder ausbaden musst. Diese permanente Masse an Themen, die sich gegenseitig beeinflussen und in Bewegung sind, ist das größte Problem solcher Projekte. Weil das immer wieder Arbeit generiert. Also wenn eine Arbeit fertig ist, muss die nächste folgen. Gibt's an einer Arbeit Probleme, musst du drei nächste Arbeitsschritte scannieren. Du bist sozusagen durch das permanente Parallelisieren von Themen immer dazu gezwungen, vorangetrieben vorwärtszukommen. Und das kann sehr viel Stress bedeuten für so einen Projektmanager. Da sozusagen sich gut zu sortieren und aufzustellen, ist extrem wichtig.
Wolfi Gassler (00:09:04 - 00:09:44)
Wenn wir jetzt mal an den Anfang zurückgehen oder wenn man sich so überlegt, okay, man hat da jetzt irgendwie so ein Projekt, wo so eine Kernkomponente ausgetauscht werden soll oder ja, das einen extrem großen Impact hat, da extrem viele Teams dann schlussendlich involviert sein werden. Wie startet man denn so ein Projekt am besten? Klassisch? Ich vermute mal oder ich hoffe, keine Ahnung, Wasserfallmodell ist jetzt nicht mehr so, aber andererseits, wenn man jetzt bei Nicht-IT-Themen auf große Projekte sieht, jetzt keine Ahnung, wenn ich irgendeinen Wolkenkratzer baue, muss ich wahrscheinlich irgendwo teilweise so ein bisschen wasserfallmäßig agieren. Wie ist es in der IT bei so großen Projekten? Muss ich da noch klassisch Wasserfall anwenden? Wie bereite ich mich denn auf so ein Projekt vor?
Stephan Strack (00:09:45 - 00:11:18)
Ich glaube es gibt einen Punkt der wird der ist in der IT meist übersehen weil er tatsächlich aus der Ökonomie kommt und das ist so der Punkt das Projekt ist in der Ökonomie gesehen als Organisationsform also als bestimmtes Mittel sich irgendwie zu organisieren ein Problem zu lösen und ein. Das Problem versteht man da auch eher als ein Hindernis auf dem Weg zur strategischen Zielerreichung. Also meine Unternehmung möchte meine Kernkomponente verbessern und austauschen. Da will ich hin. Das Problem ist, auf der alten Infrastruktur kann ich das nicht. Okay, also mache ich jetzt ein Projekt, das die alte Kernkomponente auf eine neue Infrastruktur hebt und mir dann das ermöglicht, mein strategisches Ziel zu erreichen. Das muss auch erstmal klar begriffen und formuliert sein, damit du so ein Projekt initialisieren kannst. Und das wird dann meistens auch vergessen, dass so ein Projekt so eine Initialisierung braucht, dass sich jemand die Gedanken darüber macht, welches Ziel wollen wir erreichen, welches Problem ist überhaupt zu lösen, wen brauche ich dafür, was ist das für ein Umfang und was sind so die groben Risiken. Also überhaupt mal so einen Überblick dafür haben, was kann denn überhaupt alles schief gehen, damit der Projektmanager, der das am Ende ausführt, weiß, ah, da muss ich mein Augenmerk drauf legen, dass das alles in Ordnung bleibt, damit wir das Projekt zielern. Und der Schritt wird meistens übergangen, finde ich. Also in meiner Erfahrung geht das meistens so, die Führung, du schließt da, das brauchen wir. Da hast du einen fähigen Projektmanager, du machst das Projekt jetzt. Und der Zwischenschritt, das Projekt sauber auszuformulieren, fällt dann immer dem Projektmanager in den Schoß. Also würde ich jedem Projektmanager erstmal empfehlen zu sagen, okay, mach diese Initialisierung. Das ist so ein bisschen Formalität. Und dann hast du aber auch eine gute Basis, weil du weißt, wohin musst du, welche Probleme sind zu klären, mit welchen Leuten fange ich an.
Wolfi Gassler (00:11:18 - 00:11:34)
Und wie wählt man diese Leute an, wenn du sagst, Gerade jetzt, wenn es 15 Teams sind, irgendwie will dann vielleicht jeder mitmachen. Ich kann nicht alle 150 Leute als technische Spezialisten einladen. Also wie findest du die richtigen Leute dann gerade für ein technisches Problem?
Stephan Strack (00:11:35 - 00:12:23)
Ja, das ist jetzt die Sicht aus dem Projektmanagement. Ich habe jetzt zwei Ansätze gesehen, die funktionieren. Zum einen gibt es gute Leads, die auch selber Engineering Background haben und sozusagen den initialen Scope mit abdecken können als Engineering Leads. Ich habe aber auch Szenarien gesehen, wo wir da direkt mit den Engineers gearbeitet haben und den POs als Kombination, wo wir dann gesagt haben, okay, euch nehmen wir ins Boot, damit ihr wisst, was ihr an Wissen aufarbeiten müsst, was für Tickets ihr machen müsst, und die Engineers dir dann das Fachwissen beisteuern, und dann überhaupt erst mal reverse zu engineeren, was ist denn überhaupt da, was haben wir denn? Im Sinne so einer kleinen Ist-Analyse. Aber du musst dich erst mal mit den Leuten zusammensetzen und fragen, was ist denn Status Quo? Und dann die zweite Frage ist, wie kommen wir von Status Quo zum Ziel? Und das kann eine ganze lange Reise sein, also sich das alles überhaupt zu überlegen. Kann manchmal auch richtig Wochen dauern, überhaupt herauszufinden, was man denn so hat.
Wolfi Gassler (00:12:23 - 00:12:47)
Aber wie gehst du das dann an, mit den Leuten herauszufinden, wo es hingehen soll? Weil jetzt hast du keine Ahnung, konkret irgendwie, fünf Leute oder zehn Leute, zehn technische Leute in einem Meeting sitzen, das ist ja eine Katastrophe. Da kannst du sicher sein, zehn Leute, zehn Meinungen, mindestens zehn Meinungen, wenn nicht 20 Meinungen und alle streiten, wie kommt man da auf einen grünen Zweig am Ende?
Stephan Strack (00:12:47 - 00:13:44)
Hm. Mehrere Ideen würde ich, glaube ich, dahin zufügen. Zum einen solltest du gut in Meeting-Moderation-Facilitation sein. Also, du musst irgendwie gut sein, wenn du die Gruppe zusammen hast, das Gespräch sinnvoll zu führen. Und dann musst du erstmal alle Optionen irgendwie sammeln. Es ist am Anfang in so einem Projekt wirklich schwer zu beurteilen, welche von den Optionen ist jetzt nur gut oder schlecht. Und es hilft auch sozusagen im Projektverlauf, so einen Optionen-Katalog für einzelne Teilbereiche offen zu haben. Was ist denn überhaupt im machbaren Raum? Und das muss man auch durchdiskutieren und man sollte den Leuten auch Gehör verschaffen. Damit sich jeder gehört fühlt und man auch wirklich einen großen Optionsraum zur Auswahl hat. Und dann erst der zweite Arbeitsschritt ist zu versuchen, das zu einer Gesamtlösung zusammenzupuzzeln. Wenn man sozusagen zu früh versucht, eine Lösung zusammenzupuzzeln, dann gibt es immer interessante Optionen, die man doch austauscht miteinander. Dann ist man in so einem Konfliktgespräch, ob nicht A oder B besser ist, viel zu früh, bevor man sich überhaupt alle Optionen klargemacht hat.
Wolfi Gassler (00:13:45 - 00:13:58)
Das heißt aber, du gehst ja dann auch iterativ langsam vor mehrere Diskussionsrunden, bis du dann schlussendlich zu einem Ziel an sich oder zu einer Möglichkeit zur möglichen Umsetzung dann kommst am Ende.
Stephan Strack (00:13:58 - 00:14:31)
Ja, so ein Projekt lebt davon, dass du das Domänenwissen zu dem Thema aufbaust mit der gesamten Gruppe, dass also jeder ein Experte wird insgesamt für das Thema und dann sehr starke Experten, sei es Teilbereiche, Mitglieder im Projekt sind. Und alle müssen das irgendwie insgesamt verstehen. Also, du bist auch viel dabei, immer wieder ein Status Quo zu wiederholen, was man alles hat, und das dann sukzessive zu lösen. Und das muss man aktiv machen. Also, da sind alle aktiv da und beteiligt, das Wissen aufzubauen und zusammenzutragen. Und dann kommt man irgendwie voran. Das kristallisiert sich dann auch meistens am Ende raus. Aber das ist ein Prozess, den muss man aktiv betreiben. Zufällig fällt einem die Lösung meistens nicht in den Schoß.
Wolfi Gassler (00:14:32 - 00:14:46)
Glaubst du, dass es wichtig ist, dass das dann eine Person managt sozusagen, dass es da einen Manager gibt, der vielleicht auch moderiert? Also muss das eine Person sein, kann das mehr Personen sein? Was ist da deine persönliche Meinung?
Stephan Strack (00:14:46 - 00:15:31)
Ich finde, wenn einer dafür accountable ist, hat der eine genug Motivation, alle anderen mitzuziehen. Das ist meine Meinung. Also wenn du einen klaren Verantwortlichen hast, der sagt, okay, von dir erwarte ich, dass du das aus all diesen Teams irgendwie rauskriegst, dann hat der einen klaren Arbeitsauftrag, an dem er gemessen wird. Und dann hat er auch das Incentive, loszugehen, auch wenn es mal schwierig ist, wenn die Meetings anstrengend sind, wenn da Konflikte sind, die Teams sich gerade nicht verstehen. Wenn all diese regulären Probleme in den Projekten auftreten, dann ist er auch bereit, da durchzugehen und bei der Lösung beizutragen. Und das hilft. Wenn du das sozusagen verteilst, dann versucht man, das von sich wegzuschieben, an die anderen zu geben, zu delegieren. Das ist dann immer schwierig. Und am Ende kann man sich halt auch gut verstecken aus der Verantwortung, die man hat angenommen. Und das finde ich ein bisschen schwierig. Also jetzt einen Clan gibt, der die Gesamtverantwortung trägt, das durchzuziehen, das ist meiner Meinung nach ein höherer Erfolg schon.
Wolfi Gassler (00:15:31 - 00:15:56)
Und jetzt haben wir die technische Seite besprochen, also dass man die Techniker mit reinholt in diese Meetings und dann gemeinsam eben iterativ daran arbeitet. Würdest du dann in der Phase dann auch andere Stakeholder mit einbinden oder nur das mal mit den technischen Leuten machen? Also, weil da kommt ja eine ganz andere Dimension dann noch dazu, wenn du da jetzt keine anderen bis zum C-Level womöglich dann Leute einbindest.
Stephan Strack (00:15:57 - 00:17:12)
Das ist so ein zweischneidiges Schwert. Zum einen brauchst du den Business-Input, weil du willst ja das Business-Problem lösen. Also du willst ja tatsächlich zum strategischen Ziel am Ende kommen und du brauchst den Input vom Business, was genau dann erreicht werden soll. Also das ist ja essentiell, sonst machst du irgendwas, das trägt nicht zur Zielführung, weil der Input muss schon irgendwie reinkommen ins Team. Oder es ist auch so ein Projekt, wo man das immer mit sich tragen und im Team kommunizieren können. Aber manchmal gibt es halt eben explizite Fragen, die zu klären sind. Und dann ist es sozusagen der Business, als Experte mit ins Meeting zu holen, um eine Fachfrage sauber durchzudiskutieren und zu klären. Das geht gut. Was ich finde, ist schwierig, ist, wenn du sagst, mach doch mal einen Vorschlag, wie das Gesamtprojekt am Ende aussehen soll. Das geht meistens schief. Also, oder wenn man sagt, ja, wir haben keinen Vorschlag, wie wir das lösen können, auch ganz schlechtes Szenario, dann passiert meiner Erfahrung meistens das folgende, das Business kommt und sagt, genau so hätte ich das gerne und genau so absetzen, und dann sagt die Engineering-Reihe, der Druck, ja, das hat aber irgendwie Probleme und funktioniert nicht so richtig. Dann bist du in irgendeinem Konflikt gefangen, der schwierig aufzulösen ist. Die bessere Strategie, meiner Meinung nach, ist, die Business-Anforderung einmal entgegenzunehmen, bis alle im Engineering das verstanden haben, und dann erstmal auf Lösungsfindung zu gehen, überhaupt erstmal einen Lösungsvorschlag zu etablieren, wo das Engineering sagt, schieb mal da um, der könnte passen, das könnte man so machen, um das Problem zu lösen.
Wolfi Gassler (00:17:12 - 00:17:16)
Aber dann ohne Business, also die Diskussion läuft dann ohne Business ab?
Stephan Strack (00:17:16 - 00:17:49)
Ohne Business und dann wieder zusammenbringen. Also dann alle mal wieder auftauchen aus der A&D-Abteilung, zurück in den großen Meeting-Raum, sagen, das haben wir uns jetzt mal vorgestellt, das würden wir gerne zur Diskussion stellen, euren Feedback haben, wir würden Pros und Cons oder Implications diskutieren. Und dann kommt man wieder zusammen. Und dann kommen meistens drei Änderungswünsche, aber der grobe Kern von dem, was man vorgeschlagen hat, bleibt meistens bestehen. Und das hilft dann auch, die Motivation ausweichend zu erhalten. Aber das ist schon viel Arbeit. Und manchmal passiert es halt trotzdem, dass man dann das Feedback kriegt, nee, haben wir uns ganz anders vorgestellt. Okay, dann muss man halt nochmal darüber ändern.
Wolfi Gassler (00:17:49 - 00:18:07)
Okay, wenn wir jetzt mal annehmen, wir haben die Dinge eingesammelt vom Business, wir haben da eine technische Lösung uns mal überlegt, skizziert, haben so ein Ziel, worauf wir hinarbeiten wollen, baue ich dann mein Wasserfallmodell und überlege mir, wie komme ich Schritt für Schritt zu meinem Ziel?
Stephan Strack (00:18:07 - 00:19:20)
Nee, am besten gar nicht. Am besten gar nicht. Was mir persönlich zu den meisten Erfolgen verholfen hat, war erstmal alles end-to-end zusammenzustöpseln. Selbst wenn du nur Dummy-Daten durch einen Prozess hindurch reichst. Aber dass du irgendwie ein komplexes Stück Applikationen hast, was alle Teile miteinander verbindet über klare Interfaces, das hilft schon mal. Und dann einfach den Prozess einmal ablaufen lassen. Also wenn du jetzt ein Microservices-RAM hast, wo du alle Microservices miteinander verknüpft hast, du stellst vorne den Request, das triggert euch alle durch und du kriegst deine finale Response zurück. Oder du machst einen Data-Engineering-Prozess, der durch drei Teams durchlaufen muss. Dann willst du alle miteinander verknüpft haben, dass jeder den Output von dem anderen liest, bis es dann zur gesamten Delivery kommt. Und das können am Anfang ruhig Fake- und Dummy-Daten sein. Zumindest steht schon mal das Gerüst, wie sich die Teams unterhalten müssen und wie in den Prozessen kommuniziert wird. Und das ist meiner Meinung nach die beste Basis, weil wenn dann eine Anforderung kommt oder tatsächlich implementiert wird, ist die Stelle genau bekannt, wo das zu tun ist. Und das hilft eine Menge. Ansonsten diskutierst du immer sehr viel auf dem Whiteboard, ohne dass konkret die Implikationen von dem Feature ersichtlich sind. Das ist meiner Meinung nach schwierig.
Wolfi Gassler (00:19:20 - 00:19:36)
Und würdest du dann irgendwie Untergruppen bilden, die dann jeweils über die Schnittstellen sprechen, die damit zu tun haben? Oder macht man das in der großen Runde? Also ab wann fängt man denn richtig Arbeiten an? Irgendwann muss es ja mal mehr ins Detail gehen, wo dann wahrscheinlich nicht mehr alle eingebunden sein können.
Stephan Strack (00:19:36 - 00:20:15)
So früh wie möglich. Also aus der Schnittstelldiskussion würde ich mich als Projektmanager komplett zurückziehen. Die muss je nachdem, was notwendig ist, dafür muss ich Sorge tragen. wie genau die Parameter jetzt so sind und worüber kommuniziert wird, ist meiner Meinung nach eine Engineering-Entscheidung, und die müssen damit anfangen. Also du musst dich für eine API-Sorte entscheiden, ob du jetzt Protobuf machst oder andere gängige Formate. Aber wenn du sagst, wir machen Protobuf, dann schreibst du jetzt eine Protobuf-Definition runter, so stelle ich mir das Interface vor, und schickst das zum anderen Team als Pull-Request, und dann sagen die Ja oder Nein. Und dann streitet man sich halt über Parameter, Namen und Änderungsdefinition. Und dann kann es auch mal sein, dass man so zu Naming-Conventions kommt. Die musst du einmal durch die größere Gruppe tragen, aber bitte zügig.
Andy Grunwald (00:20:15 - 00:20:49)
Du hast gerade einen spannenden Punkt gesagt, oder du hast es nicht nur einmal gesagt, du hast es mehrmals gesagt. Ja, dann müsste man mal und man müsste, man müsste, man müsste. Und meine Erfahrung ist völlig egal, ob agile Projekte, Wasserfallprojekte, ITIL-Projekte, Groß-Klein, auch wenn ich die alleine mache. dieses mann müsste mal ist immer so ein so ein punkt den glaube ich jeder von uns kennt und der immer immer immer immer immer immer in die hose geht weil diesen mann also jetzt nicht mann als geschlecht sondern diese person ich weiß nicht die habe ich noch.
Stephan Strack (00:20:49 - 00:21:39)
Nie gefunden wie siehst du das Das funktioniert tatsächlich nicht im Projekt. Also entweder einer mit Namen macht's, der ist Accountant belohnt. Der tut's, oder keiner macht's. Das sehe ich genauso. Das funktioniert sonst im Regelfall nicht. Wenn am Ende von einem Meeting nicht klar ist, wer die Aufgaben wahrnimmt und übernimmt, dann hast du halt eine sehr, sehr schlechte Chance. Wenn wir Facilitation-Training machen für Projektmanager, und uns die Meetings angucken, ist auch immer ein ganz wichtiger Punkt in der Facilitation Meeting Point Acceptance. Also du willst, dass die Action-Items, die zu erledigen sind, verstanden sind und derjenige, der die übernimmt, auch einverstanden ist, die zu tun. Wenn du das in dem Meeting nicht sicherstellst, hast du deinen Projektvorschritt höchstwahrscheinlich selber torpediert. Weil dann musst du hinterherrennen und dafür sorgen, dass die Dinge umgesetzt werden. Wenn die Leute aber sozusagen ihr Meeting schon verstanden haben, ist wichtig, die das machen wollen, dann wird es auch umgesetzt. Ganz essentiell am Standort.
Andy Grunwald (00:21:39 - 00:22:08)
Da bist du natürlich in deinem Kopf aber auch schon sehr weit. Weil die Realität, die ich so erlebe, und ich denke, da spreche ich für sehr viele Leute, ist, dass die in Meetings gehen ohne Agenda, und die gehen da raus ohne Protokoll. Und du sprichst grad hier sogar nicht nur von Action-Points festhalten und eine Entscheidung treffen und sogar delegieren. Du sprichst ja sogar auf das, wie soll ich sagen, TCPIP von Action-Point-Verteilung. Du willst ja sogar das ACK von denen haben. Genau.
Stephan Strack (00:22:09 - 00:22:33)
Gibt's witzige wissenschaftliche Studien darüber, dass Acknowledgement zu diesem Action-Item die Erfolgswahrscheinlichkeit der Umsetzung erhöht. Es ist tatsächlich schon nachgewiesen, dass das tatsächlich positiven Effekt hat. Ganz erstaunlich. Also wenn du selber sagst, kannst du dir selber sozusagen auch gut selber gut angewöhnen, am Ende von dem Meeting sagst du, okay, ich habe verstanden, das sollte ich bis zum nächsten Meeting machen, das mache ich auch. Dann erhöhst du sogar selber die Wahrscheinlichkeit, dass du das besser umsetzt.
Wolfi Gassler (00:22:33 - 00:23:05)
Was ist denn deine Meinung ganz allgemein zu dieser Dokumentation? Weil jetzt okay, ich kann am Schluss natürlich Action-Points und so weiter festlegen, aber jetzt gerade bei so einem großen Projekt, da fallen ja extrem viele Action-Points an in allen möglichen Meetings, es gibt Sub-Meetings und Schnittstellen-Dokumentationen und so weiter. extrem viele Punkte, wo man dokumentieren muss, könnte, sollte. Kann das dann der eine, der da an der Spitze steht, alles machen? Ist der verantwortlich für die Dokumentation? Wie siehst du Dokumentation?
Stephan Strack (00:23:05 - 00:24:52)
Dokumentation, das ist ein sehr spannendes Thema, Wolfgang. Zum einen wird das Business-Ziel ja nur erreicht, wenn du die Lösung implementierst. Also damit steht und fällt der Projekt erfolgt. Du gewinnst das Projekt nicht mit der Beschreibung der Lösung. Das ist schon mal Nummer eins. Also tatsächlich, Fokus ist immer auf die getane Arbeit. Und dann auf der anderen Seite, die Dokumentation ist doch wichtig, wenn es um komplexe Prozesse geht. Also wenn man als Engineering-Team einen größeren Prozess durch drei Teams irgendwie festlegt, der hat viele Implikationen, wenn man Dinge anders machen würde, dann ist mal besser, das irgendwie zu dokumentieren für die Nachwelt. Sechs Monate hat man schon wieder die Hälfte der Implikationen vergessen. Dann wird immer eine Fehleinstellung geöffnet. Und dann sind solche Dokumentationen wirklich Gold wert. Wer kann das dokumentieren? Top-Level sicherlich derjenige, der das Meeting einberufen hat. Und in den großen Projekten habe ich dann diese Meeting-Notes auch immer gemacht. Meistens auch, muss ja nicht viel Zeit kosten. Also wenn du ein Whiteboard hast oder ein digitales Whiteboard, das du mit dem Meeting gebracht hast, wo du den Prozess skizziert hast. Du hast ein Foto von dem Whiteboard und dann hängst du das Bild davon ein. Fünf Zeilentext zur Erklärung, die Action-Items darunter fertig. Das muss ja nicht eine halbe Stunde dauern. Und dann, wenn du weitergehen willst in die technische Dokumentation, habe ich mehrere Varianten gesehen. Ich glaube, eine Confluence-Page ist manchmal ganz gut für einen Überblick. Was ich persönlich gut hat funktionieren sehen, ist Dokumentation sehr nah am Code. Also direkt im Git-Repositorium mitdokumentieren, ohne Entscheidungsrecords da mitzuführen. Das scheint gut funktioniert zu haben, weil es halt auch nicht weit weg von der IDE ist, nicht ein anderes Tool, ist kein Medium-Bruch. Aber dann der Umfang. Ich glaube, das ist auch unterschiedlich, was die Teams tatsächlich brauchen, in welchem Kontext sie arbeiten. Aber es ist für mich jetzt nicht so der große Stellenwert. Muss gemacht werden, ja, aber jetzt nicht vollumfänglich für alles, weil am Ende gewinnt die geschriebene Software.
Wolfi Gassler (00:24:52 - 00:25:13)
Aber das heißt ja auch, also gerade da, Andi ist da ja ein großer Verfechter, dass alles immer niedergeschrieben werden muss und ganz viel Kontext und Design-Documents und schlag mich tot, Andi liebt Design-Documents. Das, was du jetzt sagst, ist eigentlich eher, mach ein Foto von der Diskussion, die Action-Points und Gib Gummi.
Stephan Strack (00:25:13 - 00:25:38)
Ausdifferenzieren. Wenn es um die Projektinitialisierung geht, da bin ich bei Andi. Also wenn du sagst, okay, wir würden ja gerne was Neues machen, dann bitte gerne was genau, was ist das Problem, was soll am Ende abgegeben werden? Das muss sauber festgehalten werden. Wenn es jetzt sozusagen um die Teillösung geht, die implementiert werden, solange die grobe Skizze da ist, die reicht, um das nochmal durchzudenken, perfekt. So würde ich da rangehen. Aber der initiale Auftrag, der sollte tatsächlich sehr gut dokumentiert werden.
Andy Grunwald (00:25:38 - 00:26:49)
Bei mir geht es ja nur darum, die ganze Sache zu verschriftlichen, weil, wenn ich zu euch beiden spreche, in Einzelgesprächen, und versuche, dieselbe Nachricht zu transferieren, dann kriegt ihr beide unterschiedliche Nachrichten, weil ich werde niemals eins zu eins dieselbe Wortwahl machen, die Satzreihenfolge und so weiter. Habe ich jedoch ein geschriebenes Dokument, das kann ich dir schicken, dir, Wolfgang, das kann ich dir schicken, Stefan. Ihr lest das in eurer Geschwindigkeit und wann ihr wollt und habt eins zu eins dasselbe gelesen. Und ich denke, allein dieser Punkt ist unschlagbar in Bezug auf Leute auf einen Level bringen. Ob dann in diesem Dokument immer alles drin ist, das ist eine andere Geschichte. Es ist genauso wie, wenn wir über Dokumentation reden und die Frage geht es dann nicht, Stefan, du machst ein Foto von irgendwas und Da kann ich ja nicht drin suchen. Also nicht jedes Foto wird ja direkt per OCR gescannt oder vielleicht halt heute doch mit AI und schieß mich tot. Aber da weiß ich gar nicht, ob er das schon alles einsetzt. Also du verstehst, was ich meine. Wo stand die Information denn? Ich kann dich ja nicht immer anrufen. Mama, Stefan, wir haben doch mal vor drei Wochen in einem Meeting da was geklärt. Wie war das denn nochmal? Hast du das gerade nochmal auf dem Zettel?
Stephan Strack (00:26:50 - 00:27:29)
Das wäre jetzt tatsächlich meine Antwort gewesen. Ich würde sagen, der Projektmanager ist eine valide Quelle an Informationen und der sollte auch tatsächlich Bescheid wissen, was für Entscheidungen die Mietingszentren sich getroffen sind. Also, das wäre tatsächlich der Punkt, wo ich sage, okay, wenn es keine Dokumentation gibt, gibt es ja einen, den du fragen kannst. Wenn der dir die Information nicht sofort geben kann, sollte der aber in der Lage sein, die Information wieder aufzutreiben, aus all seinen, Anführungsstrichen, Dokumentationswurst. Das würde ich sozusagen schon mit in die Verantwortung legen, dass es zumindest einen gibt, der Auskunft geben kann oder der die Informationen beschaffen kann, indem er mit den relevanten Leuten wieder redet. Wenn das nicht funktioniert, dann ist, glaube ich, deine Methode das beste Vorbild, den du haben kannst, weil dann gibt es einen Überblick irgendwo fest verschriftlicht, den sich jeder zu jeder Zeit anguckt.
Wolfi Gassler (00:27:30 - 00:27:37)
Ja, meine Frage ist, wenn du dich zurückerinnerst an dieses Projekt, Stefan, hättest du die Zeit gehabt, das so zu dokumentieren, wie Andi es gerne hätte?
Stephan Strack (00:27:38 - 00:27:57)
Nö. Nö. Also man ist ja da auch auf Fortrieb. Man muss ja Fortschrift schaffen. Dann bist du mit der begrenzten Zeit, du Deutschlands Projektmanager, auch in der Bedrohlie. Mache ich jetzt eine Stunde Dokumentation oder mache ich das nächste Meeting zum Requirements Engineering vom nächsten Teil Problem? Und da fällt die Karte grundsätzlich zum nächsten Requirements Engineering.
Andy Grunwald (00:27:58 - 00:28:09)
Aber hattest du die zeit nicht weil du alleine warst und weil so viele leute und so viele teams involviert waren oder oder was war der knackpunkt warum du warum du dazu nicht gekommen wärst.
Stephan Strack (00:28:10 - 00:28:32)
Ich glaube, es ist eine Prioritätsentscheidung darüber, was wichtiger ist, die Sache zu verschriftlichen, die auch als Information über ein anderes Medium zur Verfügung steht. Im Sinne, ich rede mit dem Projektmanager als Informationsbeschaffungsmedium. Die Information war ja da, du hättest nur zu mir gehen müssen, also war es ja kein Bedarf, sie zu dokumentieren. Stattdessen habe ich einfach das nächste Requirements Engineering gemacht, mit einer etwas dünnen Dokumentation dann darüber, was wir entschieden haben.
Andy Grunwald (00:28:32 - 00:28:35)
Aber bist du dann nicht in dem Punkt jetzt irgendwie der Gatekeeper?
Stephan Strack (00:28:36 - 00:28:38)
Ja, glaubst du das in dem Moment, ja.
Andy Grunwald (00:28:38 - 00:29:15)
Wir reden jetzt hier gerade von einem Setup, wo das gegebenenfalls noch möglich ist, wo wir alle in einer Zeitzone arbeiten, vielleicht sogar noch in einem Büro. Aber jetzt sind wir ja in der neuen Welt angekommen, nach diesem Covid-19, nach dieser Pandemie. Und wie dieses Podcast-Setup auch gerade zeigt, wir sitzen zu Hause alle in unseren vier eigenen eigenen vier Wänden. Das ist ja eine ganz andere Liga jetzt. Denkst du heutzutage genauso? Oder sagst du, nee, die Dokumentation, die Verschriftlichung ist in dem Setup, was wir heute fahren, was wir heute als normal in der Arbeitswelt ansehen, verteiltes Arbeiten von zu Hause, hat einen höheren Stellenwert gekriegt?
Stephan Strack (00:29:15 - 00:30:01)
Wenn ich jetzt so in meine persönliche Arbeit gucke, was ich sozusagen heutzutage mache, Ich kreiere Lösungs-Draft-Pages, die grundsätzlich den Kontext nochmal kurz zusammenfassen. Die gewählte Lösungsspitze beschreiben gegebenenfalls andere Optionen mit den Gründen, warum wir die nicht mehr machen. Es ist schon mehr Dokumentation und auch strukturierter zur Aufbearbeitung, weil wir eben auch ein verteiltes Team sind, als ich damals in dem lokalen Projekt gemacht habe. Ja, würde die sozusagen aus meiner persönlichen Tendenz, was ich heute mache, zustimmen, dass die Dokumentationsaufwand steigt, wenn du remote arbeitest. Ob ich es auf die Spitze treiben würde? Ich weiß nicht, ich bin da persönlich immer noch an so den Trade-Off gefangen. Irgendwann ist zu viel Dokumentation. Und ich glaube, so der liene Ansatz, so wenig Dokumentation wie nötig zu machen, ist meiner Meinung nach noch der praktikabelste Ansatz, zumindest aus der Projektmanagement-Zeit.
Wolfi Gassler (00:30:01 - 00:30:41)
Also ich bin mir auch gar nicht sicher, wenn ich da zurückdenke. Es war ja wirklich ein großes Team und wir waren verteilt teilweise über mehrere Gebäude. Ich bin mir nicht sicher, ob ich Leute aus den ganzen Gremien und Teams, inklusive Stefan, so oft überhaupt außerhalb von Meetings gesehen habe damals. Also nur weil wir physikalisch am gleichen Standort waren, bin ich mir nicht sicher, ob wir da sehr viel kommuniziert haben durch diesen physikalischen Vorteil, dass wir am gemeinsamen Standort sind. Sondern die meiste Zeit war es wieder in Meetings eigentlich, wo wir kommuniziert haben. Und da könntest du argumentieren, die hast du online auch. Kenne aber natürlich keinen oder habe nie so ein großes Projekt jetzt in der Online-Welt mal durchgeführt. Also ich kann den Vergleich diesbezüglich.
Stephan Strack (00:30:41 - 00:31:14)
Zur Lösungsfindung mit den Teams stimme ich dir zu, was ich persönlich viel gemacht habe. Ich war viel unterwegs bei anderen Koordinationseinheiten, anderen Teilprojektmanagern oder Product-Ownern, die die Teams koordiniert haben. Mit denen war ich quasi täglich im Austausch. Da bin ich quasi täglich vorbeigelaufen, kurz Plausch gehalten, kurz geklärt, wie es den Projektstatus gibt, ob es irgendwelche Neuigkeiten oder Veränderungen gibt und dann weiter. So ein Management, mit rumlaufen, Informationen einschaffen, das so ein bisschen informal zu halten, geht heutzutage nicht. Da musst du dann tatsächlich offizielle Meetings aufsetzen. Das hat schon einen anderen Charakter. Das ist tatsächlich auch eine große Umstellung für mich gewesen.
Andy Grunwald (00:31:14 - 00:31:33)
Du hattest grad das Wort Koordinationseinheiten genannt. Ich weiß nicht, ob du den Spruch kennst, aber immer, wenn ich was von Ressourcen höre, frage ich, reden wir hier über Menschen? Und die Frage stelle ich hier eigentlich auch. Koordinationseinheiten, das hört sich grad so an. Bist du, ja, wie gesagt, wir hatten grad am Anfang im Intro über Gaming gesprochen. Ich weiß gar nicht, spielst du in deinem Projekt Factorio?
Stephan Strack (00:31:34 - 00:32:14)
Also, like, okay, find einen guten Sammelbegriff für Produktmanager, Projektmanager, POs und all vergleichbare Rollen. Zusammenfassend, die alle koordinieren Aufgaben. Selbstformulierte Begriffkoordinationseinheit ist vielleicht dann doch zu weit. Aber es geht ja darum, ich will mit den Leuten reden, die die Aufgaben koordinieren, die über den Schedule mitbestimmen und die wissen, was das einzelne Team macht. Die brauche ich als Projektmanager. Die haben die Information, was gerade funktioniert, ob alles on time ist oder ob es Probleme gibt. Und mit denen muss ich in ständigem Kontakt sein, damit ich weiß, ob das Projekt gesund ist oder meine Aufmerksamkeit braucht. Also ist häufiger Kontakt zu denen einfach notwendig.
Andy Grunwald (00:32:14 - 00:32:26)
Aber eine Verständnisfrage. Mir schwirrt die ganze Zeit das Wort Projektmanagementoffice im Kopf rum. Und jetzt redest du von Koordinationseinheiten. Ist das was komplett anderes oder passt das schon zusammen?
Stephan Strack (00:32:28 - 00:33:08)
So ein Projektmanagement-Office ist eigentlich eine schöne Institution, so vom Gedanken her. Ist eine Organisationseinheit, die führt quasi die Projektmanager, bildet die aus und standardisiert das Projektsbericht-Wesen und die Projektmethodik. Ist erstmal quasi die Idee, den kontinuierlichen Verbesserungsprozess im Projektmanagement durch die gesamte Organisation zu zentralisieren und dann sozusagen als Funktion umzusetzen. das kann natürlich auch ganz abstruse wildwüchse annehmen wo man halt prinzipien reiterei macht anstatt die richtige projektschablone fürs richtige projekt zu nehmen da muss man ein bisschen vorsichtig mit sein an sich der grundgedanke ist gut und das kann halt nur schnell aus.
Andy Grunwald (00:33:08 - 00:34:04)
Wenn du jetzt von pmo sprichst von projekt management office und von der standardisierung des berichtswesens. Und auf der anderen Seite hole ich mir gerade in meinem Kopf die Definition eines Projektes wieder in Erinnerung. Ein Projekt ist einzigartig, ist unik, das wurde zuvor noch nicht so gemacht. Also ist das Projektmanagement Office eigentlich dafür da, dass man alles, was man in einem Projekt standardisieren kann, also was projektübergreifend möglich ist, zu standardisieren. Und jetzt haben die 2000er-Jahre angerufen und haben gesagt, hey, pass mal auf, da gibt's Agilität. Und in der Agilität verändern sich ja auch immer die Anforderungen und so weiter. Und die sagen ja auch alle immer, Individuen, Interaktionen sind wichtiger als Prozesse. Funktionierende Software ist wichtiger als umfassende Dokumentation. Wie passt jetzt ein Projektmanagement-Office mit, ich standardisiere alles durch, was es so geht, mit der neuen Welt überhaupt zusammen?
Stephan Strack (00:34:04 - 00:34:57)
Genau das ist sozusagen der Punkt, auf den ich hinweisen wollte. Wenn man es falsch macht, blockiert das sozusagen den Fortschritt im Projektmanagement, vor allen Dingen auch in Bezug auf agile Methoden, die wir normal in der IT brauchen. Die Problemdomäne in der IT sind sehr komplex. Man braucht einfach die agilen Methoden, um iterieren zu können, um Wissen aufbauen zu können und sich selber verbessern zu können, im Sinne von den Kurs-zu-Ziel-Erreichungen zu optimieren und seine Arbeitsmethoden zu optimieren. Dass man darauf Fokus setzen will und Wert legt, kann auch ein Projektmanagement-Office installieren. Also du kannst ja als Projektmanagement-Office sagen, okay, wir würden gerne die Projekte in Zukunft mit AGI-Methoden machen. Das schließt sich ja nicht auf. Wenn du jetzt aber hingehen würdest als Projektmanagement-Office und sagen, wir machen in der IT jetzt nur noch Wasserfallprojekte, dann würde ich dem, glaube ich, nicht zustimmen. Kann sicherlich IT-Projekte geben, wo das gut funktioniert, also die klar umgeregelt sind, wo vorher klar ist, was am Ende passieren soll, aber die meisten Projekte höchstwahrscheinlich.
Wolfi Gassler (00:34:57 - 00:35:04)
Kannst du mir mal in einem Satz erklären, was ein Project-Management-Office wirklich ist oder was die Idee davon ist?
Stephan Strack (00:35:04 - 00:35:32)
Also die Idee vom Project-Management-Office ist, die Funktion Projektmanagement zu zentralisieren, also sozusagen als Funktion aufzubauen für die Organisation. Da wird das Projektmanagement-Framework, das angewendet wird, standardisiert oder aufgebaut. Das Projekt-Dokumentation und Bericht-Wesen wird standardisiert, dass alle Projekte gleichförmig reporten und damit auch vergleichbar sind und auch einen schnellen Überblick fürs Management erlauben. Und dann die letzte Aufgabe ist, die Projektmanager auszubilden, dass ihre Methoden kompetent sind.
Wolfi Gassler (00:35:33 - 00:35:59)
Eben, aber das ist ja dann eher so wie eine Guild oder wenn man jetzt im technischen Bereich ist, keine Ahnung, alle Java-Entwickler setzen sich zusammen, wie machen wir Java, aber die eigentliche Implementierung passiert dann in den Teams und in dem Fall wäre es ja selber im Projekt dann, arbeitet halt die jeweilige Projektmanagerin, die Projektmanagerin, aber unter Anwendung der Guidelines, die man gemeinsam besprochen hat oder definiert hat.
Stephan Strack (00:36:00 - 00:36:25)
Ja, es ist halt auch so ein Best-Practice-Katalog für Projektmanager. Also wie der Entwickler seinen Best-Practice-Katalog hat für gute Design-Patterns, haben die Projektmanager dann einen Design-Katalog für, so mache ich Projektdokumentation, so dokumentiere ich das, so mache ich meine Meetings-Notizen, so baue ich meine Meetings auf etc. pp. Wenn das alles standardisiert ist, ist es halt auch einfacher. Da musst du jetzt nicht für jeden Meeting neu überlegen, wie mache ich das, sondern du weißt, so wird das Meeting gemacht.
Wolfi Gassler (00:36:26 - 00:37:30)
Wenn ich noch mal kurz zurückspringen darf zu dem Dokumentationspunkt, weil da ja wirklich so ein großes Diskussionsloch aufgemacht hat, würde ich mal sagen. Und Andi ist ja da auch ein bisschen anderer Meinung. Und das ist ja, wie Andi jetzt auch schon scheinbar gegoogelt hat, ein Teil vom agilen Manifesto, funktionierende Software mehr als umfassende Dokumentation. Also Andi ist nicht agil demnach, weil er will ja alles genau dokumentieren. Aber meine Frage auch, hattest du da eigentlich nie Probleme irgendwie mit dem C-Level oder anderen Leuten, dass die gesagt haben, wo ist denn die Dokumentation, was habt ihr denn da beschlossen? Also da muss ja schon ein extremes Vertrauen auch da sein, dass man die Leute einfach laufen lässt, vor allem wenn da jetzt 100 Leute involviert sind und das heißt, naja, Dokumentation gibt's wenig. Da gibt's mal ein Bild von diesem Whiteboard oder von ganz vielen Whiteboards, aber wenn jetzt ein C-Level mir irgendwo Whiteboards ansehe, aber keine Ahnung, Kreuzung quer, irgendwelche Begriffe oben, Zeichnungen von irgendwelchen technischen Leuten. Da muss ich schon viel Vertrauen haben. Hattest du da nie Probleme mit dem Level, mit dem höheren Management?
Stephan Strack (00:37:30 - 00:38:18)
Der Informationsbedarf und das Zielevel ist, glaube ich, ein anderer. Und da benutzt man dann ein Reporting für. Es ist jetzt die Frage, ob wir Reporting mit den Dokumentationen einzählen wollen. Aber theoretisch schaffst du jede Woche oder alle zwei Wochen, je nachdem, was der Reportingzyklus ist, wieder ein Dokument, was den Status abgibt. Und ich glaube, was da wichtig ist, ist die Struktur. Du willst Top-Level wissen, ob du auf den richtigen Metriken korrekt unterwegs bist. Du sagst, okay, da sind die Metriken, die für den Projekterfolg richtig sind. Hier sind wir. Das haben wir erreicht. Das sind die aktuellen Schwierigkeiten, für die wir Entscheidungen oder Input aus dem C-Level brauchen. Und da ist der Rest vom Projektbericht aktuell, was getan und gemacht wird. sozusagen die einfachste und beste Stufe, das wirklich sehr komprimiert zusammenzubringen. Die Information zu aggregieren, macht allerdings viel Arbeit. Da muss man tatsächlich wieder mit allen Produktmanagern, Teilprojektmanagern und involvierten Teams reden, um das alles zusammenzutragen und dann sauber aufzubauen.
Wolfi Gassler (00:38:18 - 00:38:28)
Also du machst bewusst nicht den Schritt, dass du eine Dokumentation hast, um alles zu erschlagen, sondern wirklich je nach Stakeholder die richtige Information an den richtigen Stakeholder zu liefern.
Stephan Strack (00:38:29 - 00:39:27)
Hier, es gibt eine Projektdokumentation, die die Lösungsskizzen abbildet, die ich, wie beschrieben, benutzen würde oder auch aufbauen würde. Und dann tatsächlich das Reporting, was quasi nach oben ins Zieleimer geht. Und die kriegen jede Woche oder was auch immer der Zyklus ist, dann den Bericht, wo es ist. Die Frage aus der Business-Perspektive ist ja meistens auch, wie weit weg bin ich von der Lösung meines Problems, um ein strategisches Ziel zu erreichen? Und da ist das Reporting drin. Wie genau das jetzt konkret funktioniert, ich glaube, da sollte die Firma genug Vertrauen in die Mitarbeiter und Engineers haben, die sie eingestellt haben, dass sie sich schon die richtige Lösung wählen. Wenn jetzt der Bedarf steht, da reinzugucken, dann meistens nur, weil das Reporting gesagt hat, wir kommen wiederholt in Probleme, die wir nicht lösen können. Dann ist man in so einem Szenario, wo man, glaube ich, eh sich neu verbinden muss, weil man dann meistens feststellt, das, was wir machen wollen, funktioniert nicht. Und dann muss man eh zu Sachen kommen. Aber andernfalls ist die Frage, wieso sollte sich das Z-Level denn tatsächlich auch für die Implementierung zu Details so genau interessieren?
Wolfi Gassler (00:39:28 - 00:39:40)
Du hast eine gute Meinung von dem C-Level. Ich kenne da sehr viele C-Levels, die sehr wohl Interesse haben an den gleichen Details und vielleicht sogar noch irgendeine Vorschleife am Wochenende optimieren wollen.
Stephan Strack (00:39:40 - 00:39:46)
Das kann ja auch mal im Einzelfall notwendig sein und habe es auch tatsächlich so dann erlebt, dass man eng mit dem C-Level zusammenarbeitet.
Wolfi Gassler (00:39:46 - 00:39:51)
Du kannst es sehr positiv schön formulieren, sehr eng zusammenarbeiten. So kann man das auch nennen.
Stephan Strack (00:39:51 - 00:40:23)
Ja, dem einen oder anderen Entwickler lief dann auch schon die Schweißschmerzen in die Stirn runter. Es war tatsächlich schon ein umdrehendes Gefühl. Ich würde so eine Situation auch liebend gern vermeiden, wenn sie es vermeiden lässt. Auf der anderen Seite, am Ende hat es tatsächlich dem Projekt gut getan. Das muss man dann am Ende auch sagen. Also wir haben die Fehler gefunden und behoben. War also definitiv eine gute Sache, dass der CEO mal vorbeigekommen ist. Und zeigt aber, glaube ich, auch, dass es dem CEO wichtig ist. Darf man dann auch nicht unterschätzen. Wenn der sich sozusagen die Zeit aus seinem Arbeitsalltag nimmt und schützt sich mit strategischen Themen zu beschäftigen, mit der Frontlinie des Projekts arbeitet, zeigt das auch irgendwie Bereitschaft und Interesse.
Andy Grunwald (00:40:23 - 00:40:42)
Naja, kann aber auch anders heißen, kann auch Micromanaging sein oder ich vertraue meinen Leuten nicht, dass die alles richtig auf die Straße bringen. Also wir können jetzt hier den Happy Pass quatschen oder wir können auch einfach mal sagen, dass es auch Leute gibt, die sagen, hör mal, wieso steht jetzt hier, ihr braucht eine Woche. Damals, als ich das gemacht habe, hätte das zwei Tage gedauert.
Stephan Strack (00:40:42 - 00:41:04)
Warum ist der Prozess denn jetzt so kompliziert? Damals war das viel einfacher. Ja, genau. Der Unternehmenskontext hat sich halt weiterentwickelt. Die Probleme, die zu berüchtigen sind, sind mehr. Es ist halt einfach nicht mehr so einfach, wie man das damals zusammen geputscht hat. Heute ist da halt einfach ein bisschen mehr dahinter. Ja, trinke ich. Also ich stimme dir zu. Manchmal gibt es auch so Fälle, wo man sich dann lieber den CEO schnell wieder wegwünscht. Aber dann ist er da, die sind schwer zu bewegen.
Wolfi Gassler (00:41:04 - 00:41:25)
Jetzt haben wir den Punkt funktionierende Software mehr als umfassende Dokumentation eben aus dem agilen Manifesto jetzt schon sehr tief besprochen. Würdest du im Allgemeinen sagen, dass man wirklich auf dem Level, wenn man so große Projekte hat, wo man jetzt wirklich, sage ich mal, 200 Leute oder so in irgendeiner Form eingebunden hat, kannst du diese Projekte wirklich agil durchführen?
Stephan Strack (00:41:25 - 00:42:37)
Ich würde fast sagen, du musst. Du brauchst ein komplexes System über viele Teams hinweg. Und die Teams sind normalerweise sehr spezialisiert und bearbeiten alleine schon eine sehr komplexe Problemdomäne. Wenn du jetzt zehn solche komplexen Problemdomänen hast, ist überhaupt noch ein einziges menschliches Hirn in der Lage, alle Konsequenzen und jeden Impact zu evaluieren? Höchstwahrscheinlich nicht. Wenn das nicht mehr geht, dann brauchst du ja ein Framework, in dem du hingehst und sagst, okay, das ist mein Best Guess, den baue ich jetzt mal. Dann drücke ich das grüne Knöpfchen und dann gucke ich, wie sich das System verhält. Und wenn das gut ist, cool, dann machen wir die nächsten Features. Und wenn das nicht funktioniert, okay, nächste Iteration. Du hast ja gar keine andere Wahl. Ansonsten spielst du, glaube ich, eine sehr risikoreiche Wette. Ansonsten würdest du behaupten, ich bin in der Lage, an dem Whiteboard durch zehn Teams eine so komplexe Software zu designen, dass ich die tatsächlich im ersten Versuch sauber umsetzen kann. Und dann funktioniert die genauso, dass sie unser Problem löst. Unwahrscheinlich. Also dann der zweite Fall halte ich für extrem unwahrscheinlich, wenn du so ein großes Projekt hast. Und dann geht's halt einfach nur iterativ. Das sukzessive an allen Schräubchen das System immer wieder weiterentwickeln, sodass du dich der finalen Lösung näherst.
Wolfi Gassler (00:42:37 - 00:42:48)
Wenn wir jetzt mal abgesehen von der Dokumentation, die der Wasserfall Andi natürlich gerne hätte, Weglassen. Was wären noch so Punkte in der agilen Welt, auf die man achten muss?
Stephan Strack (00:42:48 - 00:43:25)
Ich glaube, wenn man so ein großes Projekt macht, was man aus der agilen Welt mitnehmen muss, ist das, auch wenn man eine Projektinitialisierung gemacht hat, die notwendig ist, um das Projekt richtig ins Rollen zu bringen. dass doch am Ende das Projektziel immer noch eine lebende Sache ist und das sich tatsächlich auch verändern kann. Also der initial vereinbarte Vertrag mit den Stakeholdern, der wird sich im Laufe des Geschehens wandeln. Einfach weil du unterwegs eine Menge darüber lernst, wie die Teams miteinander arbeiten, was tatsächlich möglich ist und was nicht möglich ist in dieser Softwarelandschaft. Das ergibt Sicherheit. Und da musst du halt auch flexibel bleiben, dass du da in der Lage bist, das nochmal neu zu evaluieren, neu zu erörtern. Das würde ich definitiv sagen.
Wolfi Gassler (00:43:26 - 00:43:33)
Aber das ist dann mehr eine Mindset-Sache, dass man sich darauf einlässt, oder kann man da irgendwie vom Prozess her auch einwirken?
Stephan Strack (00:43:35 - 00:44:12)
Ich glaube, das ergibt sich sozusagen aus der anfangs beschriebenen Idee, wenn man mit so einem Engineering-Team so das erste Lösungskonzept gebaut hat, dann sieht man, wie nah bin ich denn überhaupt an der strategischen Zielerreichung? Und dann kommt die Diskussion ins Rollen. Wenn ich näher an das Ziel kommen will, wie viel mehr Investment habe ich denn dann im Hadas, der Preis ist mir zu hoch. Okay, kann ich vielleicht 10% mehr haben? Ja, kostet 10% mehr Einsatz. Okay, das ist ein fairer Preis. Dann fängt man sozusagen an, das Projekt hier so ein bisschen rauf und runter zu bewegen. Und ich glaube, das ist ein ganz gesunder Prozess für die Unternehmung, das auszuloten. Der sollte auch vorangetrieben werden, damit auch alle wissen, dass sie das Richtige machen. Mehr als das MVP abgeben, aber auch keine Over-Engineering betreiben.
Andy Grunwald (00:44:13 - 00:45:25)
Ich frage mich gerade, die Welt ist schnelllebig, alles schön. Und du sagtest auch gerade, während eines Projekts ändern sich Sachen. Die Gegenfrage, die hässliche Gegenfrage, die keiner hören möchte, ist der Zeitraum des Projektes da nicht einfach viel zu lang, wenn sich kontinuierlich vielleicht auch Grundpfeiler ändern können? Ich geh mal aus der praktischen Seite heraus. Ich bin Softwareentwickler, ich setz mich dahin. Wir planen eine Architektur, vielleicht schreiben wir ein Designdokument. Dann haben wir uns nach zwei Wochen die Köpfe eingeschlagen, weil wir kennen das ja alle. Nutzen wir jetzt React oder Vue.js? Nutzen wir jetzt J2EE oder Spring? Nutzen wir überhaupt Java? Oder sollen wir nicht mal Go ausprobieren? All diese Sachen, die vielleicht für das strategische Projekt zählen, wie du es immer so nennst, vielleicht gar keine Rolle spielen. Auf jeden Fall haben wir uns nach zwei Wochen endlich mal geeinigt. Und dann ändert sich irgendein fundamentaler Pfeiler. Und dann denkt man sich so, vielen lieben Dank für Ihre Zeit, wir gehen zurück ans Reißbrett. Ist da nicht eher der Ansatz von kontinuierlichen, kleinen, iterativen Schritten besser, als immer dieses, ich gehe in den Keller, Bau, Bau, Bau, bis jemand an die Tür klopft und sagt, so nicht, Jungs, wir müssen nach links und nicht nach rechts.
Stephan Strack (00:45:25 - 00:46:38)
So eine Unternehmung ist im Wandel. Also was die Unternehmung als Produkt macht, wen sie als Kunden hat, was sie strategisch erreichen will, das ist eine permanenten Forderung. Das heißt also, der Kontext, in dem du dann das Software implementierst, der ist eh per se im Wandel. Und irgendwann wird sich die Unternehmung so weit verschoben haben, dass die Software, die du geschrieben hast, gar nicht mehr zum Kontext kommt. Es wird so oder so eintreten. Wenn das der Fall ist, würde ich jetzt die unpopuläre Meinung vertreten, dass du deine Software so gestaltest, dass du nach Herzenliebens alles, was sie betreibt, erbarmungslos austauschen oder wegschmeißen kannst, ohne dass du viel Trennungsschmerz. Okay, und dann der zweite Punkt dazu ist, dann sollte auch der Entscheidungsweg, zu solchen Entscheidungsauswahlen zu kommen, möglichst günstig sein. Weil du bist ja sozusagen eh bereit zu sagen, naja, Das klingt plausibel, wir machen das jetzt mal, solange bis der Kontext sich eh verschoben hat, nicht mehr passt, dann müssen wir eh was anderes machen. Also das Investment in die Entscheidung oder dazuranzugehen, das ist eine Entscheidung für immer, ist vielleicht für die Kerngeschäftsprozesse, aber dann so für so eine Technologie war, wir sind auch alle vom Data Center in die Cloud migriert. Obwohl wir alle gedacht haben, wir werden auf Servern arbeiten, es wird immer wieder irgendwas kommen, was uns durcheinander bringt und uns zwingt, neu zu denken. Wir sollten uns eher darauf vorbereiten, dass das der Normalfall ist und dass der höchstwahrscheinlich nur häufiger eintritt als seltener in der Zukunft.
Andy Grunwald (00:46:38 - 00:47:29)
Also ich meine, einer der Punkte ist ja auch reagieren auf, reagieren, nicht regieren, regieren wird das, irgendjemand regiert das Projekt vielleicht auch, aber reagieren, reagieren auf Veränderungen mehr als das Befolgen eines Plans und Wie schaffst du es als Projektmanager denn mit den Softwareentwicklern die Balance zu finden, die ganze Sache nicht over zu engineeren, weil wenn mir als Softwareentwickler jemand sagt, wir bauen das jetzt, kann aber sein, dass diese Woche noch drei Änderungen kommen, dann versuche ich natürlich meine Software so zu bauen, dass sie höchst variabel ist, höchst flexibel und ich hoffe mal du hast das schon mehrmals in deinem beruflichen alltag erlebt wie argumentierst du dagegen du sagst auf der einen seite du musst bereit für veränderungen sein kannst nicht immer dem plan hier folgen soll es aber bitte nicht overingenieren und für alle möglichen probleme gewappnet sein sondern das heutige problem.
Stephan Strack (00:47:29 - 00:49:07)
Lösen genau also nehmen wir mal an und du würdest eine suche nach objekten betreiben jetzt kannst du sagen wir machen eine suche über adressen oder wir machen eine suche über eine GeoSearch. Wir suchen einfach in irgendeinem Radius irgendetwas. Okay. Heute sagen wir, wir machen die Adresssuche. Gut, okay. Also musst du deine Suche so bauen, dass sie die Adresssuche kann. Jetzt würde ich aber dir empfehlen, die Architektur so zu bauen, dass sie sagt, ja, eventuell wollen wir mal die Sorte Suche mal austauschen. Schreib das doch mal so, dass du die Komponente austauschen kannst gegen eine andere. Also ich will jetzt nicht, dass du eine superflexible Software schreibst, die alle hat, sondern dass du eher darüber nachdenkst, die Komponente, die könnte man austauschen durch andere Variationen und es ist höchstwahrscheinlich, dass das passiert. Und das ist so ein Input, den muss ich als Projektmanager dem Team natürlich richtig geben, damit die wissen, an welcher Stelle muss das denn flexibel sein und an welcher Stelle ist das der Kerngeschäftsprozess, der geht nicht weg. Also, dass wir immer wie Objekte suchen werden, wird der Fall sein. Okay, gut. Dann hast du sozusagen einen Rahmen, der bleibt stabil, aber innen drin sind Dinge, die du einfach austauschen kannst. Und dann mit den Veränderungen mit so vier Teams ist trickerig. Also wenn ein Team eine Veränderung macht, dann hat das meistens Implikationen auf die Teams, die neben dran sind. Und da ist so ein bisschen Fingerspitzengefühl gefragt, wo du dann die Teaminteressen ausbalanciert musst. Weil es kann nicht sein, dass ein Team eine Veränderung macht, dass du total negative Auswirkungen auf die Teams links und rechts hast. Und da ist Moderation gefragt. Da muss man als Projektmanager reingehen, das Erkenntnis machen und da den guten Trade-off finden für. Du kannst die Veränderung machen, wir können das mitziehen mit ein bisschen mehr Arbeitsaufwand, das macht Sinn. Aber wenn das zu extrem gilt, dann sorgt das für Frust im System und dann kommt das Projekt auch ins Stocken. Weil die Leute dann sagen, die machen irgendwas, das können wir nicht mittragen, so können wir nicht arbeiten, dann hast du so richtig Wüsten-Tumult im Projekt.
Andy Grunwald (00:49:08 - 00:49:23)
Moderation das wort wenn du das so aussprichst wenn du sagst okay mehrere teams können sich nicht einigen und du musst moderieren hört sich an eher an sowas wie eine mediation die ich zum beispiel aus kenne wenn sich irgendwie zwei anwälte in die köppe hauen.
Stephan Strack (00:49:23 - 00:50:13)
Ja ist auch so also da sind ja da sind ja experten, die sagen so funktioniert das nicht und das ist ja so erstmal im ersten schritt erstmal ernst zu nehmen versucht zu hinterfragen jetzt hast du aber zwei davon also die haben ja beide irgendwie recht und von dem standpunkt aus musste irgendwie anfangen und dann sich zu fragen okay wenn jeder so ein bisschen rechts hat dann gibt es doch auch irgendwie eine lösung wo beide was vom teil haben können Damit kann man ja erst mal als These anfangen. Musst du ja auch. Stell dir vor, du löst es nicht. Der eine Prozessteil ist hier, der andere da. Die streiten sich über ihr Interface oder die Konsequenzen, die sie da haben. Dein Prozess funktioniert ja nicht mehr. Du kannst ja gar nicht mehr end-to-end das Ergebnis erzeugen. Also du musst da rein als Projektmanager das machen. Und ja, es ist Mediation, herauszufinden, was zu tun ist. Gott sei Dank gibt's auch fähige Team-Meets, die einem dann dabei helfen, das irgendwie gut über die Bühne zu bringen. Man ist da ja Gott sei Dank nicht alleine.
Wolfi Gassler (00:50:14 - 00:51:01)
Aber umso mehr ich da eigentlich zuhöre, ist, wenn man so Projekte agil angeht, dann muss man noch viel mehr Zeit und Energie in die ganze menschliche Seite und in die ganze Moderationsseite investieren. Und eigentlich musst du dann auch ein guter Moderator oder Meetingführer sein und weniger ein klassischer Projektmanager, der in Excel irgendwie die Deadlines definiert und vielleicht ein bisschen kommuniziert, sondern wirklich ganz stark in mit den konkreten Leuten, die das dann umsetzen, ins Gespräch gehen, in Diskussion gehen, moderieren, wirklich die ganzen Leute unter den Hut bringen und halt in größeren Meetings immer dann zu Ergebnissen kommen am Ende. Also ist diese Skill eigentlich noch viel, viel wichtiger, wenn man die ganze Sache agil angeht.
Stephan Strack (00:51:01 - 00:51:53)
Definitiv. Der Projekterfolg hängt ja maßgeblich davon ab, wie engagiert die Leute sich ins Projekt einbringen und wie viel Mehrwert sie dadurch erreichen. Und das hat ja sozusagen dann auch Implikationen für den Unternehmens. Wenn das Projekt schnell und zügig vonstatten geht, kannst du als Firma schneller mehr Mehrwert schaffen und auch deinen Kunden muskeln. Okay, das heißt auch, dass die richtig motivierten Leute Vortrieb schaffen. Okay, dann heißt also auch zur Aufgabe des Projektmanagers gehört es dazu, mit dafür zu sorgen, dass die Motivation aufrecht ist. Und dann musst du halt genau diese Themen irgendwie bearbeiten. Und da gibt es auch Prozesse und Werkzeuge. Also wie ich schon mal gesagt habe, gute Meeting-Moderation oder gute Meeting-Facilitation. Das ist halt so ein Pool-Build für einen Projektmanager, damit der in der Lage ist, die Leute motiviert vorantreiben zu können oder auch motiviert, Konflikte lösen zu können. Zügig, reibungslos, mit dem Gefühl von, ja, wir machen hier gemeinsam das Richtige. Klar gehört das dazu.
Andy Grunwald (00:51:54 - 00:52:41)
Ich grinse die ganze Zeit, weil vielen lieben Dank, Stefan. Du bist einer der Personen, die bestätigen eine Sache, die ich halt immer sage. Und das ist unter anderem auch der Grund, warum Wolfgang und ich diesen Podcast machen und warum wir auch so Themen wie Projektmanagement in einem Software-Engineering-Podcast behandeln. Ich beziehungsweise, ich hoffe, auch Wolfgang so ein bisschen inzwischen, sagen ja immer, die Technik ist kompliziert. Verstehe mich nicht falsch, aber die richtige Herausforderung ist halt immer, mit den Menschen zu arbeiten. Deswegen haben wir auch so viele, ich sag mal, Metathemen hier. Und endlich, endlich, endlich sagt eigentlich jemand wie du genau das Gleiche, ohne dass ich ihm das in den Mund gelegt habe, so nach dem Motto, ja, die Moderation ist so wichtig, weil die hauen sich eh immer die Köpfe zusammen. Wollte ich nur mal kurz danke sagen.
Stephan Strack (00:52:42 - 00:53:34)
Gerne, Andi. Ja, ich kann es dir aus meiner persönlichen Erfahrung auch sagen. Es macht am meisten Spaß, mit engagierten Engineers zu reden, die wirklich Lust haben, gute Architektur zu machen, eine gute Infrastruktur aufzubauen und auch exzellente Features zu schreiben, mitdenken und auch über Probleme und Randfälle nachdenken und Lösungen vorschlagen. Ein super kreatives Arbeiten, das eine Menge Spaß und eine Menge Vortrieb mitbringt. gehört, glaube ich, zur Aufgabe von allen, die mit Führung zu tun haben, in so einer Unternehmung das Ausrecht zu erhalten. Weil das trägt alle mit. Das ist ansteckend. Also, das ist tatsächlich im Sinne positiv ansteckend. Und nach so einem Projekt werde ich noch mit alten Projektmitgliedern in Kontakt binden, die sagen, Mensch, das war zwar super anstrengend, aber es war auch eine extrem gute Zeit, weil wir sehr viel geschafft haben. Und ich glaube, dieser Eindruck von, es war anstrengend, man war aber auch fleißig, war ganz wichtig für die persönliche Entwicklung, auch die Medikation damit zu tragen.
Wolfi Gassler (00:53:34 - 00:54:30)
Vielleicht noch, um Andi ein bisschen dagegen zu reden, eine Hypothese von mir, um wieder auf die Design-Dokumente von Andi zu kommen. Meine Hypothese ist ja, dass du diese Dynamik, die du jetzt gerade beschrieben hast, Stefan, dass du die über Design-Dokumente und über einen asynchronen Weg der Zusammenarbeit nicht hinbekommst. Weil ich kann mich da an so Meetings erinnern, Du setzt dich da gemeinsam rein, bist fast unvorbereitet, würde ich mal sagen. Du bekommst so eine Dynamik in den Meetings. Du bekommst vorgelegt, okay, was wollen wir heute entscheiden? Stefan hat das super vorbereitet. Diese Punkt, Punkt, Punkt, das müssen wir heute entscheiden. Das ist der Input. Wie kommen wir dorthin? Und du hast eine super Dynamik in dem 1-Stunden-Meeting und machst die Entscheidung. Ich glaube, dass diese Dynamik schwierig ist über einen asynchronen Weg und Design-Dokumente. Vielleicht ist es nötig, weil man nicht anders zusammenarbeiten kann, oder es ist schwierig, aber die Dynamik fehlt, meiner Meinung nach. Ist zumindest meine Hypothese.
Stephan Strack (00:54:30 - 00:54:51)
Ich würde es auch immer wieder bevorzugen, eine Entscheidung in der Gruppe zu machen, wo sich alle physisch oder virtuell ins Gesicht gucken und sagen, ja, genau das machen wir so. Wir sind alle damit einverstanden. Das hat meiner Erfahrung nach wesentlich höheren Erfolg als Asynchro des Dasein-Dokument. Habt ihr noch Kommentare? Jeder gibt seinen digitalen Daumen hoch. Und dann redet man am Ende doch noch mal an einem Meeting darüber, was dann irgendwie doch nicht gepasst hat.
Andy Grunwald (00:54:52 - 00:55:13)
Okay, jetzt reden wir hier gerade über Asynchron und Synchron. Das ist super. Finde ich, ihr habt einen validen Punkt. Wie verhält sich die ganze Sache denn im Office und remote? Weil, wenn wir jetzt die Situation von Wolfgang nehmen, ich komme etwas unvorbereitet in ein Meeting. Herr Gassler, ich hoffe, das passiert hier nicht mehr, ja? Wir bereiten uns hier vor.
Wolfi Gassler (00:55:13 - 00:55:14)
Mit dir nie.
Andy Grunwald (00:55:14 - 00:55:35)
Und remote hat man ja, offengesprochen, ein anderes Engagement, als wenn wir jetzt alle in einem Meetingraum sitzen. Meine Erfahrung ist im Durchschnitt, dass das Engagement in Videocalls niedriger ist, als wenn wir zusammen in einem Meetingraum sitzen. Hat das auch einen Impact auf dieses, wir treffen uns alle in der Entscheidung, oder ... Ich mein, Stefan, du arbeitest jetzt grad remote, richtig?
Stephan Strack (00:55:35 - 00:55:36)
Ja.
Andy Grunwald (00:55:36 - 00:55:57)
Und du hast jetzt so mit dem direkten Vergleich, du hast sehr große Projekte in einem In-Office-Setup durchgeführt, du hast komplexe Projekte in einem Remote-Setup durchgeführt. Wie ist ... Wie ... Ändert sich der Outcome oder die Geschwindigkeit, in der sich das Projekt bewegt, in Bezug auf, ob wir remote sind oder in Office? Endlich mal jemand, der sagt, dass ich gute Fragen stelle.
Stephan Strack (00:55:57 - 00:57:18)
Die gefühlte Geschwindigkeit als Projektmanager in einem On-Office-Projekt ist auf jeden Fall höher. Es ist wesentlich rasanter, weil man einfach eine erhöhte Frequenz mit Projektbeteiligten redet, als wenn man das remote machen würde. Remote haben wir noch, auf der anderen Seite die Möglichkeit, sehr fokussiert, mal schnell für zwei Stunden das Projekt zu durchdenken, nächste Schritte zu machen, zu durchorganisieren, was normalerweise lokal nicht gegeben ist, weil sofort hier einer ankommt und sagt, wir müssen hier einfach schnell drüber reden. Es ist sozusagen schwierig für mich zu benchmarken. Was ist jetzt nun wirklich schneller? Gefühlt ist lokal schnelllebiger. So ist es einfach nur, weil schneller mehr kommuniziert wird. Und an dem anderen Teil schwierig. Wo ich dir auf jeden Fall zustimmen muss, Andi, ist die Entscheidungsfindung in den Meetings. Also die digitale Versuchung in Remote Meetings ist per se zu hoch. dass man sich digital schnell mal mit Slack-Messages beschäftigt, hier noch nur die Dokumentation liest und da noch mal schnell die E-Mail beantwortet, während das Meeting über ein Thema langläuft, was einen nur am Rande tagiert. Und man hört ja noch mit einem Ohr zu. Und schwuppdiwupp sind die Leute abgelenkt vom Meeting. Ist dann auch immer schwierig in der Moderation, wenn man da zur Entscheidungsfindung kommen will. Da muss man immer die Leute ganz sanft zurück ins Meeting holen, weil man will die ja auch nicht dann bloßstellen. Und dann kann man dann wieder die Entscheidungsfindung machen. Du hast immer die Gefahr, dass die Leute dich sauber zugehört haben. In so Meetings, wo die physikalisch alle zusammensitzen, hast du so viele Möglichkeiten, die Aufmerksamkeit zurückzuholen. Und da sitzen die Leute einfach nicht mit dem Laptop und chatten. Also das macht schon einen Riesenunterschied.
Andy Grunwald (00:57:18 - 00:57:27)
Ich finde deine Aussprache ein bisschen niedlich. Aber wie holt man denn Leute sanft in ein Meeting zurück? Und dann in demselben Satz das Wort bloßstellen erwähnen.
Stephan Strack (00:57:28 - 00:57:55)
Teamname ist sehr sehr gut also du musst irgendwie dass sie so sagen das ist mein mentaler marker es geht um mein team und dann erst die tatsächliche frage stellen dann wissen sie also ein team in meiner rolle ich bin gefragt und dann stellst du erst die tatsächliche frage wenn du erst die frage stellst und dann komma name fragezeichen das ist bloßstellen. Weil dann wird er nämlich sagen, was war die Frage? Und dann wissen alle, er hat nicht zugehört. So was machen wir bitte nicht. Aber man kann die schon ganz gesagt. Okay, bleibt jetzt jedem selber überlassen.
Andy Grunwald (00:57:55 - 00:57:56)
Niedliche Strategie.
Stephan Strack (00:57:58 - 00:57:59)
Egal.
Andy Grunwald (00:57:59 - 00:58:02)
Oder vielleicht ein Kommunikations-Manipulations-Trick. Ich weiß es nicht.
Stephan Strack (00:58:02 - 00:58:08)
Also man ist ja darauf angewiesen, dass die Leute, dass die Leute mit einem zusammenarbeiten wollen und dann muss man halt auch freundlich sein.
Wolfi Gassler (00:58:08 - 00:58:48)
Also ich hänge sehr stark an der Dokumentation heute rum, ist schrecklich, aber es ist irgendwie ein interessantes Thema. Du arbeitest ja mittlerweile in einem Unternehmen, was, kritischere Dinge eben produziert mit Pharma und so weiter, wo auch Regulatorien viel stärker sind. Glaubst du, dass das trotzdem in irgendeiner Form agil geht? Oder hat man da dann irgendwie die Probleme, wenn man so Regulatorien zu erfüllen hat, wo man ganz viel dokumentieren muss, wo alles nach ganz speziellen Prozessen geht? Keine Ahnung, ob das jetzt bei euch so streng ist, aber Wenn man ein Medizinprodukt oder so entwickelt, zum Beispiel, ist das ja oft extrem streng. Glaubst du, dass da agil überhaupt noch möglich ist? Oder sind das irgendwie Dinge, die in die gegenseitige Richtung arbeiten?
Stephan Strack (00:58:48 - 01:00:21)
Ich würde agil oder nicht agil nicht von den Regularien abhängig machen. Wenn du mich fragen würdest, Stefan, wer entscheide ich denn, ob ich ein agiles oder nicht agiles Projekt machen will, würde ich dir empfehlen, guck mal jetzt Coolwin Framework. Da gibt es eine ziemlich coole Beschreibung zum Thema Problemdomänen. Das kategorisiert die Welt ein. simple Probleme, komplizierte, komplexe, chaotische und absolutes Durcheinander. Und dann gibt es zwei Teilbereiche, die so fürs Projektmanagement relevant sind. Das eine sind die komplizierten Projekte. Die sind groß und da gibt es viele Zusammenhänge, die kann man aber im Voraus fast vollständig analysieren. Also du willst ein Haus bauen oder du willst eine Brücke bauen. Das lässt sich im Prinzip im Voraus mit moderner Softwaretechnologie, guten Architekten und Ingenieuren vollständig durchplanen, wie das Ding am Ende aussehen wird. Also du kannst, es ist wesentlich mehr vorhersehbar, wie das Projekt am Ende aussehen wird. Und dann gehst du dann so rüber zu uns in die IT. Wir wissen am Anfang noch nicht so genau, wie die letzte Gezeile geschriebener Code aussieht, wenn wir so ein Projekt anfangen. Wir wissen quasi nur so grob, in welche Richtung. es geht. Wir entdecken sozusagen, was das finale Projektergebnis sein soll und ob wir mit den richtigen Methoden arbeiten. Nur beim Doing. Wir lernen das along the way. Und das sind so Projekte, wo du agil anwenden. Da würde ich dir entscheiden. Also das ist für mich, und du kannst auch in einem agilen Projekt auch Restriktionen und Dokumentationen alles entgegennehmen und machen. Also für mich ist vielmehr die Frage, okay, kann ich das Thema im Voraus vollständig durchschauen und dann mach ein klassisches Wasserfallprojekt. Wird auf jeden Fall funktionieren. Oder ist das so komplex, dass ich vorher gar nicht sagen kann, wie genau das Entdecken das aussieht und mach auf jeden Fall an dieses Projekt.
Andy Grunwald (01:00:22 - 01:01:06)
Ich hatte die Podcast-Episode oder beziehungsweise deine Vorstellung ja unter anderem auch mit einem Mythos begonnen. Mit diesem Mythos von neuen Frauen bringen ein Kind in einem Monat zur Welt. Und ein zweiter Mythos von Projektmanagern ist eigentlich, dass Projektmanager oder dass viele Projektmanager eigentlich gar keinen Plan haben von dem, was sie da managen. Das bedeutet, was das Projekt eigentlich macht, die Details und Co. Wie ist deine Meinung in Bezug auf diesen Mythos? A. Müssen Leute, die ein Projekt managen, denn Ahnung von dem haben, was sie da managen? Oder B. Müssen sie wirklich offengesprochen einfach nur gute Manager sein, mit logischem Denken, Priorisierung und klassische Werkzeuge in der Toolbox haben?
Stephan Strack (01:01:07 - 01:02:15)
Okay, ich würde sagen, du kannst, wenn du so ein Projekt anfängst, ahnungslos sein. Solange du eine gute Methodenkompetenz hast und in der Lage bist, Themen zu durchdringen. Weil im Projekt selbst ist es zwingend notwendig, dass derjenige, der das Projekt leitet, das Projekt auch versteht und durchschaut und die Zusammenhänge begeistert. Wenn das unterwegs nicht passiert, sehr schlechte Karten. Weil einer muss das ja zusammenhalten und der Einzige, der den Komplettüberblick hat, ist theoretisch der Projektmanager oder auch Subprojektmanager in den Teilbereichen. Aber die müssen die Themenfelder ja durchdringen. Die müssen am Ende auch zur Not auch entscheiden und sagen können, ja so oder nein so, weil die Konsequenzen sind erwünscht oder unerwünscht. Wenn du das nicht kannst, dann hast du ein sehr großes Problem dadurch. Du müsstest dir dann irgendwie eine Möglichkeit schaffen, diese Evaluierung auszulagern oder an jemand anderen zu delegieren. Dann ginge es vielleicht, aber du siehst schon, dann wird es halt richtig umständlich, weil solche Entscheidungen hast du am laufenden Band. Einfach nur, Ticket ist in der Entwicklung, der Ingenieur fragt, so oder so haben wir vorher nicht drüber nachgedacht. Wenn du jetzt zwei Tage brauchst, um das zu evaluieren, und das passiert dir 200 Mal im Projekt, hast du schon direkt 200 Tage vor Zug im Projekt. Einfach so.
Andy Grunwald (01:02:16 - 01:02:37)
Im Endeffekt reduziert das natürlich auch irgendwie deinen Respekt als Projektmanager, richtig? Ich meine, jetzt kann man den Respekt durch Autorität vielleicht ersetzen und ich sag mal alles durchdrücken, was vielleicht nicht ganz so gut ist, aber ich hab so das Gefühl, umso mehr Respekt die Software-Engineers und die Projektinvolvierten vor dir haben, umso flüssiger läuft das vielleicht.
Wolfi Gassler (01:02:38 - 01:03:41)
Ich glaube auch, dass gerade diese Interaktion, wenn du direkt mit den Engineers zusammenarbeitest, dass du da einfach ein gewisses Gefühl haben musst, wie du mit denen zusammenarbeitest. Weil, wie gesagt, so Technologiediskussionen, wenn du da jetzt ganz hart nur auf Projektmanagerebene dann das killst oder so, dann hast du auch ein Problem. Also du musst da, glaube ich, irgendwie ein gutes Gefühl dafür haben, wie weit kann man gehen bei so einer Diskussion. Wann wird es zu viel? Wo ist Overengineering? Solche Dinge, die helfen, glaube ich, schon extrem. Ich glaube gar nicht, dass du unbedingt Entwickler gewesen sein musst, aber es hilft dir natürlich, wenn du diese Muster verstehst und die Erfahrung vielleicht hast schon mal von anderen Projekten, wie dicken denn so EntwicklerInnen und wie kommt man denn am besten zu einer Entscheidung? Wahrscheinlich sowas hilft dir vermutlich mal schon und für mich als Entwickler, ist es natürlich auch gut, mit solchen Leuten zusammenzuarbeiten, die das schätzen und die mir da jetzt nicht ständig irgendwie, hey, müsst ihr euch jetzt entscheiden und eure scheiß Diskussion, macht ihr mal das woanders und jetzt brauchen wir eine Entscheidung, ob Java oder Go.
Stephan Strack (01:03:41 - 01:04:38)
Ich glaube, der soziale Kitt zwischen Engineer und Projektmanager funktioniert immer dann gut, wenn die Engineers das Gefühl haben, der Projektmanager hat uns klar verstanden und er ist in der Lage, uns zu folgen. Und wenn das nicht passieren kann, dann kriegst du ein sehr großes Problem, weil die Engineers nicht glauben, dass der Projektmanager das richtig durchschaut, was zu tun sei. Und wenn du jetzt einen Arbeitsauftrag kriegst von jemandem, von dem du glaubst, dass er nicht so richtig durchschaut, was zu tun ist, dann bist du nicht so richtig motiviert, den Schreibtisch in die Hand zu nehmen und loszuarbeiten. Dann hast du ein Riesenproblem und dann funktioniert das ganze Projekt. Leider solltest du die Fähigkeit haben, begeisterungsfähig zu sein und dazu positiv zu sein und auf jeden Fall stark daran zu glauben, dass das Projektziel auf jeden Fall gut ist und erreicht wird. um die Leute mit motivieren zu können. Und wenn das in Zweifel gerät, dann kommt das Projekt sofort in Stock, weil die Leute gar nicht mehr engaged sein können, weil sozusagen die Galleonsfigur des Projekts nicht mehr genug Engagement versprüht, dass die Leute folgen wollen. Und dann bremst du einfach am Sack und die Projekte verlaufen, weil keiner will mehr mitmachen.
Andy Grunwald (01:04:39 - 01:04:41)
Ist der Projektmanager die Galionsfigur des Projektes?
Stephan Strack (01:04:42 - 01:04:51)
Sollte er. Ich meine, du kannst einen guten Projektsponsor haben, der das vielleicht ausgleichen kann, aber idealerweise, wenn du in die Ökonomie Handtücher gucken würdest, klar steht das gerade drin als Aufgabe des Projektmanagers.
Wolfi Gassler (01:04:51 - 01:05:05)
Du arbeitest ja mit dem tagtäglich dann zusammen auch, also das ist ja, ein Sponsor ist ja irgendwo entfernter, aber wenn du mit der Person ständig am Arbeiten bist und, also danke Stefan übrigens, war eine gute Zeit, aber wir haben da doch sehr viele Stunden gemeinsam verbracht.
Andy Grunwald (01:05:06 - 01:05:30)
Da muss man aber, glaube ich, auch schon aufpassen, dass die Galleonsfigur dann auch nicht immer nur gelobt wird, sondern eigentlich auch die Projektbeteiligten, oder? Ich meine, also wenn ich mir jetzt so ein Schiff ansehe und da vorne ist eine schöne Galleonsfigur drauf, dann sage ich, oh wow, das ist aber schön, ja? Und bei einem Projekt ist es ja dann eigentlich auch so, wow, der Projektmanager, der reißt das ja richtig raus, ja? Und die fleißigen Bienchen, die, ja, da wird nach unten getreten oder Scheiße fällt nach unten, oder? Da muss man ja schon ein bisschen aufpassen, oder?
Stephan Strack (01:05:30 - 01:05:35)
Hier, guck mal mit so einer Gaviotfigur. Die kommt natürlich als erstes am Hafen an. Die sehen auch alle.
Andy Grunwald (01:05:35 - 01:05:36)
Prima.
Stephan Strack (01:05:36 - 01:06:09)
Aber das Schiff kommt ja nur am Hafen an, wenn die ganze Zeit der Steuermann fleißig gearbeitet hat, die Segel gehisst waren, jemand sich um den Wind gekümmert hat und das auch noch alles gemacht hat. Davon hat die Gaviotfigur leider keine Ahnung. Die hängt da nur und lässt sich vorwärts treiben. Es ist halt genau der Punkt. Ich glaube, als Projektmanager muss man auch daran arbeiten, seine Engineers zu lernen und auch der Rest der Unternehmung sollte da immer mehr dazu beitragen. Also es kann halt auch nicht nur sein, dass nur der Projektmanager immer alle sagt, ich hab da alles gut gemacht. Da muss auch Feedback aus der Rest der Unternehmung kommen. Die sagen, hey, wir haben den Projektfortschritt gesehen, top gemacht, für die Klasse, dass ihr das unter eurem Team so gut gelöst habt. Da muss auch mal Feedback kommen.
Andy Grunwald (01:06:09 - 01:06:21)
Also das war richtig, richtig schönes Storytelling. Die Galleons, wir konnten da ganz in den Hafen an. Wow! Also das, also ... Den muss ich mir aufschreiben. Den muss ich mir wirklich aufschreiben.
Wolfi Gassler (01:06:21 - 01:06:43)
Wobei man natürlich schon sagen muss, ich hab jetzt Stefan nie als Galleonsfigur gesehen, weil so eine Galleonsfigur für mich, die kann nur Gold scheinen und bewegt sich nicht und hängt da nur vorne rum. Und das würde jetzt in Stefan nicht zuschreiben. Also, der war schon super aktiv und hat geleitet und Leadership gezeigt. Das ist schon noch mal was ganz anderes als nur dumm da am Schiff rumhängen vorne.
Andy Grunwald (01:06:45 - 01:07:14)
Ein anderer Mythos, und da würde ich jetzt gerne mal dich, Stefan, fragen, wie das eigentlich von der anderen Seite wahrgenommen wird, ist Folgendes. Engineers sind am Coden, am Hack, Hack, Hack, Deploy und allem Drum und Dran. Und der oder die Projektmanagerin kommt jede zwei Stunden vorbei. Wo sind wir denn? Wie ist der Stand? Und von der Software-Engineering-Perspektive nervt das so ein klitzekleines bisschen. Wie wird die ganze Sache denn von der anderen Seite wahrgenommen? Ich meine, klar, du willst den Stand haben, verstehe ich.
Stephan Strack (01:07:14 - 01:07:48)
Ist mir auch schon passiert. Und der Kontext ist dann, okay, ich hab was versprochen, das irgendwann fertig ist. War noch vier Wochen Puffer. Dann passierte was Unvorhergesehenes, der Puffer ist dagegen geschmolzen. Dann ist noch ein Bug in der Entwicklung aufgetaucht und jetzt ist es auf Messerschneider auf das Ticket fertig. Also steht sozusagen meine Integrität auf einmal auf dem Drahtseil. Und ich will wissen, ob ich Bescheid geben muss, dass ich mein Commitment nicht schaffe. Oder ob's klappt. Das macht einen super nervös. Dann ist man ... Würd man am liebsten per Programming machen, dafür sorgen, dass es klappt.
Andy Grunwald (01:07:49 - 01:07:53)
Uh, direkt über die Schulter schauen. Ah, ist ja noch schwieriger als alle zwei Stunden nachzufragen.
Stephan Strack (01:07:53 - 01:08:52)
Vielleicht ist das ja auch so ein Grund, warum die CEOs hin und wieder mal auftauchen. Aber das ist sozusagen ein Punkt, der mich dazu verleitet hat. Andere Sachen sind so Deadlines, wenn dann irgendwas fertig war. Oder du sagst, okay, wir wollen releasen, der Kunde will anfangen. Was kriegen wir denn überhaupt noch zusammen hin? Wir wollen Spitzaufklapp jetzt losgehen, wo so Sense of Urgency und Purpose gut zusammenfallen, wo das Team wirklich nach vorne geht. Aber du willst wissen, wo ist der Status? Du musst regelmäßig Status reporten können, weil viele andere Business-Entscheidungen außerhalb vom Projekt auf den Erfolg von diesem Teilprojekt waren. Dann ist es einfach wichtig, die Kommunikation nach außen aufrechterhalten zu können, aber dafür brauchst du ein permanentes Bild von innen. Und dann musst du einfach fragen. Du kommst ja sonst nicht. Und ich weiß, dass es störend ist. Und es ist halt wichtig, auch um alle anderen Teams, die davon abhängig sind, mitzugucken. Das sind dann so die Momente, wo man es versteht, man weiß, was für einen Unfug man da macht, dass es störend ist, aber es muss halt einfach sein, weil die anderen brauchen dich. Also ja, machen wir. Entweder aus persönlichen Problemen oder aber es gibt tatsächlich einen betrieblichen Grund, dass die Informationen woanders gebraucht werden.
Andy Grunwald (01:08:52 - 01:08:55)
Ich finde das schön. Zusammenfassung. Too long didn't read. Ja, machen wir. Ja, muss so.
Stephan Strack (01:08:56 - 01:09:01)
Ja, ich glaube, das lässt sich so nicht ausradieren.
Wolfi Gassler (01:09:02 - 01:09:25)
So, jetzt haben wir ja schon sehr viel eigentlich aus der Praxis besprochen. Und wir haben ja auch immer wieder so angeschnitten, dass das Agile Manifesto, was da so im Rahmen steht, eigentlich diese Dinge auch beschreibt. Und Andi hat ja auch brav im Hintergrund schon gegoogelt nach dem Agilen Manifesto. Andi, du kannst sicher aus dem Agilen Manifesto die vier Punkte mal vorlesen, oder kannst du die auswendig?
Andy Grunwald (01:09:25 - 01:09:34)
Ach, um Gottes Willen. Ich hab's natürlich damals, als es rauskam, Oder als die Sau durchs Dorf getrieben wurde, als Scrum der neue heiße Scheiß war.
Wolfi Gassler (01:09:34 - 01:09:36)
Oder XP war das ja damals.
Andy Grunwald (01:09:36 - 01:09:41)
Ja, Extreme Programming, Kamban und was es da nicht noch alles gab. Nee, aber fangen wir mal an. Ganz kurz.
Wolfi Gassler (01:09:41 - 01:09:43)
Bist du überhaupt zu alt schon?
Andy Grunwald (01:09:43 - 01:09:44)
Wann kam das raus?
Wolfi Gassler (01:09:44 - 01:09:45)
Keine Ahnung, Stefan, wann kam das raus?
Stephan Strack (01:09:46 - 01:09:47)
Anfang der 90er.
Andy Grunwald (01:09:47 - 01:10:03)
Ja, Anfang der 90er war ich drei. Ja, passt. Fangen wir an. Erstens, Individuen, aka Menschen und Interaktionen sind mehr wert als Prozesse und Werkzeuge. Nummer zwei, funktionierende Software mehr als umfassende Dokumentation.
Wolfi Gassler (01:10:03 - 01:10:04)
Merkst du die, Andi?
Andy Grunwald (01:10:04 - 01:10:15)
Nummer drei, Zusammenarbeit mit dem Kunden ist mehr wert als die Vertragsverhandlung. Und Nummer vier, reagieren auf Veränderungen ist mehr wert als das Befolgen eines Plans.
Wolfi Gassler (01:10:15 - 01:10:26)
Stefan, haben wir die Punkte alle besprochen oder findest du die alle in der Praxis wieder oder sind das auch Guidelines, die du grundsätzlich anwendest, wenn du so in Projekten unterwegs bist?
Stephan Strack (01:10:26 - 01:11:06)
Ja, das sind immer wieder relevante Themen. Also für die Individuen und Interaktionen, viele der Prozesse und Werkzeuge, die ich habe, sind tatsächlich im Projektmanagement dafür gebaut, um die Interaktion mit den Individuen effektiver und besser zu gestalten, dass alle engagiert am Projekt arbeiten können. Also es ist tatsächlich so, dass ich Prozesse und die Werkzeuge brauche, um mit den Individuen voranzukommen. Funktionierende Software über umfassende Dokumentation, wir haben vorhin kurz darüber gesprochen, aber der Projekterfolg hängt maßgeblich davon ab, dass die Lösung implementiert ist. Auf der anderen Seite wissen wir auch, dass wir die Dokumentation brauchen, für Stakeholder, für das Team selber. Die Projektinitialisierung muss klar gut strukturiert und dokumentiert sein. Ein gewisser Teil muss einfach da sein, auch um schwierige Fälle im Nachhinein zu schauen.
Wolfi Gassler (01:11:06 - 01:11:15)
Da geht es ja auch eigentlich um die Priorisierung, oder? Was ist wichtiger und wo kann ich im Falle Abstriche machen oder wo soll ich priorisieren?
Stephan Strack (01:11:15 - 01:13:05)
Genau, die Idee von dem agilen Manifest zu sagen, alles ist ja schon irgendwie wichtig, aber wenn du dich entscheiden musst, Da heißt der Fokus hinzulegen. Auch dann die Kollaboration mit der Unternehmung oder mit dem Kunden rauszufinden, was denn jetzt tatsächlich getan werden muss, ist immer besser als zu sagen, aber wir haben vor zwei Monaten das entschieden, daran halten wir uns jetzt. Das funktioniert nicht. Also das muss schon flexibel sein, weil wir ja eben in einer neuen Domäne arbeiten, in der wir erst im Nachhinein wissen, ob wir das Richtige tun. Und dann kann halt schon mal rauskommen, irgendwie machen wir halt das Falsche, wir sollten den Kurs ändern. Und dann muss man dazu auch bereit sein. Und dann daraus folgt quasi auch der letzte Punkt. Veränderungen werden kommen. Und darauf muss man einfach per se eingestellt sein. Dass der Plan einem hilft, in die richtige Richtung loszumarschieren, von der man heute glaubt, da komm ich an. Aber dann kommen die Veränderungen. Da ist gar kein Entkommen. Und dass man sich einfach darauf einstellt, mit denen gut umzugehen, ist wesentlich wertvoller, als zu sagen, aber wir hatten doch den Plan. Der hält meistens nicht. Da vielleicht auch noch ein kleiner Bereich, wenn man so die Planungstheorie guckt, steht ganz oben, Planen ist keine präzise Wissenschaft. Das funktioniert eigentlich gar nicht. Ja, also für mich ist das tatsächlich sehr relevant. Ich habe auch zwei agile Prinzipien, die immer wieder stark mit mir resonieren. Das ist der einzige tatsächliche Fortschritt, die Software, die in Produktion ist. Und dann das andere, was ich sehr, sehr essentiell befinde, ist die Idee von Simplicity. Also die Art, die nicht getanen, die Kunst, die nicht getane Arbeit zu maximieren, ist essentiell. Also zu sagen, okay, was ist denn das, was ich genau machen muss und was davon brauche ich eigentlich alles gerne? Da ist im Projektmanagement viel Zeit zu gewinnen. Natürlich auch der eine oder andere Konflikt mit den Engineers, ob man das jetzt nun braucht oder nicht, oder ob man das jetzt nur für diesen Fall auch designen muss oder nicht. Aber da kann man, glaube ich, viel Gutes tun, wenn man all die Fälle aus dem Projekt abschneidet, die man gar nicht braucht, sondern wenn man sie auswesentlich hat.
Wolfi Gassler (01:13:06 - 01:13:52)
Vielen lieben Dank, Stefan, für sehr viel, nicht nur für dieses Interview und für diese Podcast-Episode, sondern auch das Vorführen, das agil auch bei großen Projekten funktionieren kann, wo wirklich direkt hunderte Leute involviert sind und im weiteren Umfeld tausende Leute involviert sind. dass es wirklich funktioniert und auch gut was auf die Straße bringt. Vielen Dank auch für die Erfahrung. Ich habe damals extrem viel gelernt bei diesem Projekt, auch in Bezug auf Architektur, wie schwierig es ist, etwas technisch umzusetzen und wenn es nur eine ID ist, die leider im ganzen Unternehmen verwendet wird, ich glaube, da hassen mich heute noch viele für diese ID-Änderung. Vielen lieben Dank. Danke für die Episode. Und wir verlinken natürlich auch ein paar Ressourcen und Informationen zu dem ganzen Thema in unseren Show-Notes.
Stephan Strack (01:13:52 - 01:13:57)
Danke, Wolfgang. Auch, dass du im Projekt so gut beigetragen hast als motivierter Mitarbeiter. Andi auch.
Andy Grunwald (01:13:57 - 01:14:02)
Jetzt hört mal auf, ihr euch gegenseitig auf die Schulter zu klopfen. Ja, du warst super.
Stephan Strack (01:14:02 - 01:14:04)
Ja, du warst auch super. Ja?
Andy Grunwald (01:14:04 - 01:14:06)
Meine Güte.
Stephan Strack (01:14:06 - 01:14:09)
Wart mir auch.
Andy Grunwald (01:14:09 - 01:14:19)
Die einzige Frage, die wirklich relevant ist, um zu sagen, war das Projekt wirklich super, ist Folgendes. Wenn ihr dasselbe Projekt noch mal machen würdet, würdet ihr es genauso tun wie damals?
Stephan Strack (01:14:19 - 01:14:20)
Nein, natürlich nicht.
Andy Grunwald (01:14:20 - 01:14:21)
Danke schön.
Stephan Strack (01:14:21 - 01:14:21)
Natürlich nicht.
Andy Grunwald (01:14:22 - 01:14:25)
Alles geklärt. War schön, mit euch zu sprechen. Bis zur nächsten Woche. Tschüss.
Wolfi Gassler (01:14:26 - 01:14:33)
Also, so reflektiert muss man doch sein, Andi. Also, wenn man immer alles gleich machen würde, dann wäre das ja ein großes Problem. Würde man ja nie reflektieren.
Andy Grunwald (01:14:33 - 01:14:53)
Vielen Dank, Stefan, für deine Zeit. Vielen Dank für das Teilen deiner Weisheiten und auch deiner Berufserfahrung. Und für alle Leute, die natürlich noch ein bisschen mehr zum Thema Projektmanagement wissen wollen, in den Show Notes findet ihr natürlich die Kontaktdaten von Stefan. Das bedeutet, wenn ihr dem mal eine Linking-Message droppt oder eine E-Mail, der wird bestimmt auch antworten.
Stephan Strack (01:14:53 - 01:14:59)
Ja, danke. Danke fürs Dabeisein. Und den Hörern, ich hoffe, ihr habt viel Spaß gehabt beim Hören. Bye bye. Ciao. Ciao.