Rückwärts arbeiten, um vorwärts zu kommen (mit Jeff Gothelf von Gothelf.co)

Lesen Sie das Transkript:

Wir testen aktuell die Transkription unserer Podcasts mit einer Software. Bitte verzeihen Sie eventuelle Tippfehler, da der Bot nicht immer zu 100 % korrekt ist.

Ben Aston:

Um ehrlich zu sein: Entsprechen Ihre Projekte je wirklich dem, was Sie erhofft haben? Könnten oder sollten sie das? Woran liegt das? Vielleicht, weil Sie nicht geplant haben? Oder weil Sie Ihr Team nicht gut geführt haben. Oder, weil Sie Schwierigkeiten hatten, Ihr Team und die Stakeholder zu steuern. Vielleicht alles zusammen. Vielleicht, weil Sie nicht alle auf das endgültige Ergebnis und die Vision des Projekts ausgerichtet waren. Bleiben Sie also dran beim heutigen Podcast, wenn Sie lernen möchten, wie Sie rückwärts arbeiten können, um mit mehr Zuversicht und besseren Projekten voranzukommen, das Scheitern zu minimieren und Ihre Erfolgschancen zu erhöhen.

Vielen Dank fürs Einschalten. Ich bin Ben Aston, Gründer des Digital Project Manager. Willkommen beim DPM-Podcast. Unsere Mission ist es, Projektmanagern zum Erfolg zu verhelfen, Menschen zu unterstützen, die Projekte betreuen, damit sie besser liefern können. Wir helfen Ihnen dabei, Ihre Projektkompetenz auf die nächste Stufe zu heben.

Besuchen Sie thedigitalprojectmanager.com, um mehr über unsere Schulungen und Ressourcen zu erfahren, die wir im Rahmen einer Mitgliedschaft anbieten. Dieser Podcast wird Ihnen präsentiert von Clarizen, dem Marktführer für Enterprise Projekt- und Portfoliomanagement-Software. Besuchen Sie Clarizen.com für weitere Informationen.

Heute bin ich mit Jeff Gothelf im Gespräch. Jeff lehrt Führungskräfte und Teams durch Remote-Beratung und Coaching, Workshops, Keynotes und Bücher, sich auf die Kunden zu fokussieren, aus Fehlern zu lernen und eine agile Kultur zu schaffen, die ständig daran arbeitet, ihre Produkte, Dienstleistungen und Arbeitsweisen zu verbessern.

Er ist Mitautor von einigen Büchern, die Sie gelesen haben oder zumindest kennen – „Sense and Respond“, „Lean UX“ als das Bekannteste, „Lean vs. Agile vs. Design Thinking“. Kürzlich hat er Sense and Respond Press mitgegründet – das ist ein Verlagshaus für moderne, transformative Wirtschaftsbücher. Also, hallo Jeff, vielen Dank, dass du heute bei uns bist.

Jeff Gothelf:

Hallo Ben, danke, dass ich heute dabei sein darf.

Ben Aston:

Ich möchte gleich mit dem Thema Projekte einsteigen. Ich weiß, du bist eher produktorientiert, aber für uns PMs, die Projekte managen, kann das Teil eines größeren Programms oder einer Produkt-Roadmap sein.

Mich interessiert, wie du das siehst. Wie können wir als Projektleiter uns und unsere Teams auf eine iterativere Vorgehensweise orientieren? Und ich weiß, dass du gerade einen Beitrag über die Top-10-Gegenargumente zu Agile geschrieben hast, aber das funktioniert hier nicht. Deshalb möchte ich über einige der Herausforderungen sprechen, die wir als digitale Projektmanager haben und warum.

Grundsätzlich denke ich, die Kunden, mit denen wir arbeiten, und die Stakeholder mögen die Idee von agilem Arbeiten. Wir können diskutieren, was genau Agile bedeutet, aber ob wir von einem Liefer-Framework oder breiter von einer Denkweise sprechen – ich denke, lass uns mehr über diese agile Denkweise sprechen.

Doch ich finde, es gibt drei Herausforderungen: Erstens das Misstrauen des Kunden, zweitens zu eng definierte Anforderungen und drittens mangelndes Budget und Zeit. Also Kunden, die agil sein wollen, aber weder das Budget noch die Zeit dafür haben.

Kunden haben zu eng definierte Anforderungen und es gibt ein Vertrauensproblem. Sie vertrauen der Agentur oder dem Team nicht voll und ganz und können nicht einfach loslassen und auf den Prozess vertrauen. Das sind drei Herausforderungen. Über welche möchtest du zuerst sprechen?

Jeff Gothelf:

Lass uns zuerst über den Mindset-Shift sprechen. Das ist kritisch, besonders für digitale Projektmanager. Wenn wir Teams, Produkte, Dienstleistungen, Unternehmen und Kunden erfolgreich machen wollen, müssen wir realisieren, dass sich die digitale Produktentwicklung heute fundamental verändert hat.

Der Unterschied zu heute im Vergleich zu vor 10 oder 15 Jahren ist: Software ist heutzutage kontinuierlich. Wir gehen nicht mehr in den Laden, um eine Softwarebox zu kaufen. Wir abonnieren sie, installieren sie und sie wird dann fortlaufend aktualisiert.

Sie wird einfach fortlaufend besser. Niemand geht und kauft die nächste Version von Facebook, Pinterest oder Amazon im Laden. Das Produkt verbessert und verändert sich ständig weiter. Und das ist der grundlegende Unterschied zwischen Projekt- und Produktdenken. Projekte und Produkte unterscheiden sich.

Heutzutage bauen wir wirklich Systeme, diese kontinuierlichen Systeme, bei denen wir in jedem Zyklus – nennen Sie es Sprint oder Iteration – die Möglichkeit haben, das System zu verbessern. Fügen wir neue Funktionen hinzu? Optimieren wir bestehende? Entfernen wir Dinge?

Es gibt viele Möglichkeiten, aber meistens sind es diese drei Kategorien. Das ist der springende Punkt: Diese Dinge enden nicht. Die Idee „Ich manage das Projekt bis zum erfolgreichen Launch“ – das ist schön, aber ein Launch ist lediglich der Anfang des Gesprächs mit Ihrer Zielgruppe, nicht das Ende des Produkts.

Ben Aston:

Genau. Eins der Dinge, die wir als digitale Projektmanager häufig erleben, wenn wir den Kunden eine agilere Zusammenarbeit nahelegen möchten, heißt das oft: „Bezahlen Sie uns für ein dediziertes Team für einen gewissen Zeitraum und lassen Sie uns zusammenarbeiten.“ Sagen wir: „Ihr Website-Launch ist erfolgt, jetzt lass uns darauf iterieren.“

Wie bei Software, die fortlaufend aktualisiert wird, kann auch eine Website ständig weiterentwickelt werden. Aber dafür braucht es Vertrauen: Der Auftraggeber muss darauf vertrauen, dass am Ende Wert dabei entsteht. Wie können wir als Projektmanager unseren Kunden durch dieses Misstrauen führen – wie können wir die Lücke beim Vertrauen schließen, wenn die Lieferergebnisse am Anfang unbekannt sind?

Jeff Gothelf:

Es gibt viel zu besprechen. Fangen wir mit dem Fundamentalen an: In welchem Geschäft sind Sie eigentlich tätig? Sind Sie Partner Ihrer Kunden, um Ergebnisse zu erreichen, oder liefern Sie einfach nur eine feste Anforderungsliste ab? Denn wie du schon gesagt hast, entsteht da häufig ein Widerspruch: „Hier sind die Anforderungen, aber bitte sei agil damit.“ Das ergibt keinen Sinn.

Hier hilft ein Spektrum, das mein Kollege Jeff Patton entworfen hat. Am einen Ende steht das Wort „Arzt“, am anderen „Kellner“.

Fragen Sie sich als Dienstleister: Wo stehen Sie auf diesem Spektrum? Wenn Sie auf der Kellner-Seite sind, ist Ihr Job, genau das zu bringen, was bestellt wurde.

Ben Aston:

Genau.

Jeff Gothelf:

Und ob das dann gegessen wird oder schmeckt, ist Ihr Problem nicht. „Sie wollten Steak, Salat und Cola, das habe ich Ihnen gebracht.“ Viele Organisationen arbeiten genau so: Geben Sie mir eine bestimmte Summe, ich baue Ihnen genau das, was Sie bestellt haben. Auf der anderen Seite steht der Arzt.

Beim Arzt sagen Sie ja auch nicht: „Ich möchte dieses Medikament, diese Impfung, diese Behandlung“, und der Arzt sagt einfach okay. Sondern der Arzt berät mit dem Ziel, Ihre Kennzahlen, Ihre Gesundheit zu verbessern.

Und die Frage ist, wo auf diesem Spektrum befinden Sie sich? Agilität fällt viel leichter, wenn Sie auf der Arzt-Seite stehen, denn an jedem Ende des Spektrums ist Erfolg unterschiedlich definiert. Auf der Kellner-Seite ist der Erfolg: Haben Sie das geliefert, was bestellt wurde – pünktlich und zum vereinbarten Preis? Das ist keine Agilität. Auf der Arzt-Seite hingegen geht es um Ergebnisse – um Veränderungen im Nutzerverhalten Ihrer Kunden, um die Messung dieser Veränderungen.

Haben wir es geschafft, dass Kunden mehr kaufen, mehr Zeit verbringen, mehr erzählen, mehr als ein Produkt kaufen? Das ist der Bereich, in dem Agilität wirklich glänzt: wenn große Unsicherheit herrscht und wir nicht wissen, wie genau wir den gewünschten Geschäftserfolg erreichen.

Agilität ist nur möglich, wenn Sie sich vom Kellner hin zum Arzt-Verhalten entwickeln.

Ben Aston:

Es geht also auch darum, dass der Kunde oder Stakeholder Kontrolle und Vertrauen abgeben muss. Wenn du Organisationen coachst – wie motivierst du zu mehr Offenheit für das Unbekannte und für mehr Appetit auf agile, beratende Ansätze statt Kellner-Service?

Jeff Gothelf:

Der Weg ist, respektvoll nach dem „Warum“ zu fragen. Wenn jemand kommt und sagt: „Ich brauche bis Freitag zehn Features, wie viel kostet das?“, müssen Sie nachhaken: „Warum möchten Sie diese Features?“

Erarbeiten Sie gemeinsam mit dem Kunden eine Problemstellung statt fester Anforderungen. Zum Beispiel: „Ich brauche eine Mobile App bis Freitag.“ – Nachfragen: „Warum?“ – „Unsere Mobile-Commerce-Zahlen sind zu niedrig, wir möchten sie steigern.“ – „Um wie viel?“ – „15 % mehr wäre super.“

Jetzt geht es statt um „Bau mir eine App“ um „Steigere Mobile Commerce um 15 %“ – damit sind keine festen Features mehr vorgegeben, und das Team muss agil experimentieren, lernen und iterieren, bis das Ziel erreicht ist.

Der Erfolg bemisst sich also daran, ob wir Mobile Commerce um 15 % steigern, nicht daran, ob die App pünktlich ausgeliefert wurde. Die Annahme, dass Anforderungen automatisch zu gewünschten Ergebnissen führen, ist ein großes Risiko – meistens liegt man falsch, egal wie erfahren man ist.

Gute Produktmanager haben ca. in 30 % der Fälle Recht, das gilt auch für Stakeholder und Kunden. Wenn Sie also zu 70 % falsch liegen, ist doch ein Ansatz am besten, der Ihnen hilft, möglichst schnell herauszufinden, was wirklich zum Ziel führt, anstatt blind eine „blaue App mit fünf Features“ zu bestellen.

Ben Aston:

Das ist sehr weise. Die Anfrage des Kunden in eine Problemstellung umzuwandeln und das „Warum“ zu hinterfragen, führt zu Raum für Problemlösung und Identifikation von echten Lösungen.

Das hilft auch bei eng definierten Anforderungen – und ich möchte noch auf die Herausforderung Budget/Zeit eingehen. In deinem Post „Agile ist super, aber es funktioniert hier nicht“: Denkst du, dass Budget- und Zeitmangel Gründe sein können, dass Agile hier nicht funktioniert?

Jeff Gothelf:

Meiner Ansicht nach liegt hier ein Missverständnis darüber vor, was agile Prozesse wirklich bieten. Es geht nicht um Budget und Zeit, sondern um Risikominimierung. Statt drei Monate an einer „perfekten“ Lösung zu arbeiten, lernen wir möglichst schnell, ob wir auf dem richtigen Weg sind – und passen bei Bedarf an. Das ist der Kern.

Wenn das Team auf Marktdaten reagiert und Kurs anpasst, ist es agil. Das hat nichts mit Budget oder Zeit zu tun. Das Gegenteil ist: „Es kostet 75.000 Dollar, um die App in einem Monat zu bauen…“ Vielleicht ist das eine realistische Schätzung, vielleicht nicht. Wenn das Budget ausgegeben ist und die App nichts bringt? Riesiges Risiko beim Wasserfall-Ansatz: Man glaubt, alles vorab wissen und festlegen zu können – das ist riskant und meistens geht es schief.

Ben Aston:

Das hängt aber davon ab, von wem die Anfrage kommt. Zurück zum Steak, Salat und Cola für 30 Dollar in 15 Minuten: Wenn ich das will, will ich es – auch wenn es nicht gut für mich ist. Ich suche einfach nur jemanden, der es liefert.

Jeff Gothelf:

Ja. Dann gehen Sie zum Kellner. Aber zum Arzt: Wenn der Arzt Ihre KPIs misst (BMI, Gewicht, Blutdruck, Cholesterin) und Sie trotzdem Steak, Salat, Cola verlangen, sagt der Arzt: Nein, denn das Ziel ist, Sie gesünder zu machen. Der Kellner liefert, was Sie wünschen – der Arzt strebt ein Ergebnis an. Viele Dienstleister begreifen nicht, dass Agilität nicht nur ein anderer Prozess, sondern ein anderes Geschäftsmodell ist. Das ist schwer zu verstehen und noch schwieriger umzusetzen.

Ben Aston:

Und das erfordert Reife auch auf Kundenseite, richtig?

Jeff Gothelf:

Genau.

Ben Aston:

Das ist eine echte Herausforderung, wenn der Kunde an klaren Lieferungen festhält. Umso wichtiger, die Anfragen zu hinterfragen und quasi den „Arzt-Hut“ aufzusetzen. Jeff hat gerade einen tollen Artikel zum Thema Kundenzentrierung und Ergebnisorientierung veröffentlicht – mit einer aktualisierten Version der Future-Press-Release-Technik, inspiriert von Amazons „Working backwards“-Prozess. Es geht dabei um Risikomanagement und Zusammenarbeit.

Wie hilft dieser Ansatz? Es gibt viele Techniken, aber wie ist deine Praxiserfahrung mit dem Future-Press-Release als Methode? Welche Effekte hast du erlebt?

Jeff Gothelf:

Das Wichtigste: Man versetzt sich in eine erfolgreiche Zukunft und reflektiert, was dazu geführt hat. Die Variante im Artikel stellt den Kunden ins Zentrum. Das Ziel ist nicht nur „Wir haben das System erfolgreich ausgeliefert und Geld verdient“, sondern: „Wir haben geliefert, das Verhalten des Kunden hat sich verändert, und so sind die gewünschten Ergebnisse eingetreten.“

Um dahin zu kommen, muss man Erfolg über Kundenerfolg definieren und die Wertstiftung für den Kunden durchdenken – inklusive der Zusammenarbeit im Unternehmen. Welche Hürden waren zu nehmen und wie hat das am Ende dem Geschäft geholfen? Das Gespräch darüber findet typischerweise am Anfang eines Vorhabens nicht statt.

Meistens sind Erfolge: Lieferung termingerecht und im Budget. Aber eigentlich ist Erfolg: Ein Vorgehen, das Kunden erfolgreich macht – und damit Geschäftserfolg nach sich zieht.

Wenn Sie das von Anfang an diskutieren, können Sie im weiteren Verlauf jede Arbeit mit dem Ziel abgleichen: Hilft uns das dabei, das Ziel zu erreichen? Wenn nicht – lassen wir es!

Ben Aston:

Für diejenigen, die den Artikel noch nicht gelesen haben: Es geht um die Vorstellung einer zukünftigen, erfolgreichen Situation – also eine Art Blick in die Kristallkugel. Dabei spielen Produkt-Markt-Fit, Attraktivität, Machbarkeit und Rentabilität große Rollen. Doch wie überprüft man, ob der Future-Press-Release zutrifft, wenn vieles auf Annahmen basiert? Hast du Ansätze zur Validierung – gerade weil man ja nur zu 30 % richtigliegt?

Jeff Gothelf:

Es liefert ein Zielbild – eine Ambition des Teams. Natürlich wird man bei Vorhersagen teilweise falsch liegen, aber grundsätzlich geht es darum, ein Zielbild und die erwarteten Herausforderungen zu formulieren. Das dient im Verlaufe als Filter für Entscheidungen, bis man gegnüber der ursprünglichen Annahmen aus dem Markt neue Erkenntnisse hat und Kursanpassungen vornehmen kann. Ziel ist, so lange konsequent am Zielbild zu arbeiten, bis die Realität andere Rückschlüsse fordert.

Ben Aston:

Kann es dabei auch Nachteile geben – Kreativität oder Teamgeist blockieren? Worauf muss man bei dem Ansatz achten, warum hast du die Technik weiterentwickelt?

Jeff Gothelf:

Die größte Herausforderung: Teams sind oft zu wenig kreativ oder ambitioniert – das Dokument ist zu „brav“. Man setzt Ziele, die man ohnehin leicht erreicht. Das Stichwort (im Amerikanischen): „Sandbagging“. Die größte Gefahr: ambitionierte Ziele und Herausforderungen werden nicht bedacht.

Das Update von Amazons Technik besteht darin, den Fokus auf Outcome zu verstärken (messbare Veränderungen im Nutzerverhalten statt nur Unternehmenserfolg) sowie die Herausforderungen in der Zusammenarbeit im Unternehmen zu berücksichtigen. Kein Produkt wird alleine vom Produktteam gemacht – auch Legal, Finance, Marketing etc. sind eingebunden.

Gerade bei größeren Unternehmen ist das entscheidend. Ich möchte, dass Teams das als Teil des Prozesses früh durchdenken: Man ist nie alleine, der Erfolg hängt auch an Zusammenarbeit über Abteilungsgrenzen hinweg.

Ben Aston:

Das ist extrem wichtig – oft scheitert es nicht am Ziel, sondern am Prozess zur Zielerreichung, besonders bei Kommunikation und Zusammenarbeit. Schauen Sie sich unbedingt Jeffs Artikel zum „Rückwärts arbeiten, um vorwärts zu kommen“ an!

Jetzt würde ich gerne noch zum Prozess-Thema wechseln. Du hast in Beratung, Startups und Agenturen gearbeitet und bist jetzt selbstständig. Dadurch hast du viele funktionierende und nicht funktionierende Prozesse gesehen. Wie beobachtest du die Entwicklung von Methoden wie Lean, Agile, Design Thinking, Service Design etc.? Was siehst du für deren Zukunft?

Jeff Gothelf:

Ich glaube, irgendwann wird Agilität (kleines „a“!) der Standard in Unternehmen weltweit sein. Die Pandemie beschleunigt das. Organisationen, die bereits agil sind, werden überleben – andere werden leiden oder scheitern.

Denn die Veränderungsgeschwindigkeit in Märkten und Welt nimmt ständig zu. Wer als Monolith agiert, wird untergehen. Wer aber als Gruppe von halb-autonomen Teams agiert, die fortlaufend lernen, austauschen und den Kurs anpassen, kann auch in Krisensituationen bestehen.

Ob wir in 20 Jahren noch von Sprints, Velocity und Backlogs sprechen, weiß ich nicht – vielleicht ändern sich Labels und Begriffe. Aber dass Kundenzentrierung, fortlaufendes Lernen und kontinuierliche Verbesserungen Standard werden, ist meiner Ansicht nach unausweichlich. Das sind die Kernphilosophien von Agile und Agilität.

Ben Aston:

Was hältst du von verschiedenen Methodiken – müssen wir alle Techniken kennen und wie gut funktionieren sie im Zusammenspiel? Hast du eine Meinung zu agilem Entwickeln vs. Design Thinking?

Jeff Gothelf:

Dazu habe ich ein Buch geschrieben: „Lean vs Agile vs Design Thinking“. Kernaussage: Alles verschiedene Marken auf den gleichen Grundphilosophien. Namen und Abläufe sind unterschiedlich, aber das Grundprinzip ist eines.

Man sollte einen Ansatz wählen oder mixen und daran anpassen, was für das eigene Unternehmen funktioniert. Wichtig ist nicht die Methode, sondern, dass die Organisation agiler wird. Ziel ist, nicht blind nach Rezept zu handeln, sondern wie ein Koch, der erst nach Rezept, dann nach Gefühl, dann improvisierend arbeitet.

Anfangs nimmt man ein Rezept, dann verbessert man es, dann schmeißt man die Rezepte weg und wird zum Profi, der überall flexibel erfolgreich agieren kann. Organisationen, die streng an einem Rezept festhalten, tun sich schwer – denn sie sagen nur: „Befolge die Schritte, dann ist schon alles gut!“ Aber das Ziel muss sein, tatsächlich agil zu werden, nicht ein Rezept zu erfüllen.

Ben Aston:

Ich denke auch, wenn Leute sagen: „So macht man das nicht, das steht doch so im Buch!“, ist Vorsicht geboten. Der Prozess selbst kann weiterentwickelt werden, nicht umgekehrt. Es ist wichtiger, die Zielerreichung im Blick zu behalten, statt auf einen festen Prozess zu bestehen.

Du hast das Buch „Sense and Respond“ über das Zuhören auf Kunden und die Entwicklung neuer Produkte geschrieben. Gibt es Techniken, die wir noch nicht besprochen haben, die Organisationen zum Erfolg führen, vor allem in dieser COVID-Welt?

Jeff Gothelf:

Der wichtigste, aber oft zuletzt angegangene Aspekt ist das Anreizsystem und die Leistungsbewertung. Am Ende des Tages: Wenn ich fürs Liefern eines Features bezahlt werde, produziere ich Features – egal ob agile, lean, design thinking oder waterfall. Entscheidend ist, wie der Erfolg gemessen wird und wie das gewünschte Verhalten (Neugier, Lernen, Verbesserungen) incentiviert wird.

Wenn das nicht geschieht, bleibt Agilität auf der Strecke. Es ist viel Arbeit, aber sie lohnt sich – das Ergebnis sind bessere Produkte, glücklichere Kunden und erfolgreichere Mitarbeiter.

Ben Aston:

Beziehst du dich dabei auf OKRs (Objectives and Key Results) oder allgemein?

Jeff Gothelf:

Ja, die Kopplung der Anreize an OKRs, das Team wird an deren Erfolg und Umsetzung gemessen. Das ist ein wichtiger Bestandteil bei der Beurteilung und Förderung.

Ben Aston:

Ich habe neulich gesehen: Statt Stellenbeschreibungen Job-Scorecards verwenden – eine gute Methode, um Verantwortlichkeiten bis auf Einzelpersonen zu messen und zu incentivieren. Die Wahl und Formulierung der passenden Metriken ist jedoch manchmal herausfordernd, da sich später zeigt, dass ein gewählter Messwert falsch war und falsche Energien erzeugt hat. Doch der Fokus auf Ergebnisse und Outcome ist entscheidend! Lass uns abschließend noch über deinen Scrum-Kurs sprechen. Dort geht es um die Einbindung von Design/UX in Scrum – ein Problem vieler Agenturen. Wie kann man strategisches UX-Design sinnvoll integrieren?

Ben Aston:

Kannst du kurz erklären, wie das Zusammenspiel funktioniert? Das ist eine der größten Herausforderungen in Agenturen bei der Scrum-Einführung.

Jeff Gothelf:

Genau diese Herausforderung adressiert der PSU-Kurs von scrum.org (Professional Scrum with UX). Wir nehmen Scrum und zeigen ganz konkret und pragmatisch, wie Scrum verändert werden muss, um UX/Design-Praktiken zu integrieren, die beim Entstehen von Scrum nicht vorgesehen waren, die heute aber essenziell sind.

Wie kommt Arbeit ins Backlog, wie schreibt man Stories, wer macht was, wann passiert was? Was ist mit dem Verhältnis zwischen Lernarbeit (Discovery) und Lieferarbeit? All diese Fragen behandelt der Kurs. Das Wesentliche ist: cross-funktionale Zusammenarbeit. Designer müssen Teil des Teams sein, Discovery-Arbeit ist ebenso wichtig wie Delivery und manchmal übernimmt Discovery auch das Entwicklerteam. Das muss das Team akzeptieren können.

Ben Aston:

Meine Kritik an Scrum ist oft, dass es sehr vorschreibend ist. Klar, Frameworks sind Ausgangspunkte, aber wie war deine Erfahrung beim Entwickeln des Kurses – den Spagat zwischen Vorgaben und Flexibilität zu gestalten?

Jeff Gothelf:

scrum.org war bereit, ihre Position zu überdenken. Bei anderen Organisationen war meist die starre Haltung ein Problem („Das ist Scrum, Punkt.“). Der Kurs ist ein Rezept – ideal für den Einstieg. Wer noch mit Scrum kämpft, startet nach Rezept, passt es dann immer mehr auf die realen Gegebenheiten an. Aber das Start-Rezept funktioniert aus unserer Sicht als Ausgangspunkt ziemlich gut.

Ben Aston:

Das ist hilfreich: Wer nach Agilität sucht, sollte wissen – Frameworks sind Rezepte, kein Gesetz. Entscheidend ist nicht die Einhaltung, sondern die Zielerreichung. Das war das Thema heute. Vielen Dank, Jeff, dass du dabei warst.

Jeff Gothelf:

Sehr gerne, Ben. Es war mir eine Freude.

Ben Aston:

Mich interessiert, was denken Sie? Haben Sie Tipps, Hacks, Erfahrungen mit Erfolg oder auch Misserfolg? Haben Sie schon die Press-Release-Technik ausprobiert? Schreiben Sie es gerne in die Kommentare.

Wer mehr lernen will, kommt in die DPM-Community: thedigitalprojectmanager.com/membership – Zugang zu Slack-Team, Vorlagen, Workshops, AMA-Sessions, Office Hours, E-Books und mehr. Wenn Ihnen der Podcast gefallen hat, abonnieren Sie uns auf thedigitalprojectmanager.com. Bis zum nächsten Mal – danke fürs Zuhören.