Missionsgetriebene Entwicklung

Wenn Unternehmen wachsen, wird die Skalierung der agilen Produktentwicklung schwieriger. Laut 52 % der Befragten im 13. State of the Agile Report sind die Unterschiede zwischen der Unternehmenskultur und den agilen Werten der Hauptnachteil ihrer Arbeit.

Unternehmensleiter sind in der Lage, die agile Kultur zu nutzen, um die Produktentwicklung zu verbessern. Eine robuste agile Kultur beinhaltet Teamautonomie bei der Herangehensweise an komplexe Probleme, enge Zusammenarbeit mit Kunden sowie langfristige Visionen und Strategien.

Diese abstrakten Werte sind schwer einzuschätzen und zu berücksichtigen. In einer Organisation wird die Implementierung einer effektiven Strategie zur Nutzung dieser Werte zu einer nicht trivialen Aufgabe. Der Mission Driven Development (MDD)-Ansatz hat sich von Mid-Stage-Startups als Alternative zum Aufbau einer solchen Kultur entwickelt.

Skalierungsherausforderungen

Beim Skalieren können mehrere Verlangsamungsmuster entstehen. Bei Projekten mit unklarem Ende kann die Teammotivation sinken. Produktmanager können sich in operativen Besprechungen verloren fühlen und verlieren so Zeit, um strategische Produktpfade zu entwerfen. Die Bereitstellung neuer Funktionen und Produkte kann sich verlangsamen, wenn die Systeme immer komplexer werden.

Diese Barrieren sollten aus kultureller und praktischer Perspektive angegangen werden. Um sie zu überwinden, müssen Sie die Kontrolle abgeben, die Autonomie des Teams steigern, radikale Transparenz implementieren und einen effizienten Rahmen für die Produktentwicklung einrichten, um Ergebnisse zu erzielen.

Herausforderungen bei der Skalierung traditioneller agiler Frameworks

Bei der Skalierung von Agile müssen Management- und Teamebene synchronisiert werden. Die Führungsebene ist verantwortlich für die Entwicklung der Unternehmensstrategie, die Erstellung und Kommunikation der Produktvision, die Umsetzung von Personalentscheidungen und die Förderung der Teamentwicklung. Die Teamebene führt die notwendigen Aufgaben aus, um diese Vision und Strategie effizient in wertvolle Produkte und Funktionen umzusetzen.

Herkömmliche Agile-Frameworks (XP, Scrum und Kanban) sind für den Betrieb auf Teamebene optimiert und lassen Managementbeziehungen weitgehend unberücksichtigt. Eine neue Welle skalierter agiler Frameworks wurde entwickelt, um diese Lücke zu schließen, dh SAFe, LeSS, Scrum of Scrums, Nexus, DAD usw. Diese Ansätze erfordern jedoch viel Planung für die Implementierung und Aufwand für Verwaltung und Wartung.

Das Mission Driven Development Framework ist ein leichtgewichtiger Ansatz, der genügend Richtlinien bietet, um eine robuste Struktur zur Skalierung der Entwicklung und zur Nutzung agiler Werte zu implementieren.

Kernelemente der Mission Driven Development

Missionen

Ausgangspunkt ist Mission Discovery. Eine Geschäftsmission erfordert Zeit und Mühe und sollte ein latentes Problem, einen Lösungsraum und das gewünschte Geschäftsergebnis identifizieren. Wenn eine Mission genau definiert ist, fördert sie die Motivation, fördert die Zusammenarbeit und fördert die Forschung in breiteren Designräumen.

Trupps

Die verantwortlichen Akteure für den Erfolg jeder Mission sind Trupps. In Zusammenarbeit mit Produktmanagern führen kleine Teams von 2-4 Personen die notwendigen Aktivitäten durch, um Lösungen zu liefern, die dem Missionsziel und den Zeitbeschränkungen entsprechen.

6-Wochen-Zyklus

Die 6-wöchige Timebox ermöglicht es allen Trupps, denselben Zeitplan für die Basisplanung einzuhalten und gleichzeitig genügend Zeit zu haben, um ein aussagekräftiges Ergebnis zu erzielen.

Pufferzeit

Das MDD-Framework umfasst üblicherweise unter anderem eine ein- oder zweiwöchige Pufferperiode für endgültige Integrationen und Bereitstellungen, Schulungen und Kompetenzentwicklung, Innovationsaktivitäten und die Planung des nächsten Zyklus.

Die Bedeutung des 6-Wochen-Zyklus

Auch wenn der Zeitraum von sechs Wochen für einige Agile Praktiker viel erscheinen mag, bietet er mehrere wichtige Vorteile.

Teams, die in kurzen Zyklen arbeiten, neigen dazu, das Engagement für die Produktvision zu verlieren, da sie das Gefühl haben, eine „Wäscheliste“ mit Korrekturen, Fehlern und kleinen Funktionen abzuhaken. Dies gefährdet die Autonomie der Teams, den besten Weg zur Bereitstellung von Lösungen zu finden und auszuwählen.

Wenn die Zyklen länger werden, nimmt die Genauigkeit der Produktschätzung ab. Infolgedessen erfordert es einen hohen Planungsaufwand für die Produktteams.

Sechs Wochen wurden als Goldlöckchen der Produktzeiträume bezeichnet und bieten genügend Zeit, um durch innovatives Denken, schnelles Prototyping und kontinuierliche Lieferung ein Minimum Viable Product zu liefern.

Der 6-Wochen-Zyklus verbessert das Engagement der Teamvision weiter, indem er die Autonomie nutzt. Mikromanagement ist nicht notwendig, solange die Missionen klar formuliert sind und die Zyklen kurz genug sind, damit sich die Teams nur auf die gewünschten Ergebnisse konzentrieren können.

Schließlich können sich Produktmanager alle sechs Wochen an Planungsaktivitäten beteiligen und so genügend Vorhersagbarkeit für Teams bewahren, um auf dem Weg zur Mission zu bleiben. Dadurch kann mehr Zeit auf die strategischen und explorativen Dimensionen der Produktentwicklung konzentriert werden.

Implementierung von Mission Driven Development

Nehmen wir zum Beispiel ein Mid-Stage-Startup, das ein B2B-Produkt hat, das eine Netzwerkpreisoptimierung anbietet, die den Kundenumsatz durch den Einsatz von Anwendungen mit künstlicher Intelligenz steigert. Das Unternehmen hat kürzlich eine neue Finanzierungsrunde unterzeichnet, mit dem Ziel, sich als relevanter Branchenakteur zu festigen und den Marktanteil um 300 % zu steigern.

In diesem Szenario gibt es mehrere Herausforderungen bei der Produktentwicklung:

• Wie kann Feedback von aktuellen und potenziellen Kunden eingeholt werden, um die ausstehende Werthypothese zu validieren?
• Welche Funktionen sollten für eine überzeugende Benutzererfahrung auf der Plattform erstellt oder entfernt werden?
• Wie kann die Managementstruktur eingerichtet werden, um die Skalierung zu bewältigen und kulturelle Werte zu nutzen, um das Wachstum zu beschleunigen?

Um komplexe Frameworks zu vermeiden, entscheidet sich das Unternehmen schließlich für die Anwendung des Mission Driven Development-Frameworks. Bei Mission Driven Development werden die Details der „letzten Meile“ von jeder Organisation definiert. Die wichtigsten zu definierenden Elemente sind:

• Missionsentdeckung
• Missionsstruktur
• Squad-Montage
• Inspektion und Anpassung
• Pufferiteration
• Kapazitätsplanung

Mission Entdeckung

Ausgangspunkt ist Mission Discovery. Tim Herbig beschreibt Entdeckung als den iterativen Prozess der Verringerung der Unsicherheit in Bezug auf ein Problem oder eine Idee, um sicherzustellen, dass das richtige Produkt für die richtige Zielgruppe entwickelt wird. Bevor eine Mission in einem Iterationszyklus begangen wird, sollte sie so umfassend wie möglich validiert werden.

Der Mission Discovery-Prozess wird von speziell zugewiesenen Teams durchgeführt. Das Discovery-Team wird vom Produktmanager geleitet und besteht aus Produktforschern, Business-Analysten und Designern. Wenn es mehrere Produktmanager gibt, berichten sie an den Chief Product Officer (CPO), der eine gemeinsame Vision über alle Produkte, die Eignung der Produkte und die globale Unternehmensstrategie sowie die rechtzeitige Lieferung sicherstellt.

Der empfohlene Ausgangspunkt für die Missionsfindung sind Herausforderungen, Probleme oder Chancen. Ausgehend von einer Herausforderung hilft es dem Team beispielsweise, mehr Designräume zu erkunden und schließlich die Lösungsmöglichkeiten zu erweitern.

Die Missionsvalidierung umfasst mehrere Aktivitäten, die dem Unternehmen helfen, die Kundenbedürfnisse besser zu verstehen:

1. Durchführung von Marktforschungen und Wettbewerbsanalysen
2. Verstehen des Problemraums, in dem die Mission definiert ist
3. Entwerfen von Low-Fidelity-Skizzen und Prototypen
4. Definieren Sie einen klaren Umfang für die Mission
5. Sammeln von Kundenfeedback und Validierung

Diese Aktivitäten tragen dazu bei, dass die Mission eine solide Richtlinie für das Entwicklungsteam darstellt und garantiert, dass für die Benutzer ein Mehrwert geschaffen wird.

Infolgedessen werden einige Missionen validiert, um in das Mission Backlog aufgenommen zu werden, das sich durch Entdeckungsaktivitäten und das Sammeln von Feedback kontinuierlich weiterentwickelt.

Nehmen wir im Beispiel diese Herausforderung: Welche Funktionen sollten aus der Plattform entwickelt werden, um eine überzeugende Benutzererfahrung zu erzeugen? Nur ein Discovery-Team unter der Leitung des Produktmanagers wäre ausreichend, um diese Herausforderung anzugehen.

Nehmen wir an, dass die Plattform des Beispielunternehmens derzeit die Rohdaten des Kunden nimmt und ein optimiertes Preisnetzwerk für verarbeitete Datendateien zurückgibt. Die Plattform UX wurde jedoch nicht für ein fesselndes Erlebnis optimiert. Das Ziel an dieser Stelle ist es, festzustellen, ob der Kundennutzen aus der Verbesserung der UX, der Entwicklung neuer Funktionen oder der Verbesserung der Plattformdienste resultiert.

Nach einer ersten Marktrecherche fällt die Entscheidung, neue Features zu entwickeln. Kandidatenfunktionen für die Plattform sind:

• Ultraschnelle Preisanpassung
• Schnelle und reaktionsschnelle Benutzeroberfläche
• Intelligente und fortschrittliche Repricing-Regeln
• Preisanpassung und Verkaufshistorie

Zu Entdeckungszwecken entscheidet sich das Unternehmen für einen Design-Sprint-Ansatz: ein fünftägiger Prozess zur Beantwortung kritischer Geschäftsfragen durch Design, Prototyping und Testen von Ideen mit Benutzern. Der Discovery-Prozess wird für jede Kandidatenfunktion durchgeführt, um zu sehen, welche für aktuelle und potenzielle Kunden mehr Wert schafft. Das für die Entwicklung ausgewählte Top-Feature sind intelligente und erweiterte Repricing-Regeln.

Missionsstruktur

Das Erreichen einer soliden Missionsdefinition ist keine triviale Aufgabe. Es muss eine klare geschäftliche Herausforderung darstellen und Grenzen für das Ergebnis setzen, während es gleichzeitig genügend Raum für Teams bietet, um zu einer innovativen und effizienten Lösung zu gelangen. Ein klarer, präziser Auftrag:

• Beschreibt eindeutig eine geschäftliche Herausforderung, nachdem der Problembereich identifiziert und abgegrenzt wurde.
• Synthetisiert alle Informationen und Erkenntnisse, die in früheren Phasen entdeckt wurden.
• Links zu einem gewünschten Geschäftsergebnis.
• Ist ergebnisorientiert und zeigt deutlich das Bild des Missionserfolgs.
• Ist innerhalb des 6-Wochen-Zyklus realistisch und erreichbar.
• Ist ausreichend schmal, um den Fokus zu garantieren, und ausreichend breit, um sich von Details fernzuhalten.

In dem Beispiel wurden nach einer Woche Entdeckung Informationen und Benutzerfeedback gesammelt und synthetisiert.

Zielbenutzer: Kundenpreisanalysten.

Problembereich: Benutzer möchten in der Lage sein, intelligente und erweiterte Regeln für die Preisgestaltung festzulegen und zu verwalten, damit sie die Preisgestaltung unter bestimmten Bedingungen automatisch anpassen können.

Die wertvollsten Bedingungen für Regeln sind Mitbewerberpreis, Versanddringlichkeit, Bestellsumme, verfügbarer Lagerbestand und Rabatt für Premium-Kunden.

Einblicke: Regeln sollten in benutzerdefinierten Prioritäten angewendet werden und bei Bedarf änderbar sein.

Analysten möchten einfach sehen, welche Regeln zu bestimmten Zeiten für ein bestimmtes Produkt gelten.

Gewünschtes Geschäftsergebnis: Steigern Sie das Engagement der Benutzer auf der Plattform um 25 %, gemessen an der auf der Plattform verbrachten Zeit.

Kaderversammlung

Der Teambildungsprozess wird für jeden Entwicklungszyklus ad hoc durchgeführt. Teamautonomie und Selbstorganisationsprinzipien bleiben zentral. Die Teamzusammenstellung wird von einer Mischung aus Faktoren geleitet, die von der Komplexität der Mission, den Fähigkeiten von Entwicklern und Designern, Interessen und der Teamchemie reichen.

Der Prozess der Squadbildung wird durch Agile Coaches unterstützt. Vor jeder Entscheidung wird jede Person gefragt, welche Art von Arbeit sie in den nächsten sechs Wochen machen möchte. Dann werden auf der Grundlage von Erfahrung, Wissen und Fähigkeiten Trupps zusammengestellt, die sicherstellen, dass sie über die erforderlichen Kenntnisse und Fähigkeiten verfügen, um die Mission erfolgreich zu bewältigen.

Agile Coaches arbeiten mit mehreren Squads entlang des Entwicklungszyklus und helfen ihnen, Hindernisse und Abhängigkeiten zu beseitigen. Wenn es mehrere Agile-Coaches gibt, unterstehen sie dem Head of Agile, der für die Teamzusammenstellung, kontinuierliche Verbesserung und Agile-Produktlieferung verantwortlich ist.

Die empfohlene Squad-Größe beträgt 2-4 Personen: normalerweise ein Designer und ein oder zwei Entwickler, je nach Komplexität der Mission. Ein QA-Ingenieur soll einen oder mehrere Trupps dabei unterstützen, die gewünschten Qualitätsstandards zu erreichen.

Squads werden oft nach jedem Zyklus gemischt, sodass jeder mit verschiedenen Personen zusammenarbeiten, Wissen verbreiten und an verschiedenen Produktdimensionen arbeiten kann, obwohl ein leistungsstarkes Squad für einige Zyklen zusammenarbeiten kann.

Der spezielle Trupp im Beispiel sollte Personen mit Fähigkeiten in den Bereichen UI-Design, Datenverarbeitung und Datenvisualisierung berücksichtigen.

Inspizieren und Anpassen innerhalb des Zyklus

Transparenz, Inspektion und Anpassung sollten kontinuierlich von Agile-Coaches durch standardmäßige Agile-Praktiken gefördert werden.

Kurze wöchentliche Treffen werden abgehalten, um die Arbeit zu organisieren und das Erheben von Hindernissen und Abhängigkeiten zu erleichtern. Bei Bedarf wird eine Pflege durchgeführt, um sicherzustellen, dass die Trupps die Mission und die Benutzergeschichten vollständig verstehen. Am Ende jeder Woche werden kurze Retrospektiven durchgeführt, um Änderungen und Verbesserungen zu identifizieren und umzusetzen.

Kontinuierliche Bereitstellungspraktiken sollten während des gesamten Zyklus beibehalten werden. Das Missionsziel könnte früher erreicht werden, da die 6-Wochen-Zyklus-Timebox ein kadenzbasierter Ansatz ist, um Grundregeln festzulegen und gleichzeitig die Vorhersehbarkeit des Trupps zu erreichen.

Eine gute Praxis zur Verbesserung der Transparenz ist eine Demo am Ende der vierten Woche, basierend auf einem vereinbarten Meilenstein zwischen Squads und Produktmanagern. Ziel dieser Demos ist es, den Umfang nach Bedarf anzupassen, zu reduzieren oder zu erweitern.

Für die Beispielmission wurde zwischen dem Squad und dem Produktmanager ein Releaseplan in vier verschiedenen Releases vereinbart:

1. Ausgabe 1:
   • Neue Benutzeroberfläche für Regelfunktionen
   • Preisregeln der Konkurrenz
2. Ausgabe 2:
   • Versand-Dringlichkeitsregel
   • Gesamtregel bestellen
   • Regeln Prioritäten
3. Ausgabe 3:
   • Regel für verfügbares Inventar
   • Regel für die Visualisierungsanwendung
4. Ausgabe 4:
   • Rabatt für Premium-Kunden

Release 3 ist als Demo für die vierte Woche vereinbart. Da Releases während des gesamten Entwicklungszyklus durchgeführt wurden, sollte das gewünschte Geschäftsergebnis (in diesem Fall das Benutzerengagement) von dem Moment an verfolgt werden, an dem der Entwicklungszyklus beginnt. Grafisch wäre der Fortschritt wie folgt zu erwarten:

Pufferzeit

Ein oder zwei Wochen als Pufferzeit zu nehmen, ist eine Praxis, die durch Mission Driven Development-Implementierungen sowie durch andere Skalierungsansätze wie SAFe repliziert wird.

In SAFe wird in jedem Entwicklungszyklus eine Innovations- und Planungsiteration durchgeführt. Es dient als Kontextumschalter und ermöglicht Prozesse und Aktivitäten der Exploration und Innovation, die normalerweise von anderen leistungsorientierten Frameworks ausgelassen werden. Beispiele für Aktivitäten, die in dieser Pufferwoche umgesetzt wurden:

• Endgültige Integration der Lösung . Bei der Bereitstellung gegen Ende des 6-Wochen-Zyklus ist es wahrscheinlich, dass Integration, Verifizierung, Dokumentation und Validierung noch ausstehen. Dezidierte Zeit trägt dazu bei, eine effektive und reibungslose Integration neuer Lösungen in bestehende Produkte sicherzustellen.
• Missionsplanung und Priorisierung . Missionen werden verfeinert, in kleine oder große Chargen eingeteilt und für den nächsten Entwicklungszyklus priorisiert. Bei der Priorisierung von Missionen führen einige Unternehmen Pitch-Days ein, an denen Top-Missionen dem Unternehmen präsentiert und dann – auf kollaborative Weise – für den nächsten Entwicklungszyklus festgelegt werden.
• Hackathons . Hackathons erfreuen sich bei Startups und Unternehmen wachsender Beliebtheit, da sie Innovationen fördern, Gemeinschaften schaffen und auf unterhaltsame Weise neues Wissen und Fähigkeiten aufbauen können. Die Ergebnisse werden anderen präsentiert und werden zu Kandidaten für das Mission Backlog.
• Entwicklung experimenteller Prototypen oder Nebenprojekte . Es ist üblich, Ingenieuren und Designern Zeit zu geben, an dem zu arbeiten, was sie entscheiden, solange sie die geleistete Arbeit am Ende der Pufferzeit zeigen.
• Ingenieursarbeit . In der Regel werden reine Engineering-Arbeiten wie Infrastrukturentwicklung, Testautomatisierung, technischer Schuldenabbau und Systemmigrationen durchgeführt.
• Entwicklung neuer Fähigkeiten und Kenntnisse . Das schnelle Tempo der Wissensentwicklung zwingt Entwickler, sich über globale Trends auf dem Laufenden zu halten. Die Pufferzeit eignet sich unter anderem für Schulungen vor Ort, Communities of Practice und Technologie-Workshops.

Pufferzeiten sollten sich auf identifizierte Wissenslücken, Innovationsziele und Bedürfnisse für den nächsten Zyklus stützen. Eine Pufferzeit von einer Woche könnte beispielsweise so aussehen:

Kapazitätsplanung

Bei der Entscheidung über das Missionsengagement für den nächsten Entwicklungszyklus ist es laut Basecamp-Mitbegründer Jason Fried eine gängige Praxis, zunächst kleine oder große Chargen zu identifizieren. Große Chargen beziehen sich auf große Produktmerkmale oder Funktionalitäten, während sich kleine Chargen auf kleinere Iterationen oder Aufgaben beziehen. In dem gegebenen Beispiel könnte die ausgewählte Mission für ein neues Feature als großer Stapel betrachtet werden.

Die Empfehlung hier ist einfach: Haben Sie immer eine Mischung aus kleinen und großen Chargen. Kleine Chargen sind Missionen, die schätzungsweise 3-4 Wochen dauern, und große Chargen können sechs Wochen oder länger dauern.

Wenn ein Small-Batch-Team seine Mission bis Woche 3 oder 4 erfüllt hat, bietet die vereinbarte Demo die Gelegenheit zu beurteilen, ob das Team weiter an der Verbesserung der implementierten Lösung arbeiten, einem anderen Team helfen, eine neue Small-Batch-Mission übernehmen oder beginnen sollte ungeplante Arbeit.

Eine gute Mischung aus großen und kleinen Chargen verhindert, dass die Mitarbeiter zu 100 % ausgelastet sind, und ermöglicht ihnen so, im Falle von ungeplanten Arbeiten zu manövrieren und sich anzupassen. Big-Batch-Teams erhalten während des Zyklus so viel Fokus wie möglich, während Small-Batch-Teams Ad-hoc-Aufgaben erledigen können, die sich aus unerwarteter Arbeit ergeben.

Die Kombination kleiner und großer Chargen reduziert auch das Risiko. Nur große Chargen zu haben, kann die Wahrscheinlichkeit einer negativen Auswirkung auf die Benutzererfahrung erhöhen. Wenn mehrere neue Funktionen nah beieinander veröffentlicht werden, sollten sie von einem guten Änderungsmanagement begleitet werden. Außerdem stehen bei ungeplanten Arbeiten weniger Kapazitäten zur Verfügung. Wenn schließlich mehrere Big-Batch-Teams scheitern, könnte die Iteration als unproduktiv empfunden werden und somit die Squads demoralisieren.

Risiken der Mission Driven Development

Die Implementierung von Mission Driven Development hat viele Vorteile, aber wie jedes vorgeschriebene Framework birgt es mehrere inhärente Risiken, die berücksichtigt werden müssen.

Missionsumfang

Missionen sollten realistisch sein und darauf abzielen, die Komplexität der Herausforderung und die Fähigkeiten des Trupps gut aufeinander abzustimmen; andernfalls können die Auswirkungen auf die Entwicklungsergebnisse erheblich sein.

Eine zu ehrgeizige Mission könnte Frustration und Angst hervorrufen und sich negativ auf die Leistung des Teams auswirken. Auf der anderen Seite könnte eine wenig begeisterte Mission zu Demotivation und Langeweile im Team führen. Daher sollte eine Minimum Viable Product-Mentalität innerhalb des Rahmens konstant bleiben.

Das Warum einer Mission

Robuste Geschäftsmissionen sollten eine umfassende Definition des Problemraums und seiner Beziehung zur Unternehmensvision enthalten. Wenn diese Beziehung nicht klar ist, können wertvolle Erkenntnisse aufgrund eines mangelnden Verständnisses darüber verloren gehen, wie sich die Problemlösung auf die Unternehmensziele auswirkt.

Wasserfallfalle

Während der sechs Wochen in ein Wasserfallmodell zu geraten, ist eine natürliche Tendenz für Squads. Dafür gibt es zwei Hauptfaktoren. Erstens ist der Einsatzdruck gegen Ende des Zyklus stärker. Zweitens möchten Trupps innerhalb einer Mission so viel Umfang wie möglich ausschöpfen, was zu einer Dringlichkeit für den Einsatz am Ende des Entwicklungszyklus führt. Daher sollten Continuous-Delivery-Praktiken gefördert werden, um während des gesamten Zyklus agile Releases zu erreichen und wasserfallbedingte Risiken zu vermeiden.

Produktbetrieb

Produktbetriebsaufgaben wie das Verwalten von Infrastruktur, Diensten oder Überwachen von Komponenten sollten außerhalb des Aufgabenbereichs von Squads bleiben, da sie die Geschwindigkeit beeinträchtigen könnten. Der Rückgriff auf Entwicklungsstandards und -praktiken wie Atomic Design reduziert den Entwicklungsaufwand und beschleunigt folglich die Skalierung. Eine weitere gängige Praxis in diesem Rahmen ist ein zentrales Betriebsteam, das sich neben der Verwaltung des Produktbetriebs und der Überwachung auch um die Infrastruktur kümmert.

6-Wochen-Zyklus als kurzsichtiger Rahmen

Einige Szenarien sind für das Framework nicht geeignet. Dies gilt insbesondere beim Umgang mit großen und komplexen Systemen, die einen enormen Einfluss auf die Kundenerfahrung haben können, wie z. B. F&E-Projekte oder die Migration kritischer Systeme.

Eine leichtgewichtige Option für die Skalierung von Agile

Agil zu skalieren, um mit der Produktentwicklung und dem Unternehmenswachstum Schritt zu halten, ist eine latente Herausforderung für Agile Praktiker. Als kürzlich entwickelter agiler Ansatz hat das Mission Driven Development Framework aufgrund seiner Benutzerfreundlichkeit und Implementierung bei Unternehmen an Popularität gewonnen. Das MDD-Framework setzt einen durchgängigen, transversalen Produktinnovationsprozess in Gang, von der Entdeckung bis zur Auslieferung, der die Lücken in traditionellen agilen Strukturen füllt. Mission Driven Development hat das Potenzial, das neue Scrum für wachsende Unternehmen zu werden.