"Start less, finish more": Die agile Philosophie für Projektmanagement

Intro: Digital kompakt. Heute aus dem Bereich digitales Unternehmertum mit deinem Moderator Joel Kaczmarek. Los geht's.

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek, ich bin der Geschäftsführer von Digitalkompakt und heute habe ich den lieben Patrick Kahl zu Besuch. Patrick ist Chapter Lead Agile Coaches bei Signal Iduna und wer uns ein bisschen kennt, wir haben fairerweise lange keine Folge mehr, aber mit den Kolleginnen und Kollegen von Signal Iduna machen wir so eine Transform-Reihe. Das heißt, wir versuchen immer nachzuzeichnen, wie das Unternehmen sich transformiert und was jede einzelne Unit tut, damit das erfolgreich gelingt. Und Patrick, wie der Name schon sagt, hat einen gewissen Background, genau gesagt, bin ich mal gespannt, den gleich wieder kennenzulernen, im Bereich Kanban, Agile und Co. Und unser heutiges Thema ist Start Less, Finish More, was ich ein total geiles Thema finde, weil einerseits kommt das aus diesem ganzen Kanban Framework Kontext, also agiles Arbeiten, aber andererseits ist es auch ein Mindset, den man sich verschreiben kann, nämlich zu sagen, ich möchte gerne wirksamer werden und ich möchte gerne wirklich zusammenarbeiten und wenn ich mehr Output generiere, sind alle motivierter. Das heißt, aus der heutigen Folge nimmst du also diesen Satz mit, Start Less, Finish More und wir werden über verschiedene Dinge reden, über die Definition dessen, wie man eigentlich Nein sagt, wozu das Ganze gut ist, was braucht es eigentlich, um das zu können, plus noch einiges anderes mehr, zum Beispiel auch Ziele und wie man das Ganze misst. Also ich glaube, heute wird es richtig spannend. Von daher, lieber Patrick, schön, dass du da bist. Moin Moin.

Patrick Kahl: Moin Joel, schön. Danke für die Einladung.

Joel Kaczmarek: Jetzt muss ich dich mal ganz kurz fragen, wenn ich mich mit dir unterhalte, kann ich das schon mal vorne wegnehmen. Auf dem Zettel, den ich von dir bekommen habe, stehen eine Million Abkürzungen drauf. D-O-D-A-C-C-D-O-R-W-I-P-L-E-S-S-A-S-F-E-S-O-S und so weiter und so fort. Und du bist ein wandelndes Lexikon für solche Dinge. Was machst du eigentlich? Wie bist du dazu gekommen, das zu tun, was du jetzt tust? und was tust du in deiner aktuellen Rolle?

Patrick Kahl: Im Mexikon auswendig lernen bzw. ein Buch aufschreiben. Das hat sich über zehn Jahre lang so etabliert, die Begriffe aufzubauen, in verschiedenen Kontexten zu üben. Ich bin im Herzen Agilist, so stelle ich mich meist vor und seit mehreren Jahren von der Rolle Scrum Master über Agile Coach geworden. und ja, da haben sich die Begriffe aufgebaut. In der Nutzung der verschiedenen Frameworks, die es gibt, also Rahmenwerke, die genutzt werden rund um Agilität, also um Agilität spürbar zu machen. Und da kommen genau diese Begriffe vor, DOD, Definition of Done oder DOR, Definition of Ready, sind alles kleine Hilfsmittel, um, und da können wir gleich mal draufschauen, um das Thema Startless, finde ich, umzugehen.

Joel Kaczmarek: Wir müssen uns schon mal entschuldigen. Es gibt manchmal Menschen, die finden das doof. Ich zähle nicht dazu, aber es gibt sie und ich kann es auch verstehen und tolerieren, die finden englische Begriffe nicht so toll. Das wird in der heutigen Folge ganz brutal werden. Also Outcome, Output, Kanban, Utilization Traps, all solche Dinge, Slicing, User Stories, sowas kommt heute alles vor. Es ist einfach der Art der Arbeit geschuldet, in welchem Kontext das entsteht. Wir versuchen das immer ein bisschen auf Deutsch reinzunehmen, aber da soll man sich drauf einstellen. Also zum Glück habe ich nicht so einen Phrasenschwein. Schau mal vor, 2 Euro für jeden englischen Begriff. Oh Gott, dann wären wir heute Abend. Gut, fangen wir mal aber an. Die Definition von Start, Less, Finish, More. Klingt ja erstmal simpel. Also ich fange weniger an und ich schließe mehr ab. So nach dem Motto verzettel dich nicht. Aber vielleicht kannst du ja mal Bigger Picture geben, was damit genau gemeint ist und sich verbindet.

Patrick Kahl: Ich finde das spannend, dass du das sagst. Klingt simpel. Also in der Tat ist es eigentlich eine Kontroverse. Also man beginnt weniger und hat am Ende ein höheres Ergebnis. Also Outcome, was wir gerade gesagt haben. Eigentlich ist das für jedes Unternehmen oder für die Etat, dass ich sage, okay, wie kommt das zustande? Wie kann das sein? Und wir hatten es eben schon angeteasert, ist so ein bisschen ein Mindset, eine Haltung, eine Idee, eine Ausrichtung, die man hat. Okay, ich fokussiere mich auf gewisse Dinge mit der Hoffnung, mit dem Ansatz, mit der Hypothese, dass ich am Ende mehr rausbekomme. Wie? Indem ich mich fokussiere, indem ich Nein sage, indem ich bestimmte Mittel und Methoden nutze, um genau das zu ermöglichen. Und da schwingt so vieles mit von der Effizienz, also auch von den Kosten-Nutzen-Verhältnissen, aber auch für die Mitarbeitermotivation. Sagen, hey, ich bekomme Dinge fertig. Also ich beginne etwas und kann das abschließen am Ende. Das hat einen extrem hohen motivierenden Faktor. Und das ist so ein bisschen die Idee in der Startless Finish More, eher als Phrase, als Aussage genutzt. und dann schauen, hey, wie kann ich das umsetzen? Und dann in verschiedenen Kontexten schauen, was brauche ich dazu, um genau das zu ermöglichen?

Joel Kaczmarek: Ich glaube, jeder kennt das auch im kleinen Rahmen. Wenn man Freitag aus dem Büro geht und hat irgendwie eine Sache nicht fertig gemacht, das nervt einen voll. Versus diese Befriedigung, wenn man einen Haken hinter hat und, also alleine abhaken ist ja für viele Menschen schon sowas. Und jetzt lassen Sie mal noch zwei weitere Begriffe definieren. Die sind eigentlich, wenn man sie hört, relativ simpel. Aber vielleicht im Kontext hier empfiehlt es sich da nochmal ein, zwei Sätze zu sagen. Und zwar das eine ist Wirksamkeit, also wirksamer arbeiten. Was meint sich damit? Und das andere ist Zusammenarbeit, was ja auch manchmal abstrakter gemeint sein kann, als es vielleicht auf den ersten Blick scheint.

Patrick Kahl: Wirksamkeit ist eines der großen Wörter auch im Kontext der Agilität oder Agile Coaches. Wie messe ich meine Wirksamkeit? Wann bin ich wirksam? Also wann kann ich sehen, dass Dinge, die ich ausprobiere, die ich. anderen Leuten beibringen, als Trainer, als Berater, als Coach, dass er sagt, okay, das hat eine Wirkung, eine explizite Wirkung auf das, was ich da tue. Und vor allem in komplexen Systemen ist das sehr schwierig. Wie macht man das? beispielsweise, indem man Kunden befragt? Also ich mache etwas und frage natürlich die Betroffenen und Beteiligten, hey, hat das einen positiven Effekt gehabt? Ich habe eine Baseline, eine Hypothese, sage, mit was starte ich? Also was ist meine Ausgangsbasis und hat sich dadurch was verändert? Auch da kann man Wirksamkeit messen. Aber es ist aber nicht trivial, gerade das Thema Wirksamkeit so greifbar zu machen. Ein guter Versuch ist immer, mit Daten zu arbeiten oder aktives Feedback anzuholen. Hat das in der Veränderung gebracht? Das ist zum einen das Thema Wirksamkeit und zum anderen Zusammenarbeit, du hast es schon gesagt, ist auch nicht trivial, aber darum geht es meist, da wir bei der Signal Iduna ist es ähnlich, in großen Systemen unterwegs sind mit mehreren tausend Leuten, dann arbeitet man meist nicht alleine, sondern in Teams. Teams stehen auf einer bestimmten Größe oder haben eine bestimmte Größe, eine bestimmte Anzahl und da geht es darum, eine Zusammenarbeit herzustellen. In der Kommunikation, in der Art und Weise und deswegen ist es genauso wichtig, darauf zu schauen, wie kann ich diese Zusammenarbeit wirksamer machen? Was gibt es da für Möglichkeiten? Und da kommen wir gleich nochmal rein und es schwingt alles mit, zu sagen, hey, Wirksamkeit, wie kann ich wirksamer zusammenarbeiten und wie kann ich wenig machen und trotzdem ein hohes Ergebnis erzielen?

Joel Kaczmarek: Gut, dann lass uns mal zuspitzen. Start less, finish more. Wozu? What's the story behind it? Also was sind so die Hypothesen, die sich damit auch verbinden?

Patrick Kahl: Das ist die Wurzufrage, eine bestimmte Kernfrage. Wozu machen wir Themen? Und das, du hast gerade gesagt, ist meistens immer eine Annahme und eine Hypothese. Das heißt, wenn ich wir sage, dann bin ich im Kontext der Agilität, Agile Coaches, Scrum Master, gehen mit gewissen Hypothesen, Ansätzen rein. Wozu machen wir Dinge? Und ein Thema, das hatte ich schon gesagt, ist das Thema Mitarbeitermotivation. Mitarbeiter, die etwas erledigen, du hast es gerade schon benannt, der Freitagseffekt oder Urlaubseffekt, der Urlaub beginnt und ich habe einen schönen Flow und ich gebe alles rein und ich kann Dinge abschließen und gehe mit einem guten Abschluss ins Wochenende rein oder in den Urlaub, das fühlt sich gut an, das motiviert. Diese Motivation trägt sich natürlich weiter in der Außendarstellung, im Team selber und von daher hat es einen extrem hohen motivierenden Faktor, Dinge abzuschließen. Deswegen ist die Hypothese, okay, wenn ich mit dem Ansatz reingehe, weniger zu machen und Dinge abzuschließen, am Ende was zu bekommen, auch eine gesteigerte Qualität, eine bessere Umsetzung von Kosten, dann hat das einfach einen positiven Effekt, gesamtwirtschaftliches. Das ist so ein bisschen das Spektrum. Und das ist so ein bisschen schwierig. Das ist meistens nicht so trivial greifbar. Oftmals verzögern sich die Themen so ein bisschen. Man kann nicht immer gleich einen Effekt sehen, wenn man zum Beispiel Dinge visualisiert. Und wenn man sagt, okay, ich mache jetzt weniger. Ich reduziere meinen Input. Also das, was ich reingebe. Der Effekt ist meist immer sehr spät. Aber die Hypothese ist, dass ich eine höhere Motivation der Mitarbeiter habe. Was natürlich auf Fluktuation beispielsweise sich auswirkt. Das wirkt sich eventuell auch auf Krankheitszustände aus. Der Gesundheitszustand von Menschen. Aber natürlich, und das kommt auch mit, bei jedem Wirtschaftsunternehmen zu schauen Was hat das für eine Auswirkung auf Durchlaufzeiten, Prozessgeschwindigkeiten? Kann ich sogenannten Waste reduzieren? Also zu schauen, was passiert zwischen Schritt A und B? Dauert das gefühlt drei, vier, fünf Tage? Oder kann ich den Prozess so optimieren, dass es eventuell nur noch zehn Minuten dauert? Können wir Entscheidungsprozesse verbessern? All das hat ja dann wieder einen positiven wirtschaftlichen Effekt auf das Unternehmen selber und genauso wieder einen Effekt auf die Menschen. Und das sind so die Grundhypothesen, mit denen man angesagt, okay, ergibt Sinn. vielleicht, wenn das die Hypothesen sind, cool, dann lass uns doch mal schauen, wie wir Start, Last, Finish, More umsetzen können.

Joel Kaczmarek: Okay, verstanden. Und mal blöd gefragt, heißt es einfach nur, ich muss mich so nach dem Motto hokus pokus, keep the focus, reduzieren? Also ist es nur das, so nach dem Motto, fang einfach weniger an und wähle das aus, was wichtig ist oder verbindet sich noch mehr damit?

Patrick Kahl: Meine erste Frage einfach, Wäre ja. Das wäre so der erste Schritt. Zu Beginn sagen, hey, wie kann ich denn sich darüber klar werden, ah, was sind denn die Themen, die ich machen muss? Also was will ich machen? Was ist das Produkt, das ich dem Kunden zur Verfügung stellen möchte? Darüber Klarheit zu bekommen, also eine Ausrichtung zu schaffen über das Thema. Das beginnt mit einer Vision, mit einer Zielausrichtung. Zu verstehen, in welche Richtung wollen wir denn arbeiten? Gemeinschaftlich auch zu verstehen, arbeiten wir an den gleichen Themen? Also sich erstmal Klarheit zu schaffen und mit dieser Klarheit, der vermeintlichen Klarheit, schauen, hey, was sind die Themen, die darauf einzahlen? Und dann sind wir genau, was du sagst, bei so Themen, da ist immer ein neuer Begriff, Backlog Management, also zu verstehen, was sind die Aufgaben, die ich habe, welche zahlen direkt darauf ein, was muss ich machen, welchen Nutzen haben die, welche sind eventuell sogar jetzt notwendig zu machen, weil der Nutzen, der in Zukunft stattfindet, vielleicht reduziert wird. Und genau das ist genau die Art des Spielens, des Verstehens und die Interaktion auch mit dem Team, mit Stakeholdern, die davon betroffen sind, zu verstehen, was mache ich jetzt und im Zweifel nicht alles gleichzeitig anzugehen.

Joel Kaczmarek: Bevor wir jetzt mal in konkrete Dinge schon eintauchen, wie zum Beispiel das Nein sagen, das Fokussieren, was braucht es denn, so in a nutshell, also so auf der obersten Ebene zusammengefasst, was brauche ich, wenn ich diesem Framework folgen möchte?

Patrick Kahl: Die Arbeit mit Menschen und der Blick auch auf Prozesse, das braucht im Zweifel, gerade bei Veränderungsthemen und auch bei dem Thema Mindset oder Haltung, das haben wir ja immer schon gesagt, wenn wir sagen, hey, wir haben Wirksamkeit, wir haben Zusammenarbeit, wir haben eine Grundidee von diesem Satz, was sowohl die Haltung als auch die Umsetzung angeht, dann braucht es die Arbeit mit dem Prozess, mit der Optimierung des Prozesses, aber auch die Arbeit mit den Menschen. Was heißt das? Es braucht beispielsweise das Verständnis darüber, wie Prozesse stattfinden. Wie finden Entscheidungsprozesse statt? Wie lange dauert das? Das transparent zu machen, zu visualisieren, das kann eine Methode oder ein Satz sein. Also Klarheit zu bekommen, wie ist denn meine aktuelle Systemlandschaft aufgebaut? Das ist ein Aspekt. Und ein anderer Punkt ist die Arbeit mit verschiedenen Menschen. Und je nach Kontext ist es die Arbeit mit Führungskräften beispielsweise, die Arbeit mit Product Ownern. Also je nachdem, wer den Begriff wieder Input, also etwas in ein System eingibt und auch verantwortlich dafür ist, dass gewisse Dinge gestartet werden sollen, auch mit den Leuten gibt es zu interagieren, mit den Teams zu interagieren, dass Entscheidungsthemen, was ziehe ich mir jetzt als Thema heran, bei den Teams liegt. Also ist es sowohl die Prozessthematik, als auch mit Menschen zu arbeiten, dass wir eine andere Art der Interaktion haben, eine andere Art der Zusammenarbeit.

Joel Kaczmarek: Cool, dann lass uns mal in Medias Res gehen. Also was ja hinter steckt ist, Nein sagen. Ich habe immer mal gelernt hier, so ein Warren Buffett Zitat, wenn man erfolgreich sein will, muss man öfter Nein als Ja sagen. oder zumindest sagen erfolgreiche Menschen oft Nein. Sprich, es geht um Fokussierung. Wie machst du das? Was ist dein Werkzeug dafür?

Patrick Kahl: Es gibt ein schönes Buch, das gerade einmerkt, seit 50 Arten Nein zu sagen. Das ist ein ganz gutes Buch, was einen Hinweis gibt, um in verschiedenen Kontexten, also nicht einfach aufs gerade Wohl Nein zu sagen, sondern, und das ist das Schöne, was Warren Buffett auch sagt, zu sagen, hey, wie kann ich mein Nein, also wie kann ich das Nein sagen so oft wiederholen, sodass das Ja, was ich gebe, Kraft hat, Intuition hat, also eine gewisse Stärke hat und somit eine gewisse Nachhaltigkeit. Nein sagen, um zu verstehen, hey, wen habe ich mir gegenüber, Stay-Coder-Management zu beschreiben. Nicht jeder Stakeholder, sei es nun Financier oder Venture Capital oder Kunde oder Informierer, ist gleich zu behandeln. Also es gibt unterschiedliche Möglichkeiten, Nein zu sagen. Verstehen, was ist das Produkt, was ich anbieten möchte? Welche Features oder welche Funktionalitäten möchte ich jetzt bereitstellen oder in Zukunft? Welche Funktionalitäten funktionieren vielleicht jetzt noch nicht, weil ich Abhängigkeiten habe zu anderen Teams, weil technische Voraussetzungen nicht geschaffen sind? Also auch da Klarheit zu verschaffen und auf der Basis Nein zu sagen. Ansonsten kann man auch neben dem Verwahlenein sagen, man hat einen Plan, man hat eine Roadmap. Bin ich in der Rolle als Product Owner, Verständnis darüber zu geben, hey, was sind denn die nächsten Funktionalitäten, die ich anbiete? Also auch das ist eine Möglichkeit, Nein zu sagen oder sachlich über einen Backlog. Wir hatten das eben. Backlog Management, ich habe priorisierte Aufgaben, Aktivitäten in diesem Backlog. Das wird in manchen Kontexten auch User Stories genannt. Sagen, hey, auch da ist ja eine Reihenfolge drin, eine Priorisierung und darüber sagt man auch Nein. Und das Schöne ist, weil Nein sagen ist immer, das gebe ich gerne mit, es ist ein Noch-Nicht und kein finales Nein, sondern es ist einfach nur das Thema, hey, es gibt andere Themen wichtiger oder dringlicher aus bestimmten Gründen und das gibt es zu erfahren und es ist ein Noch-Nicht für den Moment, aber genau solche Möglichkeiten kann man Nein sagen.

Joel Kaczmarek: Ich finde ja auch, dass in solchen Sprachsachen feine Motivation drin steckt. Also ich habe auch mal gelesen, dass es einen schönen Unterschied macht, wenn man sagt, ich kann das aber gar nicht versus ich kann das noch nicht. Ja, so finde ich deswegen einen wichtigen Punkt. Und jetzt waren wir natürlich schon in der Umsetzung. Also wie, ablehnen würde ich gar nicht mal sagen, aber sagen wir mal, wie vertage ich Dinge oder wie sortiere ich Dinge auf der verbalen Ebene und Umgang. Was dem ja unterliegt, ist ja aber das Thema Priorisierung. So, wie macht man mit deiner Methodik Prioritätensetzung? Wie funktioniert das? Welche Bausteine gibt es da?

Patrick Kahl: Mit meiner Methodik, da könnte man jetzt aus den verschiedenen Frameworks so ein bisschen rausziehen. Kanban, LESS, beispielsweise Large Enterprise Scale, Scrum, also es gibt verschiedene Ansätze. Also Scrum, ganz easy würde ich sagen, aber schon fast so nachvollziehbar ist Backlog Management, Priorisieren, Backlog Refinement, Planning Poker, was man als Ansatz nimmt, um zu verstehen, hey, wie schwer sind Aufgaben, wie schwer sind Aktivitäten, wie viel Aufwand bedeutet das im Verhältnis zum Nutzen? Ganz einfache Geschichte. Einfach insofern, weil das eine ganz mathematische, einfache Zahlrechnung ist, aber natürlich dann, und da wird es ein bisschen komplexer, In Abhängigkeit mit anderen Teams oder Stakeholdern. Dann muss man abwägen, was ist jetzt notwendig und was nicht. Aber Backlog-Management im Scrum, Planning-Poker, Sprint-Bunning und Backlog-Refinement, das sind so die Begrifflichkeiten, die da reinfließen.

Joel Kaczmarek: Da musst du mal unser Publikum noch weiter abholen. Also Backlog haben vielleicht viele schon gehört. Also Dinge, die ich noch machen möchte. Und lass uns mal die anderen aber auch noch weiter durchdeklinieren.

Patrick Kahl: Genau, Dinge, die ich noch machen möchte in einer gewissen Reihenfolge. Das ist die Grundidee von einem Backlog. Alles, was oben steht, ist am wichtigsten und dringendsten. Alles, was weiter folgt, kommt zeitlich auch später. Ich hatte Begriffe genannt wie Sprintplanning. Was ist das? Das ist ein Event, ein Zeitpunkt innerhalb eines Zeitraumes von einem Drei-Wochen-Sprint beispielsweise, wo das Team zusammenkommt und für den nächsten Zyklus, also für die nächste Arbeit plant. Was will ich jetzt in meinen Backlog packen? sondern ein Sprint-Backlog. Ich hatte Backlog-Refinement genannt. Das ist praktisch ein vorgelagertes Event vor dem Sprint-Planning. Zu sagen, okay, wie sieht denn meine Gesamtausrichtung aus? Ich hatte vorhin den Begriff der Roadmap genannt. An sich ist ein Backlog auch eine Art Visualisierung einer Roadmap, eines Plans. Was plane ich in Zukunft? Also in Backlog-Refinement wird genau das durchgeführt. Da wird das Gesamt-Backlog, der Gesamtplan angeschaut und geschaut, in welcher Reihenfolge finden die Dinge statt. Themen, die vielleicht etwas älter sind, sind jedoch notwendig. Interaktion mit Kunden zu verstehen, mit Stakeholdern, das ist Backlog-Refinement. Du hast was mit Poker gerade noch gesagt. Planning Poker ist eine Möglichkeit, dem Team, also wir reden da fast von drei bis sieben, acht, neun Leuten in der Größe, unterschiedlicher Funktionalitäten, unterschiedlicher Rollen, also von einem Entwickler, von einem Tester, also meist sogenannte Cross-Funktionality-Teams, die imstande sind, Themen komplett innerhalb dieses Teams zu erledigen. eine Möglichkeit anzubieten, in den Austausch zu gehen. Was passiert, wenn wir jetzt zum Beispiel eine Tätigkeit, eine Aktivität anschauen würden, Joel, dann würdest du sagen, naja, das Haus streichen, das ist irgendwie wenig komplex. Ich habe das schon 50 Mal gemacht. Ich habe da eine gewisse Technik, ich habe da gewisse Tools. Für mich aber selbst, wow, ich habe das noch nie gemacht oder ein, zwei Mal. Keine Ahnung, für mich ist das super komplex. Ich habe keine Ahnung, wie man da rangehen soll. Planning Poker ermöglicht genau diese Konversation, diesen Austausch. Hey, was hast du an Erfahrung gemacht? Was bringst du mit, dass es für dich vielleicht weniger komplex ist im Vergleich zu mir? Und da gibt es eine schöne Planning Poker Karten, wo man so ein bisschen mit Zahlen arbeiten kann, um genau diese Komplexität zu verstehen und ins Gespräch zu kommen.

Joel Kaczmarek: weil was ich jetzt im Begriff hatte, ich zu fragen, beim Thema Backlog-Management, wenn ich jetzt nur hingehe und sage, okay, welchen Business-Impact, welche Relevanz hat das versus was sind die Kosten der Aufwand dazu? Wenn ich dann jetzt, sage ich mal, abarbeite, das, was nicht aufwendig ist, dann komme ich ja auch irgendwie nie zu den großen Wetten. Das heißt, in der Regel ist es ja oft so, die schwierigsten Sachen oder die wertvollsten Sachen machen wahrscheinlich auch den meisten Aufwand. Und dafür muss man dann aber viel nach hinten priorisieren. Nach welchem Vorgehen mischt denn sozusagen dieses Framework ab, was ich in welcher Reihenfolge tun sollte, mit welchem Impact, damit ich genau diesen Effekt nicht habe, dass ich entweder nur Kleinkram mache alles sich so ein bisschen verstopft.

Patrick Kahl: Also das Framework an sich gibt darauf keine Antwort, aber da gibt es andere Ansätze, ähnlich wie Start, Last, Finish, More. Da gibt es andere Prinzipien, die genau sowas vermeiden wollen. Ein Thema, neuer englischer Begriff, Frontloading. Kommt aus dem Softwarebereich, Softwareentwicklungsbereich, sagen, okay, wenn ich ein großes Thema habe, was ein gewisses Risiko hat, eine gewisse Unbekannte, dann werde ich das nicht im Zeitpunkt nach hinten verschieben, sondern eher nach vorne ziehen. Großes Risiko, ich versuche es jetzt anzugeben, damit die Zeit, die ich habe, um dieses Risiko zu lösen oder das Problem zu lösen, noch vorhanden ist. Also zum Beispiel Frontloading wäre ein Ansatz, um solche Großen Themen, die vielleicht eine hohe Komplexität haben und Komplexität entsteht meist aufgrund von Unerfahrenheit, technischen Voraussetzungen, die nicht gegeben sind, versuche ich dann durch so einen Ansatz, durch ein bewusstes und das ist so ein Thema von einem Product Owner bewusst nach vorne zu ziehen, damit ich das Risiko nicht nach hinten verlage, weil da ist die Wahrscheinlichkeit hoch, dass ich das Risiko nicht mehr halten und nicht mehr angehen kann. Also das wäre zum Beispiel ein Ansatz, Frontloading.

Joel Kaczmarek: Und jetzt hast du ja gesagt, Backlog-Management ist nur ein Framework von mehreren. Was für weitere gibt es denn noch, wenn ich Prioritäten-Management betreiben will?

Patrick Kahl: Ein etwas größeres, und das ist eher auf einem skalierten Ansatz, also SAFE, Scaled Agile Framework. Framework ist ein Ansatz mit der Idee, dass ein Gesamtunternehmen dem Thema Agilität näher kommen kann. SAFE ist ein sehr umfangreiches Framework, ist meist wie mehrere Teams gedacht für große Unternehmen bis hin zum Portfolio-Management. Also hat verschiedene Sichten. Ich würde jetzt zu weit führen. Was aber Safe mitbringt, das ist ganz spannend, ist das Thema Cost of Delay. Also das Verstehen von Kosten, die durch Verzögerung entstehen. Also was heißt es, wenn ich Dinge verzögere? Wie verhalten sich die Kosten dazu? Und ein anderer Ansatz, ein schöner weiterer englischer Begriff. Vieles kommt aus dem englischen Bereich. Weight is shortest job first. Zu verstehen, das ist genau das, was du gerade gesagt hast.

Joel Kaczmarek: Weight ist shortest, also den schwersten, Weight im Sinne von Gewicht, die wichtigsten, kurzesten Aufgabe zuerst.

Patrick Kahl: Genau. Was heißt das eigentlich? Man setzt im Verhältnis die Opportunitätskosten, also die Möglichkeiten, die mit diesem Produkt entstehen, der Möglichkeit oder dem Risiko, was einhergeht. Also ich habe eine Marktopportunität. Was passiert, wenn ich das jetzt ausliefere? Ja, das ist in Zukunft. Risikoaversion, also gibt es gewisse technische Risiken, die damit verbunden sind. versus der Jobgröße. Also wie umfangreich ist dieses Thema? Und genau aus diesem Mehrklang versucht man herauszufinden, wann Themen wenig auffällig sind im Verhältnis zu ihrem Nutzen und der in Zukunft entstehenden Marktreduzierung oder Marktnutzreduzierung. Also ich gebe dir ein Beispiel. Tesla, Hat beispielsweise überlegt, beziehungsweise es gibt ein Markteintrittsdatum 2015. Alles, was darüber hinausgeht, beispielsweise reduziert den Nutzen an sich, weil dann vielleicht mehrere Wettbewerber in den Markt steigen. Und das ist so ein bisschen die Idee dahinter, wait a shortest job first.

Joel Kaczmarek: Okay, also in deiner Beispiellogik jetzt zum Beispiel, es wird gerade eine neue Batterietechnologie entwickelt und ich kann voraussehen, wenn ich jetzt irgendwie in diesem und jenem Jahr mein Fahrzeug nicht auf die Straße kriege, dann werden Wettbewerber das Gleiche für den halben Preis machen und mein Competitive Edge ist der

Patrick Kahl: Nutzer. Exakt, ja. Opportunitätskosten, ja, ja.

Joel Kaczmarek: Nochmal ganz kurz zu SAFE. Scaled Agile Framework. Wofür steht das E?

Patrick Kahl: Das Framework, das E.

Joel Kaczmarek: Wo ist denn der Unterschied zwischen beiden? Also das eine ist die Cost of Delay und das andere ist, ich habe eine Opportunität und wiege diese ab gegenüber den Kosten und sage ich mal meiner Risikoaversion. Was ist der Unterschied?

Patrick Kahl: Du könntest auch nur Cost-of-Delay betrachten unter dem Aufwand dahinter. Also du könntest nur, was passiert, wenn ich das Thema oder wenn ich eine gewisse Funktionalität in die Zukunft verschiebe, steigen dadurch die Kosten aufgrund von Wartung, Lagerung, aufgrund von technischen Gegebenheiten. Also man kann auch nur den Cost-of-Delay heranziehen und danach entscheiden. Also es gibt einfach, und das ist so die Grundfrage, es gibt verschiedene Möglichkeiten, eine Priorisierung herbeizuführen. Und da ist Waiter's Shortage of First, Cost-of-Delay, der einfache Blick auf Business Value, auch das ist ja möglich. Ich betrachte nur den Business Value oder ich gehe nur nach Kundenfeedback oder ich beziehe nur Stakeholderfeedback ein. Es gibt so viele verschiedene Möglichkeiten. Es ist wichtig, in dem Kontext einer Unternehmung herauszufinden, hey, was brauchen wir hier? Ist es waitest, shortest, shopfirst? Oder sagen, wir sind so nah am Kunden oder wir haben so ein enges Produkt, dass wir vielleicht nur nach Kundennutzen gehen. Auch das kann eine Möglichkeit sein, ja.

Joel Kaczmarek: Sind diese ganzen Frameworks eigentlich auch kombinierbar oder schließen die sich ein bisschen aus?

Patrick Kahl: Und da ist eine schöne Frage. Das ist immer so ein bisschen bei der Grundthese Agile Coaching. Die Idee ist, dass man genau versteht im Kontext der Teamarbeit, hey, welches Framework passt und kann ich aus den verschiedenen Frameworks, die es gibt, wir hatten ja noch mehr genannt, kann ich da Sachen kombinieren, damit, und das ist bei der Grundaussage, wir vielleicht zu dem Punkt kommen, startless, finde ich, Moa. Um sagen zu können, hey, wie können wir denn Zusammenarbeit wirksamer machen? Ist es denn rein das Nutzen von Scrum oder muss ich kombinieren? Da sind wir bei anderen Begriffen, Design Thinking und so weiter oder andere Ansätze, Methoden zu finden. Also ja, sie sind kombinierbar und das zu verstehen, einzusetzen, ist eine wichtige Aufgabe im agilen Kontext einer Transformation, ja.

Joel Kaczmarek: Ich will ja auch die Menschen, die mir zuhören, gerne immer enablen. Müssen die jetzt wie du x Jahre Agilist sein, um sowas selbstständig zu können? Muss man sich da Beratung für einholen oder kann ich mit dem, was es da draußen gibt, auch für mich schon mal relativ schnell Sachen erschließen?

Patrick Kahl: Schöne Herzensfrage. Also Agilität an sich ist ein, so wie ich es wahrnehme, ein urmenschliches Thema. Warum? Es gibt eine schöne Grundausrichtung Prinzipien und Werte, das agile Manifesten. Da steht ein, ist ein Punkt Interaktion in Video über Prozesse und Tools. Was wir gerade machen, ist miteinander interagieren. Wir sind zwei Individuen, interagieren miteinander. Haben wir davon gesprochen, dass wir gerade agil sind? Sind wir nicht. Aber es ist so ein schöner Grundwert, ein Grundprinzip, den eigentlich jeder umsetzen kann, den wir aber vielleicht im Zuge von Standardisierung von größer werdenden Unternehmen vergessen haben umzusetzen. Und wir revitalisieren genau diesen Grundwert. Also ein Teil deiner Frage ist ja, jeder kann agil sein. Das ist eine Haltung, das ist eine Art und Weise des Lebens. Es gibt aber, und da sind wir so in diesem, wie kann ich denn besser werden? Wie kann ich denn agil sein? Wie kann ich mein Ansatz umbringen oder beziehungsweise ansetzen, da wäre die Idee, Frameworks zu nutzen, wie Scrum, wie Save, wie Kanban, um anpassungsfähig oder agil zu sein, ja, und das kann man lernen, ist es aber nicht einfach, weil, und das ist so ein bisschen das Bild, was ich immer aufmache, man kann eine Theorie, man kann Wissen erlangen, die Erfahrung führt aber dazu, dass man Erkenntnisse hat, die Erfahrung, die man machen muss, um zu verstehen, hey, ist es jetzt ein Scrum-Nachbuch oder muss ich das gewissermaßen anpassen, das entsteht meist im Tun oder in der Erfahrung, die man macht, ja.

Joel Kaczmarek: Wo wir ja bei einem wichtigen Thema sind, nämlich wie kaskadiere ich so einen Gedanken denn durch die Organisation? Wie habt ihr es gemacht, dass ihr jemanden wie dich habt, der diese Frameworks beherrscht, der das Mindset dahinter irgendwie atmet und das dann den anderen Kolleginnen und Kollegen nahe bringt? Was ist euer Weg, um das quasi in die Organisation zu treiben?

Patrick Kahl: Ein Ansatz, der hat 2018 begonnen innerhalb des Signal Iduna zu sagen, hey, wir haben, also A haben wir ja auch, das war am Anfang, wir haben eine Ausrichtung, wir haben eine Vision, wieso 2023? Das heißt, was wollen wir denn in Zukunft machen? Wie wollen wir uns als Signal Iduna Zukunft aufstellen? Wir sehen, dass der Markt sich bewegt, wir sehen Wettbewerber, wir sehen, dass es eine Nachfrage nach Talenten gibt. Also wie können wir uns als Signal Iduna anders aufstellen? Das heißt, was passiert ist, 2018 in kleinen Journeys beispielsweise zu schauen, also in kleinen Teams zu schauen, das Thema Agilität zu nutzen, Scrum in kleinen Teams auszuprobieren. Auch wieder der Kontext hilft uns. Scrum in den Hypothesen, die wir haben. Wirksamkeit, Fokus, Flow, Start, Last, Finish, More hatten wir ja schon. In der Motivation der Teams hilft uns das, auch kundenzentriert zu arbeiten. Und da war eine Idee, genau in diesen verschiedenen kleinen Journeys zu handhaben, zu agieren, das zu starten. Und was ist dann passiert? Man hat auch hier über Hypothesen basiert gearbeitet, hat es als gut empfunden. Man hat gesagt, da ist eine Vorderhaftigkeit drin, wir können das, wir wollen das. Und dann mit dem Start der Transformation, also mit dem Einsteigen, anwenden und im Skalieren dieses Ansatzes auf mehrere tausend Mitarbeiter. Zu sagen, hey, wir brauchen dazu auch Rollen. Agile Coaches, Scrum Master, verschiedene andere Rollen, die genau das ermöglichen. Und das ist von der Rollenveränderung bis hin zur Schulung, die durchgeführt wurden für die verschiedenen Rollen wie Agile Coaches, Scrum Master oder Product Owner. Natürlich das stetige Arbeiten, das Begleiten der Teams durch Scrum Master und Agile Coaches. Also es hat einen sehr sowohl theoretischen als auch einen praktischen Ansatz. Also im Tun verstehen, was passiert da, Reflexion, Bildmesser, Learn, Feedback zügeln, also was lernen wir aus den verschiedenen Themen? und das machen wir seit mehreren Jahren und iterieren weiter, wie es so schön heißt.

Joel Kaczmarek: Was sind denn eigentlich auch so, bevor wir gleich nochmal das Thema Priorisierung weiter vertiefen. Was sind denn so typische, sag ich mal, Foren oder Arten zusammenzukommen? Also wenn ich zum Beispiel mal so deinen Vorbereitungssheet durchlese, da steht sowas drauf wie Fokus Campus, Demo Days, Reviews, QBRs, was immer QBRs sind, wenn wir gleich mal von dir lernen, Blocker im Kalender, ja, also vielleicht kannst du uns auch nochmal damit abholen, wie man das in so eine Lebendigkeit kriegt über Events.

Patrick Kahl: Genau, QBR, Quarterly Business Reviews, sogenannte Momente oder Ereignisse einmal im Quartal, um der Organisation verschiedenen Leuten zu ermöglichen, zu verstehen, wo sind wir gerade, was haben wir im letzten Quartal entwickelt, wie sehen die Produkte aus, wie war das Feedback dazu? und das ist die Grundidee von dem QBR, Quarterly Business Review, um mal so einen Blick in die Werkstatt zu schaffen, das ist so die Idee dahinter. Das ist eine Möglichkeit zu verstehen, wo sind wir, also Wirksamkeit zu messen, Wirksamkeit zu verstehen am Produkt selber. Zu schauen, ist die Hypothese aufgegangen, start less, finish more. Auch das ist eher ein Wend, um zu überprüfen, ob wir da richtig sind, ob wir wirklich genug gemacht haben oder wenig gemacht haben, um genug herauszubekommen. Und andere Themen, da hast du gemeint, da sind wir wirklich bei dem Thema Wirksamkeit und Zusammenarbeit. Fokus Campus war ein großes Event letztes Jahr, wo wir über 100 Product Owner zusammen die Möglichkeit eines Raumes angeboten haben, Interaktion zwischen Individuen, das erste Prinzip. Sagen, hey, lasst uns gemeinsam ausrichten, lasst uns gemeinsam verstehen, was wir nächstes Jahr machen und schaffen können. Da war viel Richtung Machbarkeit, da haben wir priorisiert verstanden, was sind die Abhängigkeiten zueinander. Also einen Raum angeboten, um Zusammenarbeit zu ermöglichen, um zu verstehen, wann sind die Themen, die wir gerade machen notwendig. Sind die wichtig, sind die dringend, müssen wir die jetzt machen oder verschieben wir die in die Zukunft? Und das war der Fokus Campus, sehr großes Event in Dortmund, hat viel und da gibt es eine Zitat, das hat mir ein Product Owner gesagt, hat mir tausend Stunden an Mails erübrigt, weil wir einfach zusammen waren und konnten in diesem Raum für drei bis vier Tage interaktiv Probleme lösen. Wir haben uns ausgerichtet, wir haben priorisiert, wir haben Nein gesagt, wertschätzend und mit Gründen, mit einem Nutzenperspektiv und das war eine Möglichkeit, ja, Fokus Campus.

Joel Kaczmarek: Und wenn wir jetzt nochmal zum Thema Priorisierung zurückkehren. Wir sollten vielleicht auch mal eine Achse aufmachen, die in dem Kontext, glaube ich, ganz interessant ist. Und das ist Outcome versus Output. Warum ist das wichtig zu unterscheiden und wie unterscheidest du es?

Patrick Kahl: Die komplette Sicht auf die Dinge ist, ich gebe etwas rein, Input, dann mache ich etwas. Das ist meistens die Aktivität. Dann haben wir das Thema Output, also da entsteht etwas, da entsteht ein Produkt. Das Outcome selber ist dann die mit, und das kenne man natürlich auch als Impact, also die Wirkung, die entsteht. Also was entsteht denn daraus, wenn ich jetzt zum Beispiel eine Tasse herstelle oder einen Stift? Ist der Kunden zufrieden? Habe ich da ein positives Feedback? Ist es das, was ich erreichen wollte? Und das ist so ein bisschen der Blick auf Outcome. Also nur das Erstellen von Dingen heißt ja noch lange nicht, dass es zur Zufriedenheit führt. Oder dass das genau den Nutzen versprach, den ich am Anfang versprochen habe. Deswegen ist der Blick auf das Outcome wichtig. Und eine Möglichkeit ist zum Beispiel, aktives Kundenfeedback einzufragen, NPS-Befragung zu gehen, im Marketingbereich Panel-Befragung. Also es gibt verschiedene Möglichkeiten, um diesen Outcome messbar und greifbar zu machen.

Joel Kaczmarek: Und ein anderes Stichwort, was ich interessant finde, so aus deinem, was du mir im Vorfeld erzählt hast, war der Begriff Slicing. Also, dass man sich Sachen auch zurechtschneidet auf eine Art, weil das ist ja auch eine Form von Priorisierung. Gibt es da so eine Art Gesetze, wie man sich vielleicht, weil da sind wir ja wieder bei dem ganzen Thema Backlog-Management, wenn man sagt, ich habe ein großes Ziel mit aber großer Komplexität, dass ich mir das einfach auch klein slicen kann und Priorisierung quasi durch Teilen und Herrschen umsetze?

Patrick Kahl: Ja, es gibt in der Tat sogenannte Patterns, Slicing Patterns, auch wieder ein englischer Begriff. Also Möglichkeiten, nachdem ich schauen kann, in dem Begriff User Story oder in meiner Aktivität, die ich vorhabe, zu schauen, hey, gibt es da Indikatoren, die mir einen Hinweis geben, dass das Thema nicht aus einem Schritt besteht, sondern aus mehreren. Oder nicht nur aus einer Funktionalität besteht, sondern aus mehreren. Das einfachste Beispiel ist, wenn ich eine User Story schreibe oder ein Produkt und eine Unverknüpfung hat. Also ich möchte, dass der Stift blau aussieht und einen Radierer hinten hat. Also habe ich zwei Funktionalitäten in dieser Beschreibung und sage, okay, die Unverknüpfung gibt mir einen Hinweis. Zum Beispiel kann ich das slicen. Was ist wichtiger? Brauche ich jetzt den Radierer oder muss er blau aussehen? Vielleicht reicht es auch, oder vielleicht ist es nur, wenn ich den Radierer habe, bevor ich irgendwie auf die blaue Farbe gehe. Also das wäre ein Slicing-Pattern. Andere Möglichkeiten ist so ein bisschen die Komplexität rauszunehmen. Oder, das wäre auch eine Möglichkeit zu verstehen, hey, die Funktionen, die ich anbiete, also ich kann den Stift blau machen, selbstständig im Team, aber um den Radierer anzubringen und zu fertigen, brauche ich ein anderes Team. Ist das Team schon bereit dafür? Nein? Okay, dann mache ich da wieder einen Slice, also kümmere mich um die blaue Farbe und gehe dann im nächsten Schritt dann auf das Team zu. Also das wären zwei, drei Ideen für einen Slicing Pattern.

Joel Kaczmarek: Und das mal weitergedacht, wir haben jetzt viel über Backlog-Management dahin geredet, dass wir die Aufgaben angucken, aber es gibt ja auch sowas wie Stakeholder-Management. Also es ist ja nicht immer nur so, dass ich die Aufgabe kleinteilen muss, sondern manchmal muss ich auch die Leute, die daran beteiligt sind, in irgendeiner Form dosieren. Gibt es da spannende Ansätze?

Patrick Kahl: Ein Naheliegendes ist A zu verstehen, wer sind denn meine Stakeholder, also Stakeholder-Management zu beschreiben. Wen habe ich in meinem Kontext als Stakeholder, die beispielsweise nur informiert werden müssen, die gemonitort werden müssen, die ich aktiv mit allen um muss in den Entscheidungsprozess. Es gibt so schöne Stakeholder-Matrix, die man aufbauen kann, um einfach zu verstehen, hey, wen habe ich denn in meinem Kontext, wer hat welchen Einfluss. Also auch das zu verstehen, nicht nur wen muss ich informiert haben, sondern wer hat gemäß Kontext oder Struktur oder Organisation Einfluss auf gewisse Dinge, Entscheidungsprozesse, auf die Produktentwicklung. Also Stakeholder-Management ist wichtig zu verstehen. Ah, wer sind denn meine Stakeholder? Wer finanziert mein Produkt? Wer finanziert mein Team? Wer nimmt es im Zweifel am Ende ab? Das zu verstehen, das zu visualisieren und mithilfe einer Stakeholder-Matrix, die heißt genauso, wie ich sie benannt habe, recht einfach, vier Felder, vier Quadranten und dann zu schauen, hey, wer ist denn mein direkter Ansprechpartner? Dass wir bei dem Thema Nein sagen, gemäß Stakeholder und dem Verständnis, wer da ist, sagen, okay, welche Art des Nein-Sagens finde ich hier an?

Joel Kaczmarek: Und ich hange mich jetzt mal mit dir weiter. Wenn ich jetzt eine Priorisierung gefunden habe, wie visualisiere ich das vielleicht auch? oder bringst, sag ich mal, ein Verständnis für die Leute? Also ich habe bei dir zum Beispiel was gelesen, wie Color-Coding fand ich irgendwie einen interessanten Faktor oder mit Bezahlen kann man es manchmal beziffern. Wie gehst du da vor, um sowas dann hinterher den Leuten bildlich zu machen?

Patrick Kahl: Wenn ich rechts rausschauen würde, du hast ein Board, das ist eine Möglichkeit, ein Kanban-Board. Also einfach transparent zu zeigen, hey, was sind denn die Backlog-Items in meinem Backlog? Also den Backlog einfach auf einem Board, weil so ein Kanban-Board zu visualisieren und da zu schauen, hey, was ist da alles drin? Das ist eine Möglichkeit und das ist die praktisch, also die naheliegendste. Natürlich auch in der Welt, in der wir leben, online, remote, auch zu schauen, hey, gibt es verschiedene Tools, die man nutzen kann? Ein naheliegendes auch hier, Jira, Trello, Miro. Also es gibt verschiedene Anbieter, die einfach dir Möglichkeit geben zur Anwendung. Kollaboration, die Dinge zu visualisieren. Also das wäre eine Möglichkeit, Kanban-Boards ganz einfach zu erstellen. Oder, und das ist auch das, auch ein Blatt Papier und einfach runterschreiben und dann die Items, die man hat, einfach darzustellen, priorisiert von oben nach unten.

Joel Kaczmarek: Welche Rolle spielen denn insgesamt Daten in diesem Prozess? Weil darauf zieht es ja so ein Stück weit ab. Also ein Datum ist ja erstmal nur eine Festlegung von einem Inhalt. Und ein Datum kann sein die Komplexität, ein Datum kann sein der Impact etc. etc. Wie gehe ich in solchen Methoden mit Daten um?

Patrick Kahl: Oh, da spielt vieles mit, da hast du jetzt so ein bisschen die Box der Pandora aufgemacht. Einmal den Bezug zur Wirksamkeit, hat aber genauso den Bezug zum Wegen, hey, mache ich denn wenig und habe dann am Ende den großen Ausgang, also wieder Start, Let's, Finish, More. Aber was gibt es da für Attribute oder Daten, wie du es gerade genannt hast? Ich kann feststellen, wie alt ist denn die Aktivität, die ich habe? Wie lange brauche ich, um das umzusetzen? Habe ich das also richtig gesliced, den Begriff von eben zu nutzen, dass ich das im besten Fall innerhalb von wenigen Stunden umsetzen kann, um dann wieder zu sagen, okay, habe ich das richtige Outcome erreicht und dann wieder Feedback zu bekommen? Also Alter von gewissen Dingen. Ich kann natürlich schauen, und da sind wir bei dem Punkt von eben, Cost of Delay, Waiter, Shutter, Chauffeur, Spelling, Poker, all die Themen. Also das ist so ein bisschen ein Pricetag zu geben. Wie hoch ist der Nutzen? Was kostet mich das? Wer ist involviert an Teams? Wen brauche ich alles dazu? Brauche ich das gesamte Team oder nur einen Teil davon? Also das sind Daten. Durchlaufzeiten, wie lange? Auch wieder da vorne dein Kanban-Board. Ich habe einen Backlog, einen Startpunkt. Und so ein Item, so eine Aktivität wandert ja von links nach rechts. Also es ist Ich ziehe mir das aus dem Backlog raus, also bin ich im Progress, arbeite daran, bin in Entwicklung, bin vielleicht im Test, bin im Quality und so weiter. Also ich habe verschiedene Bereiche, die ich habe und ich kann einfach schauen, wie lange dauert das von A nach B? Also wie lange dauert dieses Handover? Und dann sind wir bei dem Punkt Wirksamkeit. Dauert das Handover, also die Übergabe dieses Items innerhalb des Teams, wenige Minuten oder reden wir davon Tage? Und das zu verstehen, das zu visualisieren, das hat eine hohe Einzahlung auf das Thema Wirksamkeit und Zusammenarbeit. Genau, das sind so die Themen. und ein Punkt Richtung Kannbahn, das hattest du auch vorhin, Work in Progress, also zu verstehen, hey, wie viele Aktivitäten kann ich mir parallel in, Beispiel in Doing ziehen, also in die Umsetzung oder, und das ist die andere Frage, bei Start, Last, Finish, More, also wie viel darf ich maximal beginnen, sodass ich nicht stehen bleibe in meinem Prozess, sodass die Teams gut ausgelastet sind. immer noch motiviert, aber nicht zu ausgelastet, sodass sie dann in eine Frustration kommen und sagen, okay, ich habe fünf Items parallel, okay, dann habe ich dann vielleicht ein Bottleneck, also bei dem Thema Utilization Trap. Also da schwingt so ein bisschen was mit. Das zu verstehen, das zu visualisieren, ist extrem wichtig, um genau diesem Grundsatz auch folgen zu können.

Joel Kaczmarek: Bei WIP muss ich mal an RIP denken, also manchmal ist das Work in Progress dann mal so Rest in Peace. Und bei dem Faktor, den du, was du eben alles beschrieben hast, gibt es denn so eine Art zentrales Wasserloch, sage ich mal, wo alle zusammenkommen und sich diese Dinge angucken, also wie jetzt dein Beispiel mit dem Kanban-Board, oder ist es auch ein Stück weit über Stakeholder verteilt, da dass der eine sich diese Daten anguckt und die andere sich jene.

Patrick Kahl: Ich mange mit dem Begriff Wasserloch, muss ich mir direkt merken. Wasserloch ist schön. Also kommt man mit einem Wasserloch zusammen. Ja, also es gibt sowohl Events auch wieder hier, wo man sich als Team selber genau diese Daten auch anschauen kann. Ein schönes Format dafür ist das Daily Stand-Up im Scrum. Jeden Tag 15 Minuten, wo man genau auf die Sachen drauf schaut. Hey, wo stehen wir gerade? Was haben wir denn gerade in Parallelarbeiten? Wie sehen die Daten aus? Aber auch in der Retrospektive genau zu schauen. Hey, wie haben wir in den letzten Monaten oder letzten Wochen, letzten Tagen gearbeitet? gearbeitet? Haben wir mehr geschafft? Haben wir weniger geschafft? Wie ist denn unsere Throughput-Reihe? Da haben wir einen neuen Begriff, also unsere Durchlaufzeit. Ist irgendwas stecken geblieben? Also haben wir sechs Items geplant und sind sechs Items fertig geworden? Oder konnten wir so etwas nachziehen? Also Retrospektiven, Daily Stand-Up, ja, und auch ein QBR. Auch da ist wieder der Begriff von vorhin, auch das ist ein Event, um nicht nur auf ein Produkt zu schauen, sondern auch Daten heranzuziehen. Ich sage immer gerne, oder vergesse, es gibt eine subjektive Wahrnehmung. Ich fasse Dinge an und hat eine subjektive Einschätzung über das Thema und eine objektive, also zwei Seiten, subjektiv und objektiv. und objektiv sind wir genau bei Daten. Was sagen mir die Daten? Um so ein bisschen einen sachlichen Aspekt reinzubekommen und vielleicht persönliche oder Meinungen versuchen glattzuziehen, weil es kann genau das passieren, was du sagst, dass man natürlich auf verschiedene Daten schaut, die für sich interpretiert. Deswegen ist es wichtig, dass man gemeinsame Events hat und genau die relevanten Stakeholder in das Thema mit einbezieht, genau.

Joel Kaczmarek: Der letzte Fragenkomplex, den ich für dich jetzt noch hätte, wäre der Bereich Ziele und Messbarkeit. Also du hast, glaube ich, auch OKA schon mal fallen lassen in einem Nebensatz. Wie baue ich Ziele, wenn mein Mastermind oder mein überbordender Satz Start, Let's Finish More ist und wie messe ich dann deren Erfüllung?

Patrick Kahl: Also nehmen wir mal das Thema OKR, weil sonst könnten wir auch bei Zählausrichtung und Messbarkeit, glaube ich, könnten wir sehr viel, sehr klein und sehr groß. Aber OKR oder ein OKR-Ansatz heißt ja OKR als Objective and Key Results. Das heißt, ich habe ein übergeordnetes Ziel, Objective, und ich habe Hypothesen, Key Results, die das Versprechen haben, wenn ich das mache, dann zahlt das positiv auf den Erfolg des Objectives, also das Ziel, ein. Wie entsteht sowas? im Zweifel dadurch, dass man eine überragende Vision oder Strategie für ein Jahr hat oder länger und sagt, hey, und dann sind wir wieder bei dem Slicing-Thema, wie kann ich denn genau diese große Vision, die ich habe, die Ausrichtung für ein Jahr oder für mehrere Jahre in kleinere Bereiche unterteilen, also quaterlich einbauen. Und da sind wir genau bei der Idee von Objective und Key Results, also OKRs. zu überlegen, was mache ich denn jetzt in diesem Quartal, weil, und das sind wir beim Thema Cost of Delay, Weight of Structure First und Nutzenaptitive, was muss ich jetzt machen, weil es den höchsten Nutzen verspricht, weil wenn ich es verzögere, beispielsweise genau dieser Nutzen nicht mehr eintritt. Und dann kommt man wieder in die Priorisierung, in die Diskussion mit verschiedenen Stakeholdern. Und genau diese Fokussierung auf ein Quartal hilft mir im besten Fall, nicht alles zu machen, was ich für das Jahr habe, sondern was muss ich jetzt machen, Also start less, um am Ende das Outcome zu erzielen. Also am Ende auch dann genau das, was ich mir aufgeschrieben habe, umzusetzen. Und das ist dann wieder bei vorhin, was wir gesagt haben, hat einen hohen motivierenden Faktor, wenn man regelmäßig drauf schaut, wie entwickeln sich die Key Results? Wie ist denn das Kundenfeedback, was ich bekomme? Haben wir dann Steigerungen? Also die Key Results sind meist auch immer sehr quantitativ, also messbar gehalten. Das heißt, ich setze mir gewisse Hypothesen der Umsetzung. Ich versuche gerade ein Beispiel während des Redens auszuarbeiten, dass ich beispielsweise sage, hey, wenn ich gewisse Funktionalitäten innerhalb einer App, also Features bereitstelle, mit der Annahme, dass genau diese Funktionalitäten in der App erfolgsverpflichtend sind, weil sie einen hohen Geschäftsverfälle abdecken. Also ich habe Kunden, die das stark nutzen. Somit hat das einen positiven Effekt auf meine Gesamtnutzung für die App oder für einen Kundenportal. Das heißt, ich gehe mit der Hypothese in den Raum, ich benutze genau diese zwei digitalen Services, weil das Versprechen hoch ist, dass diese digitalen Services einen hohen Kundenstamm haben oder von vielen Kunden genutzt werden, sodass das Objective, Präsenzen der Kunden-App am Markt hochgehalten wird, einen positiven Effekt hat. Und dann fokussiere ich mich nicht auf 50 Features, sondern genau auf die zwei, die ich verspreche, für dieses Quartal umzusetzen. Und das ist die Grundidee dahinter.

Joel Kaczmarek: Du hast ja vorhin auch schon mal erwähnt, die Leute nicht zu demotivieren, dadurch, dass sie zu viele Sachen auf dem Tisch haben. Gibt es denn so eine Kennzahl, wenn man Start, Let's Finish, More sich über die Tür schreibt, wie viel man gleichzeitig machen sollte?

Patrick Kahl: Auch da gibt es eine Thumbroll, also so eine Daumenregel aus dem Kanban-Ansatz. Meist ist das die, also es gibt einen Ansatz, der, wenn man von der grünen Wiese startet und wir haben keine Erfahrung, was irgendwie mein Whip ist, das ist die Kernfrage, dann ist das so ein bisschen die Hälfte von der Teamgröße. Also wenn wir sagen, hey, wir haben irgendwie zehn Mann im Team oder zehn Menschen im Team, Frau und Mann zugleich, dann ist mein VIP circa fünf. Also starte ich mit einem VIP von fünf und dann ist ja das Schöne bei einer Retrospektive zu schauen, hey, wie hat sich das entwickelt? Haben wir mehr gepult? Haben wir weniger? Wenn weniger, woran lag es? Beispielsweise, weil wir zu uns zu große Items, Slicing Patterns reingezogen haben in unseren Backlog. Also Thumbroll, die Hälfte vom Team ist dein erstes VIP und dann schaust du im Erkenntnis, also empirisch zurück, wie kann, ist die fünfte die richtige Zahl oder müssen wir mehr oder weniger machen?

Joel Kaczmarek: Patrick, super spannend und gefühlt könnte ich mit dir noch viel, viel länger reden. Aber ich glaube, für heute war das schon mal ein echt guter Input. Hast du vielleicht noch abschließend einen Tipp, wenn Menschen sich jetzt erst daran trauen, was sie tun können, um da, sage ich mal, einen Fuß in die Tür zu kriegen bei diesem ganzen Thema?

Patrick Kahl: Auch wieder da schön kann man, starte da, wo du bist, das zu visualisieren, was du gerade machst. Nimm dir ein Board, nimm dir ein Stiftpapier, scribble deinen Prozess auf, deine Aktivitäten auf, die du machst, um ein Thema umzusetzen. Und genau, wenn man diese Visualisierung hat, wo bin ich gerade, was mache ich gerade, dann kann eine Optimierung stattfinden. Also starte da, wo du bist, visualisiere das und dann genau mit dieser Visualisierung optimiere dich im nächsten Schritt. Dann sind wir eigentlich so in einem Zyklus drin, reflektiere, schau zurück, fang so ein paar Daten an zu scribbeln. Wir hatten das, hey, wie viel kann ich maximal machen, etc. pp. Also da, wo du bist, visualisieren und dann reflektieren und dann bist du eigentlich schon da, wo du sein sollst.

Joel Kaczmarek: Ja, mega. Hey, du, hat viel Spaß gemacht. Vielleicht vertiefen wir auch nochmal einzelne Aspekte später, aber für den Moment, dann hat man erstmal was zum drauf rumdenken. Von daher, vielen Dank dir und auf bald.

Patrick Kahl: Danke dir. Ciao.

Outro: Danke fürs Zuhören beim Digital Kompakt Podcast. Du merkst, hier ziehst du massig Wissen für dich und dein Unternehmen heraus. Wenn du mit uns noch erfolgreicher werden möchtest, abonniere uns auf den gängigen Podcast Plattformen. Und hey, je größer wir werden, desto mehr Menschen können wir helfen. Also erzähl doch auch deinen Kolleginnen und Kollegen von uns. Bis zum nächsten Mal.