Agilität erfolgreich umsetzen mit Metagilität (mit David Bishop von Agile Worx)

Lesen Sie das Transkript:

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

Ben Aston: Lassen Sie mich raten, Sie haben zuerst nach dem Wasserfallmodell gearbeitet, was nicht funktionierte, und dann haben Sie es mit Agilität versucht und… nun, das funktioniert auch nicht so richtig.

Jetzt mischen und kombinieren Sie Methoden. Sie haben ein bisschen Agilität kombiniert mit Wasserfall und suchen nach den letzten Streuseln, die noch fehlen. Bleiben Sie dran bei unserem aktuellen Podcast über Metagilität. Sie könnten ein oder zwei Dinge darüber lernen, wie ein agiles Playbook genutzt werden kann, um das Beste aus beiden Welten zu vereinen.

Danke, dass Sie eingeschaltet haben. Ich bin Ben Aston, Gründer des Digital Project Manager. Willkommen beim DPM-Podcast. Unsere Mission ist es, Projektmanager:innen zum Erfolg zu verhelfen – wir unterstützen Menschen, die Projekte managen, damit diese noch besser führen und umsetzen können. Wir helfen Ihnen, Ihr Projektmanagement auf das nächste Level zu bringen. Schauen Sie auf thedigitalprojectmanager.com vorbei, um mehr über unsere Trainings und Ressourcen im Rahmen der Mitgliedschaft zu erfahren. Dieser Podcast wird präsentiert von Clarizen, dem Marktführer für Enterprise Project und Portfolio Management Software. Erfahren Sie mehr unter Clarizen.com.

Heute begrüße ich David Bishop. Dr. David Bishop ist ein Technologe, Berater, Forschungsunternehmer und Dozent mit über 25 Jahren Erfahrung in den Bereichen Telekommunikation, Transport, öffentliche Verwaltung und Versorgungsunternehmen. Er ist CEO und Gründer von Agile Worx, LLC. Weitere Informationen finden Sie auf Agile-worx.com. Dieses Unternehmen bietet Tools für Programm- und Projektmanagement, Schulungen und Beratungsdienste. Außerdem ist David Bishop der Autor von Metagility: Managing Agile Development for Competitive Advantage. Vielen Dank, dass Sie heute bei uns sind, David.

David Bishop: Danke, dass Sie mich eingeladen haben.

Ben Aston: Ich möchte mit Ihnen darüber sprechen, wie man aus dem Nichts einen Rahmen aufbaut. Erzählen Sie uns etwas über Ihren Hintergrund und wie Sie zu dem Entschluss gekommen sind, dass die Welt ein neues Framework braucht. Was war Ihr Werdegang, Ihre Erfahrung, die Sie zu diesem Punkt brachte?

David Bishop: Richtig. Ich bin nun seit etwa 25 Jahren im Bereich Technologientwicklung tätig und war die meiste Zeit Systemarchitekt und Systemingenieur, habe Lösungen mit neuen Technologien entwickelt – sowohl in der IT, wie auch in der Flugindustrie, im Mobilfunk und in der Telekommunikation. Wie Sie schon erwähnt haben, habe ich vor etwa zehn Jahren bei einer Firma gearbeitet, die sehr stark im Bereich Industrial IoT aktiv war. Eines der großen Themen war dort die Umsetzung agiler Methoden.

Ben Aston: Richtig.

David Bishop: Der Grund dafür lag darin, dass die Kunden dies forderten. Sie wollten nicht nur mit neuer Technologie, sondern auch mit den angesagten Methoden arbeiten. Es war nicht die Branche selbst neu, aber die Technologie war neu. Sie versuchten, diese Technologie zu integrieren. Es gab viele Wettbewerber, die smarte Grid-Technologien und unterschiedliche Funkkommunikationssysteme entwickelten.

Diese technologische Basis sorgte für die Herausforderungen. Sie versuchten mehrfach, agile Methoden zu übernehmen, weil es aus ihrer Sicht entscheidend war, die Produkte so schnell wie möglich auf den Markt zu bringen. Trotz vieler Anläufe und teurer Berater scheiterten sie immer wieder. Ich habe die Produktentwicklung begleitet und auch versucht, im Unternehmen die Agilität einzuführen, dachte mir aber: Da muss es doch einen anderen Weg geben.

Wieso haben so viele schlaue Berater bei der Umsetzung solcher Herausforderungen Probleme? Mir wurde klar, dass Agilität zwar sehr erfolgreich war und gute Ideen mitbrachte, aber auch gewisse Schwächen hat. Zum Beispiel bei verteilten Teams, großen Teams oder sehr komplexen Entwicklungsumgebungen und komplizierten Produkten. Gerade solche Herausforderungen sind für Unternehmen, die reine agile Methoden übernehmen möchten, riesig.

Ben Aston: Definitiv. Berichten Sie etwas von Ihrer Praxiserfahrung. Mich interessiert, wie sich die alltäglichen Herausforderungen beim Versuch der agilen Transformation auf den Projektalltag auswirkten. Was waren die Warnsignale dafür, dass etwas nicht passte?

David Bishop: Es gab einen enormen Widerstand in manchen Teams. Das war kein „Och nö, jetzt schon wieder etwas Neues“ – es war wirklich ernsthafter Widerstand. Viele beschwerten sich, dass der Prozess nicht funktioniere und auch nicht funktionieren könne. Das Problem: Es handelte sich um Embedded Systems – das heißt, die entwickelten IoT-Produkte waren nicht nur Software, sondern echte Geräte. Geräte bestehen in der Regel aus Embedded-Systems-Bestandteilen: Hardware, Firmware und Software, erarbeitet von verschiedenen Teams, teils auch anderen Abteilungen oder Firmen.

Doch irgendwann müssen diese drei Komponenten als ein fertiges Produkt getestet und ausgeliefert werden. Genau das tat dieses Unternehmen – und deshalb ist der Kontext hier so interessant: Genau in diesen Bereichen findet heute Innovation statt. Früher, als das Agile Manifest veröffentlicht wurde, vor 15, 20 Jahren, ging es nur um Software. Aber heute handelt es sich nicht mehr nur um Software.

Es geht um Geräte: Smart Devices, Smart Meter, Smart Cars, Ihr Smartphone – alles sind im Grunde Embedded Systems Geräte. Unternehmen, die solche Produkte entwickeln, haben besonders große Probleme mit Agilität – wegen der Komplexität. Praktisch bedeutete das: Die Berater, mit denen wir arbeiteten, sagten: „Gut, eure Software-Teams machen Zwei-Wochen-Sprints und tägliche Stand-ups – aber wir kriegen die Hardware-Teams nicht dazu, das zu machen. Sie sehen die Notwendigkeit nicht.“

Ben Aston: Richtig.

David Bishop: Und bei den Firmware-Teams war es ähnlich: Auch sie hatten das Gefühl, dass die Methode für sie nicht gut funktioniert. Tatsächlich arbeiteten die Software-Teams viel schneller, sie konnten iterativ entwickeln. Bei den Hardware-Teams aber passte das überhaupt nicht, ihre Produkte hatten Lebens- und Releasezyklen von 12 bis 18 Monaten.

Es dauert einfach viel länger, einen Chip auf der Hardware zu implementieren und ausführlich zu testen. Und denken Sie daran: Die meisten Unternehmen, die Embedded Systems entwickeln, sind in Branchen tätig, die streng reguliert sind, z. B. Versorgungsunternehmen oder Luftfahrt. Die Risiken sind hier viel größer – potenziell geht es um Menschenleben oder katastrophale Ausfälle. Die Anforderungen an Qualität und Performance sind deutlich höher als bei typischen Software-Anwendungen oder E-Commerce-Webseiten.

Ben Aston: Genau.

David Bishop: Und das waren genau die Branchen, die agile Methoden am frühesten und konsequentesten aufgenommen haben.

Ben Aston: Wenn Sie mehr über die Entstehung der Metagilität erfahren möchten, lesen Sie den Beitrag auf thedigitalprojectmanager.com. Dort erzählt er die Entwicklungsgeschichte des Buches. Anstatt darüber weiter ins Detail zu gehen, möchte ich mit Ihnen über das eigentliche Framework sprechen und sehen, wie wir Erkenntnisse auf unsere Projekte übertragen können. Viele von uns haben Wasserfall-Ansätze ausprobiert.

Wir arbeiten sequenziell, weil das für Stakeholder und Projektstrukturen oft am sinnvollsten ist. Aber gleichzeitig bringen wir agile Elemente ein, arbeiten kollaborativ und iterativ. Wir greifen verschiedene Methoden auf, leben die Philosophie: Lasst uns iterieren, oft Wert liefern.

Wir bauen, testen, lernen. Aber letztlich müssen wir oft doch sequentiell arbeiten. Ich möchte über Metagilität sprechen und wie wir das auf unsere Projekte anwenden können. Die Realität ist: Agile Methoden sind weit verbreitet und als beste Lösung für Softwareentwicklung anerkannt – aber was agile Methoden wirklich bedeuten, das bleibt Interpretationssache.

Und wie besprochen, ist das eine echte Herausforderung. Der hybride Ansatz gilt zwar selten als beste Lösung, ist aber faktisch das Ergebnis für viele, die versuchen, unterschiedliche Frameworks mit den spezifischen Gegebenheiten ihres Unternehmens zu vereinen. Hardwareschritte dauern länger als Software, Middleware liegt irgendwo dazwischen.

Alles gleichzeitig zu veröffentlichen, ist eine Herausforderung. Wie beim Web-Development: UX und Design gehen schnell, Entwicklung benötigt viel mehr Zeit. Reden wir also über Ihre Erfahrungen mit Leistungsfähigkeit und die Grenzen agiler Methoden, wie Sie sie im Buch beschreiben.

Wo sehen Sie die Einschränkungen der heutigen agilen Frameworks? Vergleichen Sie sie mit Methoden wie Scrum auf taktischer Ebene und Frameworks wie SAFe auf hoher Ebene.

David Bishop: Wenn man über Frameworks wie Scrum, Kanban, DSDM, LeSS oder zum Beispiel Disciplined Agile spricht – das wurde kürzlich von PMI aufgekauft, das wird interessant sein zu beobachten.

Ben Aston: Ja, ich kaufe kein Framework. Das ist interessant.

David Bishop: Sie gehen das Problem von verschiedenen Seiten an. Viele wollen agile Methoden einführen, weil sie glauben, dass Teams dann besser zusammenarbeiten, Führungskräfte besser werden oder die Effizienz steigt – und das ist ja alles gut. Aber der eigentliche Zweck von Agilität ist Wettbewerb. Es geht darum, Nummer Eins im Markt zu werden. Das Agile Manifest ist direkt aus dem Lean Manufacturing Ansatz entstanden – der Toyota Produktionssystem-Ansatz. Damals wurde Toyota vom Blechdosenhersteller zum besten Automobilhersteller der Welt.

Die Idee der Agilität ist, diesen Erfolg zu wiederholen – Marktführer zu werden. Manche Frameworks, wie SAFE, sind sehr unternehmensfokussiert und versuchen jede Abteilung zu „agilisieren“ – von Personal bis Rechtsabteilung. Die Hoffnung ist, dass so inkrementelle Verbesserungen erzielt werden, aber ich sehe dort oft eine Überfokussierung auf Prozesse und eine Rückkehr zu alten, seitenlangen Dokumentationen früherer Zeiten…

Ben Aston: Genau.

David Bishop: Metagilität dagegen – Scrum etwa fokussiert sich auf Teamebene, es gibt verschiedene Rituale für Teams. Die Frameworks ergänzen einander: Sie können Scrum, Kanban, Metagilität und SAFE parallel im Unternehmen verwenden. Was Metagilität besonders macht: SCRUM arbeitet auf der Team-Ebene, Kanban auf Prozessebene. Metagilität legt den Fokus auf das Produktentwicklungssystem – also Produkt- und Projektmanagement, Entwicklungs- und Testteams und deren Zusammenarbeit mit dem Kunden, sodass das Produkt dessen Erwartungen erfüllt und maximale Qualität erzielt wird.

Wenn Sie ein Rennen gewinnen wollen, konzentrieren Sie sich auf Motor, Getriebe und Antrieb – nicht auf elektrische Fensterheber. Viele Frameworks kümmern sich zu sehr um Randbereiche, anstatt das fokussiert zu optimieren, was wirklich entscheidend ist, um Marktführer zu werden.

Metagilität bündelt das, was Unternehmen richtig gemacht haben, die es an die Spitze geschafft haben – und macht es für andere reproduzierbar.

Ben Aston: Sie beschreiben es als umfassenden Ansatz, um eine effektive Identität zu managen. Ist Metagilität ein Lieferframework, eine Methodik, ein Playbook? Wie beschreiben Sie es?

David Bishop: Ich würde es als Framework bezeichnen. Es führt Sie durch den Prozess – etwa zu Beginn: Metagilität beginnt damit, zu bestimmen, welche Art von agiler Anpassung Sie möchten. Bevor man dorthin kommt, hilft das Buch auch, ein neues, forschungs- und wissenschaftsbasiertes Denken für Geschäftsentscheidungen zu entwickeln. Ein Abschnitt widmet sich der Veränderung des agilen Manifests durch Forschungsergebnisse.

Wenn Sie dann zur agilen Transformation kommen: Als Erstes wird behandelt, welche Art von agiler Umsetzung sinnvoll ist. Sollte es eine reine agile Lösung sein, ein hybrider Ansatz, oder vielleicht sogar weiter nach dem Wasserfallmodell? Es gibt dazu viele (peer-reviewte) Studien auf Führungsebene, die diese Entscheidungen wissenschaftlich begründet unterstützen, etwa von Barlow – dessen Diagramm auch im Buch enthalten ist. Dort wird die Agile-Umsetzung als Funktion der Komplexität von Abhängigkeiten und der Teamgröße beschrieben. Das ist essenziell.

Gerade bei komplexen Produkten und großen, verteilten Teams mit starker Interaktion und Abhängigkeiten funktioniert eine reine agile Umsetzung meist nicht, sondern erfordert einen gezielten hybriden Ansatz. Hybrid-Ansätze sind in der Branche oft negativ belegt, weil da häufig gescheiterte Transformationen darunterfallen – aber ein bewusst geplanter, wissenschaftlich begründeter hybrider Ansatz kann hervorragende Ergebnisse liefern.

Ben Aston: Können Sie das Framework für die, die das Buch nicht gelesen haben, beschreiben: Wie funktioniert es – welche Bausteine beinhaltet es?

David Bishop: Im Buch gibt es eine große Übersichtstafel, aber im Kern geht es um Folgendes: Teil eins ist die Entscheidung, welchen Ansatz (Transformation) man wählen sollte.

Ben Aston: Wie wird diese Entscheidung getroffen?

David Bishop: Mit dem erwähnten Barlow-Diagramm im Buch. Das bedeutet: Die Teamgröße sowie die Komplexität von Produkten und der Grad der Abhängigkeiten sind entscheidend. Sie müssen also herausfinden, wie viele Interdependenzen und Abhängigkeiten zwischen Teams, Entwicklungssträngen etc. bestehen. Daraus ergibt sich, ob ein hybrider Ansatz notwendig ist oder eine rein agile Methode noch greift.

Metagilität beschreibt, wie man das „hybride“ umsetzt: Beispielsweise haben Softwareteams Zwei-Wochen-Sprints und tägliche Stand-ups, Firmwareteams Dreißigtage-Sprints und wöchentliche Stand-ups, Hardwareteams mit langen Zyklen (12–18 Monate) eventuell keine Sprints, nutzen aber Methoden wie Rapid Prototyping, um den anderen Teams regelmäßig Entwicklungsplattformen oder Testgrundlagen zu liefern. Das Ziel ist stets: den Projektfluss aufrecht erhalten.

Metagilität beschreibt zudem, wie Teams agile und Wasserfall-Elemente kombinieren, z. B. durch Übernahme der Stage-Gates als Kontrollmechanismen in der hybriden Methodik für Teams mit unterschiedlich schnellen Zyklen.

Zusätzlich werden im Buch Messgrößen, Interaktionsarten und deren Anwendung beschrieben – basierend auf erfolgreichen Fallstudien. Metagilität ist also ein detailliertes Playbook zur Steuerung und Umsetzung hybrider, agiler Implementierungen.

Ben Aston: Wie bestimmt man die richtige Kombination agiler Praktiken? Veränderungen werden ja oft negativ gesehen – wie findet man also den besten Mix, wann ist Status quo ausreichend, wann ist Evolution/Revolution nötig?

David Bishop: Hier hilft die wissenschaftliche Methodik und forschungsbasierte Begleitung. Häufig werden Lösungen aus Intuition, Best Practices oder durch Konsensfindung getroffen – das funktioniert bis zu einem gewissen Punkt. Bei komplexen Transformationen wie Agile, DevOps, Digital geht das nicht. Dort braucht es „stärkere Medizin“, also wissenschaftliche Methoden, wie interpretative Fallstudien oder Ethnografien, um Kontextübergreifendes zu destillieren. So lässt sich erkennen, was verallgemeinerbar ist und tatsächlich funktioniert. Das dauert, ist aber effektiver.

Ben Aston: Das Framework ist also kein Einheitsprodukt, sondern individuell anpassbar. Wie bewertet man überhaupt, ob eine Umsetzung wirklich Metagilität ist und erfolgreich war?

David Bishop: Gute Frage, darauf geht das Konzept der Agilen Vortizität ein – das ist im Buch ausführlich beschrieben und aus qualitativer Grundlagenforschung entstanden. Agilitätsvortizität beantwortet die Frage: Wie agil ist eine Organisation wirklich? Damit lässt sich messen, wo ein Unternehmen steht, was besser wird und wie. Das war lange die große Lücke in der Branche, die Metagilität schließt, indem sie Erfolg messbar macht.

Ben Aston: Was haben Sie bei Unternehmen beobachtet, die Ihr Framework eingeführt haben? Welche Auswirkungen waren messbar, insbesondere in Bezug auf Marktführerschaft und Wettbewerbsfähigkeit?

David Bishop: Unsere Fallstudien stammen meist aus dem Embedded-Systems-Markt – dem innovativsten, aber auch anspruchsvollsten Bereich. Firmen, die Metagilitäts-Konzepte übernommen haben, wurden dort meist Marktführer oder kamen sehr nah heran. Das zeigt sich meist in größerem Marktanteil, mehr ausgelieferten Geräten und einer schnelleren Innovationsrate. Der Schlüssel ist, durch die frühzeitige Markteinführung innovativer Produkte einen entscheidenden Vorsprung zu sichern. Agile Umsetzung, speziell Metagilität, hilft, Entwicklungszyklen zu verkürzen – bei konstant hoher Qualität und Kundenzufriedenheit.

Ben Aston: Wo hat Metagilität nicht funktioniert? Wo gibt es Stolpersteine?

David Bishop: Das liegt meist an zwei Faktoren. Erstens: Fehlt die Unterstützung des Managements, bleibt der Erfolg aus. Transformationen müssen von oben gewollt und getragen werden. Entscheidend ist, dass ein überzeugender Business Case präsentiert wird, damit die Führung versteht, worum es wirklich geht: Wettbewerb und Profitabilität, nicht bloß Motivation oder ein „Wohlfühlklima“.

Zweitens: Schwache Anforderungsanalyse. Bei agilen Transformationen liegt der Fokus oft zu sehr auf Entwicklung und Test, weniger auf die Rolle der Business Analysts (also Product Owner im agilen Kontext) und deren Arbeit. Der Wandel von Anforderungen im Wasserfall zu agilen Anforderungen wird häufig nicht vollzogen. Viele „sammeln“ Anforderungen wie zuvor, anstatt gemeinsam mit dem Kunden iterative Anforderungen zu entwickeln. Die Folge: Übervolle Backlogs, nicht priorisierbare Anforderungen, riesige technische Schulden und ein Misserfolg der Transformation.

Ben Aston: Ich habe das schon oft erlebt – Anforderungen sammeln kann sich endlos hinziehen. Wenn man neu in Metagilität ist: Was wäre der erste konkrete Schritt für ein Unternehmen, das Metagilität nutzbringend anwenden möchte?

David Bishop: Der wichtigste Schritt ist, neue Kundenbeziehungen aufzubauen. Im Agile Manifest heißt es schon: Zusammenarbeit mit Kund:innen steht über Vertragsverhandlungen. Aber, wie wir heute wissen, sind Vertrags- und Kooperationsverhandlungen ein und derselbe Prozess – und sie finden auf allen Organisationsebenen statt: Zwischen Produktmanager/innen, Product Ownern, Projektmanager/innen, Entwicklungsteams und vielen Stakeholdern im Kundenunternehmen. Sie müssen eine kollaborative Beziehung etablieren, damit der Kunde am Testen und Gestalten neuer Innovationen teilnimmt. Und: Es zählt weniger ein Plan, als vielmehr eine Vision. Erfolgreiche Unternehmen wussten, mit wem sie diesen Weg gemeinsam gehen – und lehnten auch Kunden ab, die diese Zusammenarbeit nicht wollten. Diese vertrauensvolle Beziehung entscheidet über dauerhaften Erfolg.

Ben Aston: Sehr weise Worte. Wenn wir wirklich Wert für Kund:innen liefern wollen, brauchen wir auch ein Zusammenarbeitsmodell und gegenseitiges Vertrauen, um dieses iterative Miteinander zu ermöglichen. Vielen Dank, David, für das Gespräch über Metagilität.

David Bishop: Herzlichen Dank.

Ben Aston: Ich freue mich auf Ihr Feedback – haben Sie das Buch Metagilität gelesen? Schreiben Sie gerne einen Kommentar. Falls nicht: Den Link finden Sie im Transkript. David, wo kann man mehr über Metagilität und Ihr Buch erfahren?

David Bishop: Sie können einfach „Metagilität“ googeln, da gibt es viele Ressourcen. Oder besuchen Sie Agileworx.com (Agile-worx.com) – dort finden Sie Infos zu unserem Unternehmen, zu unseren Kursen (aktuell aufgrund der Umstände als virtuelle Kurse ab August bis November). Den aktuellen Kursplan und Infos gibt’s unter metagility.technology, sowie Kontakt zu mir direkt per E-Mail: David@agileworx.com (Agile-worx.com). Ich freue mich immer, von Interessierten zu hören.

Ben Aston: Vielen Dank, David! Wenn Sie sich weiterentwickeln möchten, werden Sie Mitglied bei DPM. Gehen Sie auf thedigitalprojectmanager.com/membership – dort gibt es Zugang zu unserem Slack-Team, Vorlagen, Workshops, AMA-Sessions, E-Books und mehr. Wenn Ihnen dieser Podcast gefallen hat, abonnieren Sie uns auf thedigitalprojectmanager.com. Bis zum nächsten Mal und danke fürs Zuhören.