FAQ

Grundlagen & Einstieg

Was bedeutet „agil arbeiten“?

Agil arbeiten heißt: in kurzen Zyklen Arbeit liefern, Feedback einholen und daraus lernen. Der Kern ist die Work-Feedback Loop – nicht ein bestimmtes Framework. Wer agil arbeitet, optimiert die Geschwindigkeit, mit der ein Team aus echtem Feedback bessere Entscheidungen trifft.

Mehr dazu: Agil arbeiten, Die Work-Feedback Loop

Was ist das Agile Manifest und ist es noch relevant?

Vier Werte, zwölf Prinzipien – formuliert 2001 und immer noch die beste Grundlage für agiles Arbeiten. Das Problem ist nicht das Manifest, sondern dass es kaum jemand gelesen hat. Wer die Prinzipien versteht, braucht weniger Framework-Diskussionen.

Mehr dazu: Agiles Manifest als Grundlage, Agiles Manifest in der Praxis, Agile Grundlagen Guide

Was ist die Work-Feedback Loop?

Ein Denkmodell: Work → Feedback → Entscheidung → veränderte Arbeit. Die zentrale Idee: Feedback ist nur dann Feedback, wenn es die nächste Arbeit tatsächlich verändert. Alles andere ist Reporting. Die WFL macht agiles Arbeiten greifbar – unabhängig vom eingesetzten Framework.

Mehr dazu: Die Work-Feedback Loop, WFL interaktiv, Feedback-Zyklus statt Frameworks, Kontext Work-Feedback Loop

Was ist die Feedback Response Time (FRT)?

Die FRT misst, wie schnell ein Team aus Feedback lernen kann: t(FRT) = t(signal) + t(decision) + t(deploy). Signal erkennen, Entscheidung treffen, umsetzen. Je kürzer die FRT, desto schneller lernt das Team. Das ist die härteste Metrik für Agilität.

Mehr dazu: Feedback Response Time, Feedback kommt zu spät, WFL interaktiv

Was bedeutet iteratives Vorgehen?

In kurzen Zyklen arbeiten, Ergebnisse zeigen, Feedback einholen, anpassen. Nicht monatelang planen und dann hoffen, dass es passt. Iteration bedeutet: Jeder Zyklus liefert ein Ergebnis, das getestet werden kann – und die nächste Iteration wird dadurch besser.

Mehr dazu: Iteratives Vorgehen, Iteration & Feedback

Brauche ich ein Framework wie Scrum oder Kanban?

Frameworks sind Werkzeuge, nicht Religion. Verstehe zuerst die Prinzipien dahinter – dann wähle das Framework, das zu deinem Kontext passt. Oder bau dir was Eigenes. Wer Scrum einführt, ohne die Prinzipien zu verstehen, macht Cargo Cult.

Mehr dazu: Kanban vs. Scrum, Agiles Arbeiten erfolgreich umsetzen, No-Bullshit Kanban Guide

Methoden & Praxis

Was ist der Unterschied zwischen Scrum und Kanban?

Scrum arbeitet in festen Sprints mit definierten Rollen und Events. Kanban optimiert den Flow mit WiP-Limits und Pull-Prinzip. Scrum gibt mehr Struktur, Kanban mehr Flexibilität. Beides kann funktionieren – die richtige Wahl hängt vom Kontext ab, nicht von Glaubensfragen.

Mehr dazu: Kanban vs. Scrum, No-Bullshit Kanban Guide, Scrum ist nicht das Problem

Warum funktionieren unsere Daily Standups nicht?

Weil sie zum Statusbericht verkommen. „Was habe ich gestern gemacht“ interessiert niemanden. Walk the Board: Geht die Tickets von rechts nach links durch und klärt, was blockiert ist. Fokus auf Flow, nicht auf Rechtfertigung.

Mehr dazu: Warum Dailys scheitern, Daily Scrum für Entwickler

Brauchen wir Story Points?

Story Points sind massiv überbewertet. Teams verbringen Stunden mit Schätz-Poker, während Cycle Time und Throughput bessere, objektivere Daten liefern. Wenn ihr schätzen wollt: T-Shirt-Sizes reichen. Aber misst lieber, statt zu raten.

Mehr dazu: Das Ende der Schätzung, Story-Point-Unsinn

Was bringt Backlog Refinement wirklich?

Das Refinement ist das wichtigste Event im Sprint. Gut gemacht: Planning dauert 30 Minuten, Stories sind klar, das Team hat Kontext. Schlecht gemacht: Der Sprint startet im Chaos, Fragen tauchen erst beim Coden auf. Investiert hier Zeit – es zahlt sich doppelt aus.

Mehr dazu: Backlog Refinement Technik

Was ist eine Definition of Done?

Euer Qualitätsversprechen als Team. Die DoD definiert, wann ein Ticket wirklich fertig ist – nicht „Code geschrieben“, sondern getestet, reviewed, dokumentiert, deploybar. Ohne DoD entscheidet jeder selbst, was „fertig“ heißt. Das endet immer in Nacharbeit.

Mehr dazu: Definition of Done in der Praxis

Wie geht man mit zu großen Stories um?

Horizontal schneiden: Jeder Slice liefert eigenständig Wert und kann unabhängig deployed werden. Kleine Stories bedeuten schnelleres Feedback, bessere Planbarkeit und weniger Risiko. Wenn eine Story nicht in einen Sprint passt, ist sie keine Story – sie ist ein Epic.

Mehr dazu: Wie schlimm sind große Stories?, Kleine Stories machen Sinn, Umgang mit unterschiedlich großen Stories

Was sind WiP-Limits und warum sind sie wichtig?

WiP-Limits begrenzen die parallele Arbeit im Team. Euer Team ist nicht langsam – es ist überladen. Weniger gleichzeitige Arbeit bedeutet schnelleren Durchfluss, weniger Kontextwechsel und früheres Feedback. WiP-Limits sind das einfachste Werkzeug mit dem größten Hebel.

Mehr dazu: WiP-Limit Simulator, Warum dein Team nicht langsam ist, Regeln explizit machen

Was bringen Retrospektiven?

Nur dann etwas, wenn konkrete Maßnahmen entstehen und umgesetzt werden. Eine Retro ohne Follow-up ist ca. 1.200 € verbranntes Budget pro Durchführung. Weniger reden, mehr committen. Lieber eine Maßnahme umsetzen als zehn besprechen.

Mehr dazu: Deine Retro: 1.200 € für die Tonne?

Was ist Dimensional Planning?

Eine Alternative zur klassischen Planung mit fixen Endterminen. Statt „alles bis Datum X“ plant ihr in Dimensionen: Must, Should, Nice. Das Team liefert garantiert die Must-Items, der Rest wird nach Kapazität gezogen. Ehrlicher und realistischer als jeder Gantt-Chart.

Mehr dazu: Dimensional Planning erklärt, Agile Projektplanung

Welche Metriken sind in agilen Teams sinnvoll?

Cycle Time, Throughput und Feedback Response Time. Diese drei Metriken zeigen, wie schnell euer Team liefert und lernt. Finger weg von Velocity als Leistungsindikator – das führt zu Inflation und Gaming statt zu besserer Arbeit.

Mehr dazu: Feedback Response Time, CyleNivo: Ein Werkzeug, kein Cockpit

Teams & Führung

Was macht ein gutes agiles Team aus?

Klare Vision, psychologische Sicherheit, Selbstorganisation und ein gemeinsames Qualitätsverständnis. Gute Teams brauchen keine Aufsicht – sie brauchen Kontext, Vertrauen und die Freiheit, Entscheidungen zu treffen. Alles andere regeln sie selbst.

Mehr dazu: Agile Teams: Voraussetzungen, Agile Teams: Führung

Wie führt man ein agiles Team?

Der Spagat zwischen Gestalten und Loslassen. Servant Leadership statt Command & Control: Hindernisse räumen, Rahmen schaffen, Entscheidungen ermöglichen – nicht vorgeben. Die schwierigste Führungsaufgabe ist, nicht einzugreifen, wenn das Team es selbst lösen kann.

Mehr dazu: Gestalten und Loslassen, Agile Führung, Agil arbeiten, agil führen

Warum ist Vertrauen so wichtig für agile Teams?

Ohne Vertrauen keine Selbstorganisation. Micromanagement killt Motivation und Code-Qualität gleichzeitig. Teams, die Fehler machen dürfen, lernen schneller. Teams, die kontrolliert werden, liefern nur das Minimum.

Mehr dazu: Vertrauen statt Micromanagement, Vertrauen

Welche Rolle spielen Stakeholder im agilen Prozess?

Aktive Akteure, nicht passive Zuschauer. Stakeholder müssen agiles Arbeiten verstehen, regelmäßig Feedback geben und Prioritäten mittragen. Wer nur am Ende eines Projekts auftaucht und alles ändern will, hat agiles Arbeiten nicht verstanden.

Mehr dazu: Agiles Arbeiten: Stakeholder, Die Rolle des Product Owners

Was ist ein guter Product Owner?

Jemand mit echtem Kundenwissen und Entscheidungsbefugnis. Ein PO, der jede Entscheidung eskalieren muss, bremst das Team. Ein PO ohne Kundenkontakt rät nur. Gute POs sind keine Backlog-Verwalter – sie sind Produktstrategen mit Mandat.

Mehr dazu: Die Rolle des Product Owners

Transformation & Kultur

Warum scheitern agile Transformationen?

Weil sie sich auf Methoden konzentrieren statt auf Kultur. Scrum einführen ohne Vertrauen, Fehlerakzeptanz und echtes Empowerment ist wie ein Auto kaufen, ohne fahren zu lernen. Transformation braucht Haltungsänderung, nicht nur Prozessänderung.

Mehr dazu: Agile Transformation: Kultureller Wandel, Agile Transformation

Ist das Label „Agile“ verbrannt?

Ja – durch Zertifikats-Mühlen, Agile-Theater und Berater, die Frameworks verkaufen statt Handwerk zu lehren. Und nein – weil die Prinzipien dahinter relevanter sind denn je. Das Label ist beschädigt, das Handwerk nicht.

Mehr dazu: Ist das Label verbrannt?, Agiles Arbeiten: Einfach und schwer

Was ist der „Agile Eisberg“?

Die sichtbaren Methoden – Scrum, Kanban, SAFe – sind nur die Spitze. Darunter liegen Werte, Prinzipien und Haltung. Wer nur die Spitze kopiert, ohne den Eisberg zu verstehen, macht Cargo Cult Agile. Die echte Arbeit passiert unter der Wasserlinie.

Mehr dazu: Der Agile Eisberg

Für Entwickler:innen

Was bringt agiles Arbeiten Entwickler:innen?

Mehr Fokuszeit, weniger sinnlose Meetings, bessere Code-Qualität – wenn es richtig gemacht wird. Agil heißt nicht „mehr Meetings“, sondern bessere Meetings und klarere Prioritäten. Entwickler:innen profitieren vor allem von kürzeren Feedback-Zyklen und weniger Kontextwechseln.

Mehr dazu: Agile für Entwickler

Warum wollen gute Entwickler:innen keine Tickets abarbeiten?

Weil sie mitdenken wollen. Gute Devs brauchen Kontext, Autonomie und Einfluss auf das Was – nicht nur das Wie. Wer Entwickler:innen zu reinen Ticket-Abarbeitern degradiert, verliert die Besten zuerst. Beteiligung am Produkt ist kein Nice-to-have.

Mehr dazu: Warum Entwickler keine Tickets abarbeiten wollen

Was sind technische Schulden und wie baut man sie ab?

Bewusste oder unbewusste Kompromisse bei der Code-Qualität. Technische Schulden aufzustauen ist wie Zinsen auf einen Kredit: Irgendwann zahlt ihr mehr für Zinsen als für Features. Regelmäßig adressieren, nicht als eigenes Projekt aufschieben.

Mehr dazu: Technische Schulden

KI & Agiles Arbeiten

Kann KI agiles Arbeiten verbessern?

KI reduziert Mental Load bei Routineaufgaben: Dokumentation, Code-Reviews, Testgenerierung. Aber schneller produzieren heißt nicht produktiver sein. Der Feedback-Zyklus mit echten Nutzern bleibt der Engpass – und den kann keine KI abkürzen.

Mehr dazu: KI: Realistischer Einsatz, Schneller ≠ produktiver

Ist AI Coding eine Gefahr für Software-Qualität?

AI Coding ist wie ein Azubi im zweiten Lehrjahr: brauchbare Ergebnisse, braucht aber Anleitung und Review. Ohne erfahrene Entwickler:innen, die den Output prüfen, entsteht technische Schuld im Akkord. Das Tool ist gut – blind vertrauen darf man ihm nicht.

Mehr dazu: AI Coding: Ein Azubi macht noch keinen Entwickler, AI-Entwicklung 2026: Kritisch ja, blind nein