Zwischen Routine und Innovation: Das richtige Vorgehensmodell für die Software-Produktentwicklung finden
Cynefin Framework: Klarheit im Dschungel der Methodenwahl
Die Entwicklung neuer Softwareprodukte kennt kein Patentrezept: Jede Situation ist anders. Das Cynefin Framework von Dave Snowden bietet einen Kompass, um typische Aufgabenbereiche in der Produktentwicklung einzuteilen und daraus die geeignete Herangehensweise abzuleiten. Es unterscheidet zwischen fünf Domänen:
-
Einfach (Obvious): Die Zusammenhänge sind klar, es gibt etablierte Best Practices. Beispiel: Standardisierte Wartungsaufgaben, Anwendung von Coding-Guidelines.
-
Kompliziert (Complicated): Ursache und Wirkung sind nicht auf den ersten Blick ersichtlich; Fachwissen ist nötig, wie bei Architektur-Entscheidungen oder Performance-Optimierungen.
-
Komplex (Complex): Wirkzusammenhänge sind erst im Nachhinein verstehbar, Experimente und Feedback sind der Weg zum Ziel (z. B. Entwicklung neuartiger Features).
-
Chaotisch (Chaotic): Zeit für Analyse bleibt nicht – bei Produktionsausfällen oder akuten Notfällen muss sofort gehandelt werden.
-
Unordentlich (Disorder): Unklarheit darüber, welche der Domänen überhaupt zutrifft – typisch für diffuse Projektanfänge.
Anhand dieser Einteilung lassen sich Methoden und Teams optimal auf die jeweilige Aufgabe einstellen – und damit Projekte zielsicher und effizient steuern.
Von „blau“ zu „rot“: Die Farbenlehre nach Wohland
Gerhard Wohland bringt diesen Gedanken mit einer Farbwelt auf den Punkt:
-
Blaue Welt: Hier ist das Vorgehen plan- und steuerbar. Wissen zählt, Prozesse sind etabliert. Wiederholbare Probleme finden bewährte Lösungen.
-
Rote Welt: Hier herrschen Dynamik, Unsicherheit und Überraschung. Können zählt, innovatives, emergentes Handeln ist nötig, Zusammenarbeit und Experimentieren sind essenziell.
Im Software-Alltag spiegeln sich diese Welten in der Auswahl des Vorgehensmodells wider.
Praxisnah: Produktentwicklung – immer Rot?
Es hält sich der Mythos, dass Software-Produktentwicklung automatisch immer „rot“, also komplex und unvorhersehbar, ist. Das stimmt so nicht. Entscheidend sind der Kontext und die vorhandenen Erfahrungsmuster.
Die „blaue“ Produktentwicklung
Ein erfahrenes Team entwickelt ein Produkt, das von Vorgängerprojekten oder Standardlösungen abweicht – aber die Grundzüge, Technologien und Prozesse sind bekannt. Beispiele:
-
Wiederholte Entwicklung eines Produkts innerhalb einer fest etablierten Architektur.
-
Upgrade/Klon eines bewährten Systems für einen neuen Markt.
-
Einführung bekannter Module in einen existierenden Softwarekontext.
Hier wirken Routine, Erfahrungswissen und klare Arbeitsteilung. Bewährte klassische, plangetriebene Modelle (Wasserfall, V-Modell) oder straff geführte Phasenmodelle führen schnell und effizient zum Ziel.
Die „rote“ Produktentwicklung
Ist das Ziel noch nicht klar umrissen, die Technologie neu, die Anforderungen volatil – dann ist die Zukunft nur tastend und schrittweise zu erkunden. Beispiele:
-
Greenfield-Entwicklung in einem neuen Technologiefeld.
-
Entwicklung eines Produkts mit disruptivem Business Model.
-
Projekte mit radikal neuen Schnittstellen oder KI/IoT-Integration.
Hier helfen agile Methoden, kurze Sprints, enge Feedback-Loops und multifunktionale Teams. Innovation entsteht im Zusammenspiel vieler Köpfe, auf Basis von Offenheit, Fehlerkultur und Experimentierbereitschaft.
Übergänge und Mischformen: Die Realität ist bunt
In der Praxis verschwimmen die Grenzen:
-
Einzelne Features können „rot“, andere „blau“ sein – und ein Projekt wandert im Verlauf von Rot nach Blau (oder umgekehrt).
-
Erfolgreiches Wissensmanagement und Dokumentation helfen, aus roten Pionierleistungen für spätere blaue Wiederholungssituationen zu lernen und Routinen zu schaffen.
-
Methodenwechsel im Projekt sind kein Zeichen von Schwäche, sondern Ausdruck einer dynamischen, reflektierten Führungskultur.
Leitfaden für die Praxis: Wie wähle ich das passende Vorgehen?
-
Analysephase: Nutze das Cynefin Framework – Wo sind Aufgaben eindeutig, wo brauchen sie Fachleute, wo Experimente?
-
Erfahrungsabfrage: Gibt es ähnliche Vorgängerprojekte – oder betritt das Team völliges Neuland?
-
Flexibilität statt Dogma: Wasserfall kann in der Blauwelt glänzen – Scrum und Co. gehören in die Rotwelt. Wer dogmatisch nur agil arbeitet, schadet manchmal mehr als er nützt.
-
Regelmäßiger Check: Produktentwicklung ist dynamisch. Überprüfe regelmäßig: Ist eine Aufgabe noch Rot, oder ist sie bereits Blau geworden?
Fazit: Moderne Produktentwicklung braucht mehr als Methodendogmen
Die klügste Wahl ist kontextsensitiv. Teams sollten sich fragen: Wie neu ist die Aufgabe? Wie viel Erfahrung und Struktur steckt im Team? Welche Risiken kann man eingehen? Die Tools von Cynefin und Wohland helfen dabei, die Lage realistisch einzuschätzen – und den Weg zu erfolgreichem Softwareprodukt systematisch zu finden.