Das Daily beginnt pünktlich um 9.30 Uhr, das Board ist aktuell, die Retrospektive steht alle zwei Wochen im Kalender. Trotzdem hat sich in dem Entwicklungsteam einer Versicherung wenig verändert. Anforderungen kommen weiter als fertige Spezifikation aus dem Fachbereich, Probleme werden im Daily nicht angesprochen, und die Retrospektive endet jedes Mal mit denselben drei Punkten, an denen niemand etwas ändern darf. Das Team macht Scrum. Agil ist es nicht.

Für dieses Muster hat sich der Begriff „agiles Mindset“ eingebürgert. Er ist unscharf und wird gern in Präsentationen strapaziert. Dahinter steckt aber eine richtige Beobachtung: Methoden wie Scrum oder Kanban wirken nur, wenn die Beteiligten verstehen, wozu sie dienen, und wenn die Organisation ihnen den nötigen Spielraum lässt.

Was mit einem agilen Mindset gemeint ist

Ein Mindset ist eine Denkweise, also die Annahmen, mit denen Menschen an ihre Arbeit herangehen. Ein agiles Mindset beruht auf einigen Grundüberzeugungen:

• Unsicherheit ist normal. Bei neuer Software ist zu Beginn nicht alles bekannt. Statt das zu verdrängen, plant man so, dass man früh lernen kann.
• Feedback ist wertvoller als Annahmen. Eine kleine Version, die echte Nutzer ausprobieren, sagt mehr als ein langes Konzept.
• Fehler sind Informationen. Wer einen Fehler früh entdeckt, spart Aufwand. Das setzt voraus, dass Fehler offen angesprochen werden können.
• Das Team ist verantwortlich. Wer die Arbeit macht, entscheidet mit, wie sie gemacht wird.

Verwandt ist das Konzept des Growth Mindset der Psychologin Carol Dweck. Sie unterscheidet Menschen, die Fähigkeiten für festgelegt halten, von solchen, die sie für entwickelbar halten. Wer davon ausgeht, dazulernen zu können, sieht in einer gescheiterten Idee eher eine Lernchance als ein persönliches Versagen. Für agile Teams ist diese Haltung eine wichtige Voraussetzung.

Agile tun und agil sein

In der Diskussion über agile Arbeit hat sich eine einfache Unterscheidung durchgesetzt. Agile tun meint die sichtbaren Praktiken: Sprints, Dailys, Boards, User Stories, Retrospektiven. Agil sein meint die Haltung, aus der heraus diese Praktiken sinnvoll werden.

Ein Beispiel macht den Unterschied greifbar. Angenommen, ein Team bemerkt mitten im Sprint, dass eine geplante Funktion für die Nutzer kaum Bedeutung hat. Ein Team, das nur agile Praktiken befolgt, baut sie trotzdem, weil sie im Sprint-Backlog steht. Ein Team mit agiler Haltung spricht mit dem Product Owner, klärt den Nutzen und stellt die Arbeit gegebenenfalls zurück.

Für diese Fehlform gibt es den Begriff „Cargo-Cult Agile“. Er spielt auf Inselbewohner an, die nach dem Zweiten Weltkrieg Landebahnen nachbauten, in der Hoffnung, dass wieder Flugzeuge mit Gütern landen. Die Form stimmt, die Wirkung bleibt aus. In Unternehmen zeigt sich das an Dailys, die zu Statusberichten an die Teamleitung werden, oder an Sprints, deren Inhalt vorab für ein ganzes Jahr feststeht.

Werte und Prinzipien aus dem agilen Manifest

Die Grundlage der agilen Bewegung ist das Manifest für agile Softwareentwicklung. Siebzehn Fachleute aus der Softwareentwicklung formulierten es im Februar 2001 bei einem Treffen in Snowbird im US-Bundesstaat Utah. Es nennt vier Wertepaare:

1. Individuen und Interaktionen mehr als Prozesse und Werkzeuge
2. Funktionierende Software mehr als umfassende Dokumentation
3. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
4. Reagieren auf Veränderung mehr als das Befolgen eines Plans

Wichtig ist der Nachsatz des Manifests: Die Werte rechts sind wichtig, die links werden aber höher geschätzt. Agilität heißt also nicht, auf Dokumentation oder Planung zu verzichten. Es heißt, im Zweifel dem Gespräch, dem funktionierenden Ergebnis und der Anpassung Vorrang zu geben. Wie sich der dritte Wert in der Vertragsgestaltung niederschlägt, beschreibt der Beitrag Agile Verträge verstehen.

Ergänzt werden die Werte durch zwölf Prinzipien. Einige davon sind für den Alltag besonders aufschlussreich:

• Funktionierende Software wird regelmäßig innerhalb weniger Wochen oder Monate ausgeliefert, bevorzugt in der kürzeren Zeitspanne.
• Fachleute und Entwickler arbeiten während des Projekts täglich zusammen.
• Projekte werden um motivierte Menschen herum aufgebaut, denen man das nötige Umfeld und Vertrauen gibt.
• Technische Exzellenz und gutes Design fördern die Beweglichkeit.
• Einfachheit gehört zum Kern, verstanden als die Kunst, die Menge nicht getaner Arbeit zu maximieren.
• In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten an.

Ein Team, das ständig unter Zeitdruck schlechten Code produziert, verliert genau die Beweglichkeit, um die es bei Agilität geht. Warum kleine, häufige Schritte in der Entwicklung so viel bewirken, zeigt der Beitrag Kleine Schritte, große Wirkung.

Psychologische Sicherheit als Voraussetzung

Eine agile Haltung lässt sich nicht anordnen. Sie entsteht dort, wo Menschen erleben, dass Offenheit nicht bestraft wird. Die Organisationsforscherin Amy Edmondson von der Harvard Business School nennt das psychologische Sicherheit: die gemeinsame Überzeugung eines Teams, dass man Fragen stellen, Fehler zugeben und Kritik äußern kann, ohne Nachteile zu befürchten.

Bekannt wurde der Begriff über die Fachwelt hinaus durch Googles internes Forschungsprojekt Aristotle. Google berichtete 2015, dass psychologische Sicherheit unter den untersuchten Faktoren am stärksten mit dem Erfolg von Teams zusammenhing. Solche Ergebnisse aus einem einzelnen Konzern lassen sich nicht eins zu eins übertragen.

Für den Alltag bedeutet das konkret:

• Führungskräfte reagieren auf schlechte Nachrichten mit Fragen statt mit Schuldzuweisungen.
• Retrospektiven haben Folgen. Vereinbarte Verbesserungen werden umgesetzt oder es wird erklärt, warum nicht.
• Nach Störungen wird nach Ursachen im System gesucht, nicht nach Schuldigen. In der IT nennt man das ein Blameless Postmortem.

Wie sich ein agiles Mindset entwickeln lässt

Haltungen ändern sich langsamer als Prozesse. Ein Workshop reicht dafür nicht. Hilfreich sind einige Ansatzpunkte, die sich gegenseitig verstärken.

Mit dem Warum beginnen

Jede agile Praxis hat einen Zweck. Das Daily dient der Abstimmung im Team, nicht dem Statusbericht. Das Review dient dem Feedback, nicht der Präsentation. Wer bei jeder Praxis fragt, wozu sie da ist, erkennt schneller, wenn sie zur Formsache wird.

Entscheidungen dorthin verlagern, wo das Wissen liegt

Ein Team kann nur Verantwortung übernehmen, wenn es Entscheidungen treffen darf. Das betrifft die Reihenfolge der Arbeit, technische Lösungen und die eigene Arbeitsweise. Müssen alle Entscheidungen über die Linie, bleibt das agile Mindset eine Forderung ohne Grundlage.

Kleine Experimente statt großer Programme

Statt die ganze Organisation auf einmal umzustellen, lohnen sich begrenzte Versuche: ein Team, ein Produkt, drei Monate. Was funktioniert, wird übernommen, was nicht funktioniert, wird angepasst. So lebt die Einführung selbst die Haltung vor, die sie fördern will.

Führung als Vorbild

Führungskräfte prägen die Kultur stärker als jedes Leitbild. Wenn sie selbst Feedback einholen, Unsicherheit zugeben und Pläne ändern, wenn neue Erkenntnisse es verlangen, signalisiert das mehr als jede Schulung. Wie sich Rollen und Strukturen dabei verändern, beschreibt der Beitrag Agile Transformation: Wie sich Kultur, Führung und Struktur ändern.

Woran agile Haltung in Unternehmen scheitert

Viele Hindernisse liegen nicht bei einzelnen Personen, sondern in den Strukturen:

1. Jahresplanung mit festen Inhalten: Wenn Budgets nur für fest definierte Funktionen vergeben werden, bleibt für Lernen im Projekt kein Raum.
2. Individuelle Zielvereinbarungen: Werden Menschen an persönlichen Kennzahlen gemessen, konkurriert die Teamarbeit mit den eigenen Zielen.
3. Agilität nur für die IT: Arbeiten Entwicklungsteams in Sprints, Fachbereiche und Einkauf aber nach starren Abläufen, entstehen Reibungen an jeder Schnittstelle.
4. Ungeduld: Kulturelle Veränderungen dauern. Wer nach einem Quartal den Erfolg der agilen Transformation bilanziert, misst meist nur die Einführung von Ritualen.

Was das für Ihr Team bedeutet

Das agile Mindset ist kein Zusatzmodul, das man zu Scrum oder Kanban hinzubucht. Es ist die Voraussetzung dafür, dass diese Methoden überhaupt wirken. Gleichzeitig ist es kein Ersatz für gutes Handwerk: Ohne klare Ziele, technische Qualität und verlässliche Absprachen bleibt auch die beste Haltung folgenlos.

Überschätzt wird, wie viel sich über Appelle erreichen lässt. Wer ein agiles Mindset fördern will, verändert besser die Bedingungen: Entscheidungsspielräume, den Umgang mit Fehlern und die Art, wie Arbeit geplant und bewertet wird. Unterschätzt wird dagegen, wie viel ein einzelnes Team bewirken kann, das die Prinzipien ernst nimmt und seine Erfahrungen sichtbar macht.

Wer agile Arbeitsweisen im Unternehmen verankern möchte, findet auf der Seite zur Beratung und Begleitung agiler Transformation einen Überblick über unsere Angebote.

Häufige Fragen zum agilen Mindset

Ist ein agiles Mindset nur für Softwareteams relevant?

Nein. Das Manifest stammt aus der Softwareentwicklung, die Grundgedanken lassen sich aber auf jede Arbeit übertragen, bei der Ergebnisse unsicher sind und Feedback hilft, etwa im Marketing, in der Produktentwicklung oder in der Personalarbeit. Weniger passend ist es für Tätigkeiten, die stabilen und genau vorgegebenen Abläufen folgen müssen.

Wie lange dauert es, bis sich eine agile Haltung entwickelt?

Eine feste Zeitspanne lässt sich nicht nennen. Ein Wandel in der Kultur einer ganzen Organisation dauert länger als in einem einzelnen Team, weil Strukturen, Budgetprozesse und Führungsverhalten mitziehen müssen.

Funktioniert ein agiles Mindset in einer hierarchischen Organisation?

Ja, in Grenzen. Hierarchie und Agilität schließen sich nicht aus, solange Teams innerhalb klarer Leitplanken selbst entscheiden dürfen. Problematisch wird es, wenn jede Detailentscheidung genehmigt werden muss. Ein sinnvoller Weg ist, mit einzelnen Teams zu beginnen und die Erfahrungen zu nutzen, um Strukturen schrittweise anzupassen.