Stefan, wie hast du auf deinem beruflichen Werdegang agile Methoden kennengelernt?
An der Universität in Oldenburg habe ich Wirtschaftsinformatik studiert und danach einige Jahre als wissenschaftlicher Mitarbeiter an der Fakultät gearbeitet. Hier habe ich viele agile Methoden sowohl in der Theorie, als auch in der Praxis kennengelernt. Danach habe ich als Product Owner Erfahrungen im Bereich der digitalen Produktentwicklung gesammelt, und damit einhergehend sowohl kleine Unternehmen, als auch Konzerne bei ihren Prozessen begleitet. Mittlerweile setze ich mein praktisches Wissen als Berater bei AYVA ein.
Was heißt Agilität eigentlich? Ist das etwas, das nur in der IT-Branche funktioniert?
Agilität ist übertragbar auf alle Branchen, weil Agilität nicht das bloße Anwenden von agilen Methoden bedeutet, wie zum Beispiel Scrum oder Kanban. Vielmehr hängt sie von den Werten und dem Mindset im Team ab.
Damit ist beispielsweise gemeint, dass jeder eigenverantwortlich handelt. Man wartet nicht darauf, dass jemand einem sagt: „Diese Aufgabe musst du jetzt machen“, sondern arbeitet proaktiv am Projekt mit. Jede Person trägt Verantwortung für die eigene Arbeit. Natürlich gibt es innerhalb dieses Teams eine übergeordnete Zielsetzung, die durch einen Product Owner oder den Projektleiter vorgegeben wird. Aber im Grunde funktioniert agiles Arbeiten vor allem durch Eigenverantwortung, sowie durch gutes Teamwork.
Wichtig ist auch das Prinzip von „Inspect and Adapt“; also die Bereitschaft, regelmäßig das eigene Vorgehen, die Ziele und auch die Zusammenarbeit im Team zu hinterfragen und kontinuierlich zu verbessern. Es geht darum, die eigene Arbeitsweise kritisch zu prüfen: Bin ich noch auf dem richtigen Weg? Kann ich Dinge besser machen? Lasse ich Potenziale ungenutzt?
Ein wesentlicher Bestandteil von Agilität ist auch eine gesunde Feedback- und Fehlerkultur. Kritik soll nicht verletzen, sondern dazu beitragen, dass sich alle im Team inhaltlich weiterentwickeln. Dafür braucht es einen “Safe Space”, also eine sichere und positive Atmosphäre, in der Raum für dieses Feedback gegeben ist. So können Team-Mitglieder gemeinsam ein Ziel verfolgen und sich gegenseitig unterstützen. In der Praxis geht es also vor auch um Offenheit und Anpassungsfähigkeit.
Außerdem ist es wichtig, in der agilen Arbeit auf crossfunktionale Teams zu setzen, in denen alle relevanten Disziplinen vertreten und die nötigen Kapazitäten verfügbar sind. Der Fokus muss klar bleiben, daher sollten Teammitglieder nicht in zu vielen verschiedenen Projekten eingesetzt werden.
Was sind deiner Meinung nach die größten Unterschiede zwischen klassischen und agilen Arbeitsweisen?
Aus meiner Sicht sind die Methoden nicht schwarz-weiß voneinander zu trennen. Das kann ein fließender Übergang sein. “Klassisch” klingt auch recht negativ konnotiert. Dabei heißt “klassisch” nicht gleich “schlecht”, und agil ist nicht automatisch besser. Sind beispielsweise wie im Maschinenbau schon von Anfang an die genauen Spezifikationen bekannt, macht das die Ressourcenplanung einfach – in so einem Fall ist klassische Projektplanung durchaus sinnvoll.
In der IT-Branche hat sich Agilität einfach deshalb durchgesetzt, weil Software-Entwicklung nicht immer berechenbar und die Form der Umsetzung nicht von vornherein klar ist. Als Faustregel gilt: Sind die Spezifikationen sehr klar, können klassische Arbeit und Vorausplanung von Ressourcen gut funktionieren. Bei Agilität steht eher die Frage im Vordergrund: “Wie lösen wir das vorliegende Problem am besten?”. Von hier aus wird schrittweise geplant und auch direkt umgesetzt.
Ein Problem entsteht allerdings, wenn auf Software-Projekte mit unklarem Scope (also Umfang der Dinge, die umgesetzt werden sollen) Wasserfall-Prinzipien angewendet werden. Das Resultat ist dann oft, dass der Zeitplan, den man sich am Anfang erarbeitet hat, im Laufe des Projekts immer wieder angepasst werden muss. Spätestens dann sollte man realisieren, dass eine Wasserfallmethode ungeeignet ist. Je nach Projekt sollte man also evaluieren, welche Methode besser ist.
Welche Missverständnisse über Agilität begegnen dir am häufigsten?
Ein sehr häufiges Missverständnis ist, dass Agilität mit Chaos verglichen wird. Viele glauben, dass man in agilen Projekten nicht planen kann, oder dass alles völlig offen und unstrukturiert abläuft. Das stimmt so aber nicht. Auch in einem agilen Setting gibt es eine verlässliche Planung – sie sieht nur anders aus. Anstatt auf eine 100-prozentig ausgearbeitete Lösung hinzuarbeiten, setzt man klare Zeitrahmen (Timeboxing) und akzeptiert auch mal eine 80-prozentige Lösung, um schneller Ergebnisse zu liefern und Nutzerfeedback einzubinden. Das steigert die Time-to-Market und bietet gleichzeitig die Möglichkeit, später auch nutzerorientierte Optimierungen vorzunehmen.
Ein weiteres Missverständnis ist die strikte Trennung von „klassisch“ und „agil“. Wie gesagt, sind die Methoden in der Praxis meist gar nicht so klar voneinander abgegrenzt. Auch in klassischen Projekten gelten Prinzipien wie Eigenverantwortung oder eine gute Feedback-Kultur. Und genauso können agile Elemente – etwa Sprints, Stand-ups oder Retrospektiven – klassische Projekte bereichern. Aus meiner Sicht sollten Projektverantwortliche beide Welten kennen und die Methodik situationsabhängig wählen, je nach Anforderungen und Rahmenbedingungen des Projekts.
Wo sollte man am besten starten, wenn man im klassischen Unternehmen agiler werden möchte?
Dein Team hat Lust, agil zu arbeiten? Dann: Einfach mal machen! Meeting-Formate wie Review, Retrospektive, Refinement und Stand-ups kann man direkt einführen und nutzen. Gerade in kleinen Teams kann man sowas gut testen.
Schwieriger könnte es werden, das richtige Mindset ins Team zu bringen. Die Leute müssen motiviert sein, agile Methoden anzuwenden – ist das gegeben, ist das bereits die halbe Miete.
In einem größeren Unternehmen könnte die Einführung schon komplexer werden. Denn Agilität funktioniert nur dann nachhaltig, wenn auch in den Führungsebenen verstanden wird, welchen Nutzen eine agile Arbeitsweise bringt und wie man dafür den nötigen Raum schafft. Ist ein Unternehmen stark hierarchisch geprägt, in viele kleine Abteilungen mit klaren Übergabepunkten aufgeteilt, dann widerspricht diese Struktur dem Grundgedanken von Agilität – nämlich Crossfunktionalität und gemeinsames Arbeiten über Abteilungsgrenzen hinaus.
Das ist aber kein Deal-Breaker. Nicht jede Abteilung muss agil werden. Bereiche wie Finance oder Controlling können gut klassisch organisiert bleiben. Aber dort, wo Produkte entwickelt werden, spielen die Stärken von Agilität eine große Rolle – etwa durch schnelle Prototypen, frühes Kundenfeedback und die Möglichkeit, Ideen schnell zu verproben und auch wieder zu verwerfen. Dabei muss man aushalten, dass agile Prozesse am Anfang etwas ineffizient sein können. Der Nutzen wird sich aber zeigen, sobald schnell erste Zwischenergebnisse geschaffen werden.
Apropos Ergebnisse: Gibt es einfache Quick Wins, die den Nutzen von agilen Prinzipien schnell sichtbar machen?
Ein sehr wirkungsvoller Quick Win ist die verkürzte Time-to-Market; also die Auslieferungs-Geschwindigkeit neuer Funktionen. Während klassische Projekte oft eine lange Konzeptphase durchlaufen und erst nach Jahren ein fertiges Produkt liefern, erlaubt Agilität, mit einem „Minimum Viable Product“ (MVP) sehr schnell erste Ergebnisse an die Kundschaft zu geben.
Statt also jahrelang an einer perfekten Lösung zu feilen, bringt man nach wenigen Monaten bereits ein eingeschränktes, aber funktionierendes Set an Funktionen auf den Markt – etwas, das die Kundschaft erst einmal testen oder direkt nutzen kann. Gerade für betriebswirtschaftlich denkende Stakeholder ist dieses Argument sehr überzeugend.
Welche agilen Methoden oder Frameworks eignen sich für den Einstieg, und warum?
Für den Einstieg eignet sich besonders Scrum, weil es ein sehr klares und leicht verständliches Rahmenwerk bietet. Die Regeln und Empfehlungen sind überschaubar, und Meeting-Formate wie Refinement oder Daily schaffen regelmäßig Raum, um über Anforderungen zu sprechen und gemeinsam Transparenz herzustellen.
Ein weiterer Vorteil sind die Sprints mit ihrem festen zeitlichen Horizont: Sie machen die Planung greifbar und leicht verständlich, auch für Teams, die bisher eher klassisch gearbeitet haben. Zudem hat jedes Meeting in Scrum einen klaren Zweck – das sorgt für Struktur und Orientierung.
Wichtig ist dabei: Man muss Scrum nicht nach Lehrbuch anwenden. Wenn es für ein Team sinnvoller ist, nur alle zwei Tage ein Daily zu machen, oder Planning und Refinement zu kombinieren, ist das völlig in Ordnung. Agilität lebt von Anpassung, nicht von starren Regeln.
Für den Start ist es außerdem hilfreich, jemanden mit Erfahrung im Framework dabei zu haben – etwa einen Agile Coach. Das erleichtert die Einführung enorm und sorgt dafür, dass das Team die Methode schnell produktiv nutzen kann.
Muss ich mit Scrum, OKR oder anderen Frameworks arbeiten, um agil zu sein?
Nein. Frameworks sind am Ende nur das: Rahmen, die einem dabei helfen können, die eigene Arbeit zu organisieren. Wie gesagt, sind bei Agilität die intrinsische Motivation, gesunder Menschenverstand und Lust an der Arbeitsweise viel wichtiger. Sind diese Werte gegeben, arbeitet das Team automatisch agiler, ob nun mit oder ohne Framework.
Hast du Tool-Tipps, die deiner Erfahrung nach für einfache agile Prozesse gut funktionieren?
Grundsätzlich braucht man eigentlich keine Tools. Man kann auch mit Post-Its an der Wand starten, um Aufgaben zu managen.
Wer digital arbeiten will, kann Whiteboards wie Mural oder Miro nutzen. Diese Tools bieten auch praktische Vorlagen für Scrum, Kanban oder OKR an. Es gibt natürlich auch andere fortgeschrittene Tools wie Jira, Confluence, oder auch Notion, aber die bringen etwas mehr Komplexität mit sich. Wer gerade erst den Einstieg ins agile Arbeiten findet, sollte mit der weißen Wand – live oder digital – starten.
Wer einen Überblick über die Anwesenheiten im Sprint-Team behalten will, profitiert von einem Personalmanagement-Tool wie Personizer. Gerade in hybriden Teams kann das Abstimmungsaufwände klein halten und macht transparent, wer wann wo arbeitet.
Welche typischen Widerstände beobachtest du bei der Einführung von Agilität? Wie überzeugt man Skeptiker vom Nutzen agiler Arbeit?
Die größten Widerstände bei der Einführung von Agilität entstehen aus Unwissenheit und Skepsis gegenüber Veränderungen. Veränderung im Unternehmen ist grundsätzlich erst einmal unbequem – gerade wenn bisherige Prozesse und Hierarchien infrage gestellt werden. Viele Mitarbeitende verbinden damit Unsicherheit.
Wichtig ist daher, mit denselben Prinzipien zu arbeiten, die Agilität ausmachen: Transparenz, Kommunikation und schrittweises Überzeugen durch Ergebnisse. Das bedeutet, den Nutzen von Agilität klar zu kommunizieren und ihn gleichzeitig mit konkreten Projektergebnissen erlebbar zu machen. Wenn Skeptiker sehen, dass sich Pläne ohnehin regelmäßig ändern und Agilität genau dafür eine flexible Lösung bietet, überzeugt das oft mehr als jedes Argument.
Ein weiterer Erfolgsfaktor ist, Menschen zu haben, die Agilität vorleben – die offen kommunizieren, Feedback annehmen, Fehler als Lernchance sehen und andere motivieren. Solche „Botschafter“ können helfen, Unsicherheit im Team abzubauen und Begeisterung zu wecken.
Gibt es aus deiner Sicht auch „Don’ts“, also Fehler, die man bei der Einführung von agilen Methoden vermeiden sollte?
Wichtig ist zu verstehen, dass man Menschen die Agilität nicht aufzwingen kann, wenn sie eigentlich keine Lust darauf haben. Wenn jemand klar signalisiert, dass er oder sie nicht agil arbeiten möchte, bringt es nichts, Überzeugungsarbeit bis ins Unendliche zu leisten. Im Gegenteil: solche Personen können schnell das ganze Team ausbremsen oder sogar die Stimmung vergiften. Agilität funktioniert nur dann, wenn die Beteiligten auch wirklich überzeugt von der Arbeitsweise sind. Wer nicht will, gehört schlicht nicht ins agile Team.
Ein weiterer häufiger Fehler ist der Glaube, man könne Agilität einfach durch die Einführung von Tools oder Frameworks erreichen. Aber nur, weil ein Unternehmen mit Jira arbeitet oder Scrum-Meetings einführt, ist es noch lange nicht agil. Agilität hat in erster Linie mit Mindset, Zusammenarbeit und Menschlichkeit zu tun – nicht mit Meeting-Formaten oder Frameworks.
Woran erkenne ich im Unternehmen, dass die agile Transformation auf dem richtigen Weg ist? Kann man das messbar machen?
Auf der Ebene einzelner Projekte kann man den Erfolg durchaus mit Kennzahlen messen – etwa über ein Burn-Down-Chart, das zeigt, ob der Arbeitsumfang im Sprint realistisch geplant war und wie gut das Team seine Ziele erreicht.
Die Transformation einer gesamten Organisation ist allerdings schwer in Zahlen zu fassen. Es gibt keinen Endzustand, der da heißt: „Agile Transformation abgeschlossen”.
Vielmehr geht es um eine kontinuierliche Entwicklung, die sich weniger in harten KPIs, sondern vor allem in den weichen Faktoren widerspiegelt: Offenheit, Feedback- und Fehlerkultur, Ehrlichkeit und Gemeinschaftlichkeit.
An diesen kulturellen Veränderungen erkennt man, dass Agilität wirkt. Wenn Teams mehr Wertschätzung und Selbstwirksamkeit erleben und Menschen gerne in diesem Umfeld arbeiten, ist das bereits ein starkes Indiz für eine erfolgreiche Transformation.
Wer es messbarer machen möchte, kann regelmäßige Mitarbeiterbefragungen nutzen: Wie nehmen die Mitarbeitenden Agilität wahr? Wie zufrieden sind sie mit Zusammenarbeit und Entscheidungsprozessen? Wichtig ist dann, dieses Feedback auch ernst zu nehmen und umzusetzen. Denn genau darin zeigt sich, ob das gesamte Unternehmen ein agiles Mindset verinnerlicht hat.
Welchen Rat würdest du einem Unternehmen geben, das zögert, erste Schritte in eine agilere Arbeitsweise zu gehen?
Hört auf zu zögern, macht einfach. Es tut nicht weh, mit einem kleinen Pilotprojekt zu starten und erste eigene Erfahrungen zu sammeln. Niemand muss gleich das gesamte Unternehmen umkrempeln – im Gegenteil, kleine Schritte sind oft der bessere Weg, weil sie zeigen, was funktioniert. Das inspiriert auch andere Team-Mitglieder.
Wichtig ist, es nicht komplizierter zu machen, als es ist. Man muss nicht erst alle Mitarbeitenden in Agilität schulen. Einfach ausprobieren, Erfahrungen sammeln, lernen und anpassen – das ist der Kern agiler Arbeit.
Und wenn unterwegs Fragen auftauchen oder zusätzliches Wissen gebraucht wird, kann man jederzeit Unterstützung von extern dazu holen, wie zum Beispiel durch einen Workshop bei AYVA.
Aber der entscheidende Schritt ist: Einfach anfangen!

“Agilität ist übertragbar auf alle Branchen, weil Agilität nicht das bloße Anwenden von agilen Methoden bedeutet. Vielmehr hängt sie von den Werten und dem Mindset im Team ab.”