Mindset vor Methode

Du hast es sicher schon oft erlebt: In Diskussionen, auf Social Media oder in Artikeln klagen viele darüber, dass agiles Arbeiten nicht funktioniert. Viele, die in “agilen” Teams arbeiten, fühlen sich gegängelt. Das was sie über agiles Arbeiten lesen entspricht nicht dem, wie sie bei sich agiles Arbeiten erleben. Sie sagen: „Wir machen doch Scrum“ oder „Wir nutzen Jira und haben ein Daily“, aber irgendwie funktioniert das alles nicht. Die Folge ist oft pure Frustration.

Warum ist das so? Die Antwort liegt in einem fundamentalen Missverständnis dessen, was Agilität im Kern ausmacht.

Das große Missverständnis: Falsche Erwartungen

Mach einmal den Test und google selbst zum Beispiel „Why Agile“. Die Ergebnisse sind oft ebenso erhellend wie erschreckend. Du wirst auf Sätze stoßen wie:

• Agile Methoden helfen Teams, Projekte pünktlich und im Budget abzuschließen.
• Ein Vorteil von Agilität ist eine bessere Projektkontrolle.
• Agilität hilft Teams, effizienter zu arbeiten und die höchste Qualität innerhalb der Budgetbeschränkungen zu liefern.

Genau hier liegt das Problem. Diese Aussagen schaffen Erwartungen, die Agilität niemals erfüllen kann oder will. Agilität hat nichts mit klassischem Projektmanagement oder starrer Budgetkontrolle zu tun. Zwar können positive Effekte wie eine hohe Qualität oder eine gewisse Budgettransparenz durch kleine Lieferungen entstehen, aber sie sind nicht der eigentliche Grund für agiles Arbeiten.

Die erste und wichtigste Frage: Was für eine Arbeit machst du?

Bevor du überhaupt über Agilität nachdenkst, solltest du dir eine ehrliche Frage stellen: Welche Art von Tätigkeit übst du und dein Team aus?

Stell dir vor, du arbeitest bei VW und baust einen Golf. Der Prozess ist bekannt, die Schritte sind klar, das Ergebnis ist definiert. Du reproduzierst etwas. In einem solchen Umfeld brauchst du kein hohes Maß an Agilität. Ein klassischer Planungsansatz ist hier wahrscheinlich effizienter und sinnvoller.

Jetzt stell dir vor, du entwickelst eine völlig neue Software. Du betrittst permanent Neuland. Die Anforderungen sind am Anfang vage, denn selbst der Kunde kann nicht vollständig beschreiben, was er am Ende genau braucht (auch, wenn er das manchmal behauptet). Das ist kein Vorwurf, das ist menschlich und völlig normal. In Projekten werden wir alle schlauer.

Genau für dieses Umfeld – das Unbekannte – wurde Agilität geschaffen. Sie erkennt an, dass wir:

• nicht alles von Anfang an wissen können.
• während des Projekts dazulernen.
• Feedback brauchen, um zu überprüfen, ob unsere Ideen funktionieren.

Agilität ist also die Antwort auf Projekte, bei denen der Weg und das Ziel nicht von Anfang an glasklar sind. Sie ist nicht per se „schnell“, sondern „beweglich“ (agile). Sie ist das relativ schnellste Vorgehen in einem unbekannten Umfeld, weil sie durch ständiges Lernen und Anpassen Verschwendung (Waste) vermeidet.

Ein Modell zur Orientierung: Die Stacey Matrix

Dieser intuitive Unterschied zwischen der Arbeit am Fließband und der Erkundung von Neuland hat einen Namen und ein Modell: die Stacey Matrix von Ralph D. Stacey.¹ Sie ist ein geniales Werkzeug, um zu verstehen, welche Art von Arbeit du vor dir hast und welcher Lösungsansatz dafür am besten geeignet ist.

Die Matrix spannt sich über zwei Achsen auf:

• Die vertikale Achse (Das Was): Wie klar sind die Anforderungen? Wie einig sind wir uns (Team, Kunde, Stakeholder) darüber, was am Ende herauskommen soll? Die Skala reicht von „nah an der Gewissheit“ bis „weit entfernt von Gewissheit“.
• Die horizontale Achse (Das Wie): Wie klar ist der Lösungsweg oder die Technologie? Wissen wir genau, mit welchen Schritten und Werkzeugen wir das Ziel erreichen? Die Skala reicht von „nah an der Gewissheit“ bis „weit entfernt von Gewissheit“.

Daraus ergeben sich vier Hauptdomänen:

• Einfach (Simple): Unten links. Die Anforderungen sind klar, der Lösungsweg ist bekannt. Das ist dein VW Golf vom Fließband oder Backen nach Rezept. Hier brauchst du kein agiles Vorgehen. Ein klassischer Plan (Wasserfall) ist effizient und absolut ausreichend. Man spricht hier auch von “Best Practice”.
• Kompliziert (Complicated): In der Mitte. Die Anforderungen sind relativ klar, aber der Lösungsweg erfordert Expertenwissen und Analyse. Der Bau einer Brücke oder die Reparatur eines Uhrwerks fällt hierunter. Auch hier sind klassische Projektmanagement-Methoden oft noch gut geeignet, da das Problem durch Analyse lösbar bleibt. Man spricht hier von “Good Practice”.´
• Komplex (Complex): Oben rechts. Sowohl die Anforderungen als auch der Lösungsweg sind unklar. Das ist das Neuland der Softwareentwicklung. Wir wissen am Anfang nicht genau, was der Kunde am Ende wirklich braucht, und wir wissen nicht, welche technischen Hürden auf dem Weg lauern. Genau hier, im komplexen Bereich, ist Agilität zu Hause. Hier können wir nicht planen, wir müssen entdecken – durch kurze Zyklen, Experimente und schnelles Feedback.
• Chaotisch (Chaotic): Ganz oben rechts. Hier herrscht pures Chaos – ein Systemausfall des Produktionsservers, eine schwere Krise tritt ein. Es gibt keine Zeit für Pläne – Chaos ist nicht planbar. Das einzige Ziel ist, sofort zu handeln und die Situation zu stabilisieren, während sich die Umstände rapide ändern können. Agilität kann helfen, um etwas Struktur in die Unordnung zu bringen und gegebenenfalls die Situation wieder ins Komplexe zu bringen. Das Chaos an sich ist nicht handhabbar.

Die Stacey Matrix zeigt schonungslos, warum der Versuch, komplexe Softwareprojekte mit den Methoden aus der “einfachen” oder “komplizierten” Welt zu managen, zum Scheitern verurteilt ist. Es ist der Versuch, eine unbekannte Landschaft mit einer perfekten, vorher gezeichneten Karte zu durchqueren. Das kann nicht funktionieren.

Wenn du also feststellst, dass du und dein Team sich die meiste Zeit im komplexen Feld bewegt, dann ist die Frage nicht ob ihr agil arbeiten solltet, sondern nur noch wie.

Hinweis: Die Stacey Matrix ist ein einfaches, aber extrem wirkungsvolles Modell, um diese Unterscheidung zu treffen. Ein weiteres, noch tiefergehendes Framework in diesem Bereich ist das Cynefin Framework² von Dave Snowden, das uns lehrt, Probleme erst zu klassifizieren, bevor wir handeln. Schau hier gerne in den verlinkten Wikipedia Artikel, wenn du tiefer buddeln möchtest.

Das Fundament: Mehr als nur Regeln und Werkzeuge

Wenn du also in einem Umfeld des „Neulands“ arbeitest, wie setzt du Agilität dann richtig um? Hier kommt der entscheidende Punkt: Agilität ist zuallererst ein Mindset, eine Haltung.

Es braucht am Anfang nicht viel: Nur das Verständnis für das Agile Manifest und seine zwölf Prinzipien. Das ist die Basis. Alles andere – Scrum, Kanban, Jira, Rollen wie der Product Owner oder Scrum Master – ist untergeordnet. Diese Frameworks, Methoden und Werkzeuge sind nur Hilfestellungen, die on top kommen. Sie sind das „Wie“, aber das Mindset ist das „Warum“.

Der häufigste Fehler ist, diesen Schritt zu überspringen. Menschen sehnen sich nach klaren Regeln, deshalb greifen sie zu einem Framework wie Scrum. Sie halten sich penibel an das Regelwerk, führen alle Zeremonien durch und wundern sich dann, warum sie nicht agil sind. Der Grund ist einfach: Sie oder ihr Umfeld haben das Fundament, das Mindset, nicht verstanden oder verinnerlicht.

Wenn bei dir im Team die Frage aufkommt „Warum funktioniert Scrum bei uns nicht?“, solltest du einen Schritt zurücktreten und fragen: „Welche Grundprinzipien der Agilität leben wir nicht gut genug?“

Die „Agile Primitives“: Der Baukasten, auf den es wirklich ankommt

Wenn es also nicht die Methode ist, was ist es dann? Wenn ‘Mindset’ das ‘Warum’ ist, was sind dann die fundamentalen Bausteine des ‘Wie’, die unabhängig von Scrum oder Kanban immer gelten müssen? Stefan Wolpers hat dafür einen brillanten Begriff geprägt: die „Agile Primitives“.³ Das sind die fundamentalen, unteilbaren Bausteine, die den Kern jeder echten agilen Arbeitsweise ausmachen – unabhängig von einem spezifischen Framework. Wenn du diese Prinzipien lebst, bist du agil, egal ob du Scrum, Kanban oder gar keine benannte Methode nutzt.

Lass uns diese zehn „Primitives“ als eine Art „No Bullshit“-Checkliste betrachten:

1. Iterative Entwicklung: Du arbeitest in kurzen Zyklen, in denen du planst, umsetzt, testest und lieferst.
2. Inkrementelle Lieferung: Du lieferst funktionierende Software in kleinen, werthaltigen Teilen aus, so früh und so oft wie möglich. (Übrigens: Nichts im agilen Manifest verbietet es, mitten in einem Sprint zu liefern, wenn etwas fertig und wertvoll ist!)
3. Kontinuierliche Verbesserung (Kaizen): Du schaust permanent auf deine Produkte und deine Prozesse und fragst: „Was können wir besser machen?“ und „Wie können wir uns besser organisieren?“. Die Retrospektive ist dafür nur ein Werkzeug, nicht das einzige.
4. Zusammenarbeit mit dem Kunden: Der Kunde ist ein aktiver Partner im Prozess, nicht nur ein Auftraggeber am Anfang und ein Abnehmer am Ende.
5. Selbstorganisation: Das Team hat den Freiraum und die Verantwortung, seine eigene Arbeit zu gestalten und zu organisieren.
6. Anpassungsfähigkeit: Du begrüßt Veränderungen, weil du weißt, dass sie im Neuland unvermeidlich und wertvoll sind. Dein Prozess ist darauf ausgelegt, auf neue Erkenntnisse reagieren zu können.
7. Kontinuierliche Integration: Dein Code wird ständig zusammengeführt und in einem releasbaren Zustand gehalten. Das ist die technische Grundlage für Geschwindigkeit.
8. Transparenz: Die Arbeit, der Fortschritt und die Probleme sind für alle Beteiligten jederzeit sichtbar.
9. Feedbackschleifen: Du baust an jeder denkbaren Stelle Mechanismen ein, um schnell Feedback zu bekommen – vom Kunden, vom Nutzer, von automatisierten Tests, von deinen Kollegen.
10. Einfachheit: Du konzentrierst dich darauf, die Menge an nicht getaner Arbeit zu maximieren. Du baust nur das, was jetzt den größten Wert schafft.

Diese zehn Punkte sind das wahre Betriebssystem der Agilität.

Das Hausbau-Beispiel: Der Unterschied im Denken

Um noch mehr in die Denkweise für agiles Arbeiten zu kommen, hier ein kleines (wenn auch konstruiertes) Beispiel. Stell dir vor, du baust ein Haus und es geht jetzt darum, die Anzahl und Position der Steckdosen festzulegen. Jetzt hast du drei Möglichkeiten:

• Der Wasserfall-Ansatz: Du erstellst einen detaillierten Plan, wo jede einzelne Steckdose hinkommen soll. Du investierst Wochen in die perfekte Planung, um ja keine Steckdose zu vergessen. Wenn das Haus fertig ist, stellst du unweigerlich fest: „Mist, hier hinter dem Sofa fehlt eine, und die da in der Ecke brauche ich doch nicht.“ Der Plan war perfekt, aber die Realität hat sich geändert.
• Der „Geld-ist-egal“-Ansatz: Du sagst: „Egal, was es kostet, ich will in jeder Ecke eine Doppelsteckdose.“ Du hast am Ende überall Strom, aber auch viele unnötige Steckdosen, die die Wände verschandeln und Geld gekostet haben.
• Der agile Ansatz: Du sagst: „Lass uns eine Grundausstattung an den offensichtlichsten Stellen installieren. Wenn ich im Haus wohne und meinen Alltag lebe, werde ich schnell merken, wo wirklich noch eine Steckdose fehlt oder eine stört.“ Du vereinbarst mit dem Elektriker, dass er später für schmales Geld schnell und unkompliziert weitere Steckdosen nachrüsten oder entfernen kann.

Der agile Ansatz erkennt an, dass du den perfekten Plan nicht am Anfang machen kannst. Er optimiert nicht für die perfekte Vorhersage, sondern für die schnelle und kostengünstige Anpassungsfähigkeit an die Realität.

Wie du das agile Mindset im Unternehmen verankerst

Ein Mindset lässt sich nicht einfach per Anweisung einführen. Es muss wachsen. Aber du kannst die idealen Bedingungen dafür schaffen.

1. Sichere dir die Unterstützung des Managements: Ohne die Rückendeckung der Führungsebene wirst du immer wieder an Grenzen stoßen. Wenn das Management nicht versteht, warum Agilität mehr ist als nur „Scrum machen“, wird jeder weitere Schritt ein Kampf.

2. Bilde eine Gruppe, die für das Thema brennt: Suche dir Gleichgesinnte aus allen Bereichen des Unternehmens – Management, Entwicklung, Product Owner, Scrum Master, Account Manager. Gründet eine kleine, aber vielfältige Gruppe, eine Art „Tech-Team Agilität“. Die einzige Voraussetzung: Alle in dieser Gruppe müssen für das Thema brennen und es vorantreiben wollen.

3. Schafft ein gemeinsames Fundament: Die erste Aufgabe dieser Gruppe ist es, sich ein einheitliches und tiefes Verständnis von Agilität zu erarbeiten. Beschäftigt euch intensiv mit dem Manifest und den Prinzipien. Was bedeuten sie konkret für euer Unternehmen? Wo ist Agilität bei euch sinnvoll und wo nicht?

4. Arbeitet agil an der Agilität: Nutzt die agilen Prinzipien, um Agilität im Unternehmen voranzubringen.

   • Setzt euch erreichbare Ziele und plant in Iterationen.
   • Sammelt permanent Feedback aus der Organisation.
   • Passt euren Plan basierend auf diesem Feedback an. Denkt daran: Nicht der Plan ist wertvoll, sondern das Planen.

5. Kommuniziert, kommuniziert, kommuniziert: Seid radikal transparent. Teilt eure Pläne, eure Ziele und vor allem die Gründe für eure Entscheidungen. Das schafft Vertrauen und nimmt den Leuten die Angst vor dem Unbekannten. Eine Gruppe, die im Verborgenen arbeitet, erzeugt nur Misstrauen.

6. Werdet zu Multiplikatoren: Nutzt eure Gruppe, um das Wissen im Unternehmen zu verbreiten. Bietet kleine Talks an, steht als Ansprechpartner für Fragen zur Verfügung und helft anderen Teams, die Prinzipien zu verstehen und anzuwenden.

7. Gebt einen Rahmen, aber lasst Freiheit: Setzt Leitplanken, was im Fokus steht und was nicht. Aber gebt den Teams die Freiheit, diese Leitplanken für sich zu interpretieren. Nicht jede Lösung passt für jedes Team.

Dieser Weg ist kein schneller Sprint, sondern ein Marathon. Aber er ist der einzige nachhaltige Weg, um ein echtes agiles Mindset zu etablieren, das weit über das bloße Befolgen von Regeln hinausgeht.

Im Laufe dieses Buchs werden wir alle oben angesprochenen Aspekte weiter ausführen und ich werde euch aus meiner Praxis jeweils Methoden liefern, die ihr als Start- oder Überprüfungspunkt verwenden könnt.

Agilität ist also in erster Linie eine Haltung. Im nächsten Kapitel schauen wir uns mit dem Eisberg-Modell an, warum viele Unternehmen nur die Spitze sehen – und dann scheitern.

Quellen

1. „Ralph D. Stacey“. In Wikipedia. 2025. https://en.wikipedia.org/w/index.php?title=Ralph_D._Stacey&oldid=1314966541.↩︎

2. „Cynefin framework“. In Wikipedia. 2025. https://en.wikipedia.org/w/index.php?title=Cynefin_framework&oldid=1318597538.↩︎

3. Wolpers, Stefan. Agile Primitives — Beyond Frameworks — Age-of-Product.com. 2024. https://age-of-product.com/agile-primitives-beyond-frameworks/.↩︎