Wenn „agil“ zum Freifahrtschein wird
Agile Frameworks richtig einsetzen beginnt damit, einen verbreiteten Irrtum zu korrigieren: „Wir sind ja agil“ bedeutet nicht, dass Planung überflüssig ist. Dennoch erlebe ich diesen Satz regelmäßig, meistens als Begründung dafür, warum man sich nicht festlegen möchte oder Erwartungen nicht erfüllt werden.
Agil heißt: die nächsten ein bis zwei Sprints feingranular planen, alles dahinter grober. Iterativ, nicht planlos. Wer das verwechselt, hat ein Problem, das kein Framework löst.
Der Begriff „agil“ nutzt sich ab. Nicht weil die Idee schlecht ist, sondern weil sie zu oft von oben verordnet wurde, ohne echte Begleitung. Die Konsequenz kenne ich aus vielen Organisationen: Stühle werden umgestellt, Zettelchen aufgeklebt, ein Kanban-Board hängt an der Wand. Und dann heißt es: „Wir machen jetzt Agile.“ Das ist kein Organisationsentwicklung, das ist Kulissenbau.
Ich selbst trete deshalb kaum noch als „Scrum Master“ oder „Agile Coach“ auf. Nicht weil ich mich von den Methoden distanziere, sondern weil der Begriff so viele Erwartungen weckt, die am eigentlichen Ziel vorbeigehen. Mir geht es darum, Teams und Organisationen weiterzuentwickeln. Agile Methoden sind dabei Werkzeuge, kein Selbstzweck.
Das Grundproblem: Frameworks über den falschen Kontext stülpen
Bei einem großen deutschen Automobilkonzern sollte ich ein Team als Scrum Master begleiten. Das Team selbst steuerte ausschließlich externe Dienstleister, es gab kein gemeinsam wertschöpfendes Arbeiten im klassischen Sinne. Scrum „by the book“ hätte in diesem Kontext reinen Overhead produziert.
Was ich stattdessen tat: Werkzeuge selektiv eingesetzt. Kein Daily, sondern ein offener Sync nach Bedarf. Retrospektive alle drei Wochen statt zweiwöchentlich. Kein Sprint Review, weil es schlicht kein vorzeigbares Inkrement gab. Das Ergebnis war besser als jedes Framework-konforme Vorgehen es gewesen wäre.
Darüber hinaus sehe ich einen strukturellen Denkfehler in vielen Unternehmen: Agilität im gesamten Unternehmen ausrollen zu wollen. Das klingt ambitioniert, verkennt aber die Ambidextrie zwischen Produktivität und Innovation. Ein Rechnungswesen mit klaren Prozessen braucht kein Scrum. Ein Produktentwicklungsteam in unsicherem Marktumfeld sehr wohl.
Blaue und rote Probleme: Das nützlichste Unterscheidungsmodell
Gerhard Wohland und das intrinsify-Netzwerk haben ein Denkmodell geprägt, das ich in meiner Arbeit ständig nutze. Es trennt zwischen blauen und roten Problemen, angelehnt an die Logik der Stacey-Matrix.
Blaue Probleme sind kompliziert, aber lösbar: Ursache und Wirkung sind bekannt, Prozesse und Wissen sind vorhanden. Hier reicht effizientes Handeln. Agile Frameworks sind in diesem Kontext Verschwendung, denn sie bringen Overhead in ein System, das Klarheit braucht.
Rote Probleme sind komplex: Ursache-Wirkungs-Zusammenhänge fehlen oder sind unvorhersehbar. Hier braucht man, was Wohland „Könner“ nennt, Menschen mit eingespielter Erfahrung und adaptivem Denken. Genau für diesen Kontext sind Frameworks wie Scrum gebaut.
Eine gute Analogie ist das Fliegen: Start, Landung, Autopilot sind blaue Situationen mit Standardprozessen. Ein Triebwerksausfall ist rot: er braucht eingespieltes Können, das sich nicht aus einem Handbuch ablesen lässt.
Kein Kontext ist rein blau oder rein rot. Deshalb lautet die pragmatische Frage: Überwiegen die komplexen Teilprobleme? Wenn ja, ist ein agiles Framework wie Scrum sinnvoll. Wenn der Löwenanteil der Aufgaben klar und prozessierbar ist, erzeugt Scrum nur Reibung.
Scrum-Theater und die Frage nach echter Verschwendung
„Scrum-Theater“ entsteht, wenn alle Beteiligten wissen, was zu tun ist, aber pflichtschuldig ein Sprint Review „zusammenzimmern“, meistens ohne echte Stakeholder, ohne offene Fragen, ohne Lerneffekt. Das ist kein Review, das ist Hygiene-Theater.
Mein eigener Maßstab für Verschwendung ist konsequent teamzentriert: Was das Team als wertlos empfindet, ist Verschwendung. Was es als wertvoll erlebt, ist es nicht, auch wenn es vom Lehrbuch abweicht. Dazu gehören auch interne Reviews ohne externe Kunden. Wenn ein Team durch das gemeinsame Vorzeigen von Arbeit Transparenz schafft und Vertrauen aufbaut, hat dieser Termin seinen Zweck erfüllt.
Im klassischen Projektmanagement wurde der Mensch oft ausgeblendet. Hartes Delivern, Lessons Learned als wirkungsloser Abschluss, Aufwände ohne Reflexion. Agile Arbeitsweisen schauen stärker auf die Menschen, die das System am Laufen halten. Das ist kein weicher Faktor, das ist ein strategischer Unterschied. Mehr dazu, wie Lessons Learned und Retrospektive sich unterscheiden, habe ich in einem eigenen Artikel beschrieben.
Shu-Ha-Ri: Wie der Einstieg gelingt, ohne im Framework zu erstarren
Ich empfehle fast immer den gleichen Einstieg: Erst nahe am Framework starten, dann gemeinsam mit dem Team in der Retrospektive adaptieren. Nicht weil das Lehrbuch sakrosankt wäre, sondern weil es eine gemeinsame Referenz schafft. Wenn alle wissen, was „by the book“ bedeutet, können alle gemeinsam entscheiden, was sie davon behalten und was nicht.
Das ist Shu-Ha-Ri in der Praxis. Shu: die Regel verstehen und folgen. Ha: die Regel hinterfragen und situativ anpassen. Ri: über die Regel hinauswachsen und aus dem Verständnis heraus handeln.
Dabei entsteht manchmal die Frage, ob ein Scrum Master oder Agile Coach vorher Führungserfahrung gebraucht hätte. Ein geschätzter Kollege von mir sagt: ja, unbedingt. Ich sehe das differenzierter. Erfahrung macht sattelfester, keine Frage. Aber die entscheidende Sensitivität für Gruppendynamik, für das, was zwischen den Zeilen passiert, das ist mehr Persönlichkeit als Biografie. Diese „Antennen“ lassen sich nur begrenzt trainieren.
Mein persönlicher Fail: Spannungen zu lange laufen lassen
2017 begleitete ich ein Team, in dem ein Mitglied Regeln konsequent nach eigenem Gutdünken auslegte. Pünktlichkeit, Commitments, gemeinsame Vereinbarungen: alles wurde dehnt, bis andere im Team begannen, dasselbe zu tun. Die Leistung des Teams litt spürbar.
Ich wartete etwa drei bis vier Monate, bevor ich die Spannung direkt adressierte. Das war zu lang. Viel zu lang. Der Schaden war da, das Vertrauen im Team beschädigt.
Das Learning daraus ist nicht, jeden Konflikt sofort auf den Tisch zu legen. Sondern: Spannungen früh ansprechen, sobald sie die Wertschöpfung beeinträchtigen. Nicht vorher, weil nicht jede Reibung schädlich ist. Aber auch nicht monatelang warten, in der Hoffnung, es löse sich von selbst.
Heute gilt das als eine meiner Stärken. Ich gehe in Retrospektiven wie ein Spurensucher rein: Was liegt hinter dem, was gesagt wird? Welche Fährten legt jemand aus? Heikle Themen bearbeite ich danach bevorzugt im Vier-Augen-Gespräch, nicht auf der öffentlichen Bühne. Blaming vor dem Team löst selten etwas, es eskaliert meistens nur.
Agile Systeme werden ausgenutzt: Wie damit umgehen?
Ein Kollege formulierte es pointiert: Agile Arbeitsweisen ziehen Menschen an, die klare Verbindlichkeiten scheuen, weil es so viel Auslegungsspielraum gibt. Jede Retrospektive lässt sich blockieren. Jedes Commitment lässt sich wegdefinieren. Das ist keine Erfindung, das ist Beobachtung aus der Praxis.
Mein Umgang damit: Ich beobachte, ohne sofort zu intervenieren. Wenn ein Muster klar wird, spreche ich es an, konstruktiv und direkt. In der Gruppe funktioniert das oft schon dadurch, dass Spannungen sichtbar werden und andere Teammitglieder merken, dass ihre Wahrnehmung geteilt wird.
Wer tiefer in die Dynamiken agiler Teams eintauchen möchte, findet in meinem Artikel über systemische Entwicklung im Chapter weitere Perspektiven auf soziale Muster in Organisationen.
Was wirklich zählt: Hinter die Frameworks schauen
Der Abschluss-Appell aus meinem Gespräch mit Alex beim Podcast „agile fails best.“ war so einfach wie ernstzunehmen: Hinter die Frameworks schauen. Fragen, welches Problem wirklich zu lösen ist. Kein Aktionismus, wenn ein Team bereits gut läuft. Manchmal ist die beste Intervention, die Klappe zu halten und gewähren zu lassen.
Das klingt unspektakulär. Ist es auch. Und genau deshalb wird es so selten gemacht.
Frameworks wie Scrum sind nicht schlecht, sie sind nur kontextgebunden. Wer sie versteht, passt sie an. Wer sie nicht versteht, klebt Zettelchen und stellt Stühle um.
Daher meine Einladung: Schreib mir, welche Situation dich gerade beschäftigt. Nicht welches Framework du einsetzt, sondern welches Problem du lösen möchtest. Genau da fangen die richtigen Gespräche an.
Mehr zu den Grundlagen, auf denen ich aufbaue, findest du in meinem Artikel über agile Werte versus agile Methoden.
