A–Z des agilen Arbeitens

Boardregeln sind die ausgesprochenen Vereinbarungen darüber, wann eine Aufgabe eine Spalte verlassen darf. Explizit gemacht klingen sie nach Bürokratie, sind aber wichtiger als ein hübsches Layout.

Continuous Delivery heißt, Software jederzeit auf Knopfdruck in Produktion bringen zu können. Automatisierte Pipelines für Build, Test und Deployment sind der Schlüssel zu kurzen Feedback-Zyklen.

Die vier DORA-Metriken messen Software-Delivery-Performance und gelten als Goldstandard dafür. DORA warnt in der eigenen Dokumentation ausdrücklich davor, sie zu Zielen zu machen. Sie sollen zeigen, wo es hakt, nicht wer schneller ist.

Der Engpass ist der Faktor, der die Anpassungsgeschwindigkeit eines Systems am stärksten begrenzt. Nach der Theory of Constraints bestimmt immer die engste Stelle die Leistungsfähigkeit des Ganzen. Ein Board macht sichtbar, wo sie sitzt. Alles, was du anderswo verbesserst, verpufft.

Flight Levels sind ein Modell von Klaus Leopold. Es unterscheidet Flughöhen, von der operativen Team-Ebene bis zur Strategie. Der Zweck: Verbesserung hört nicht an der Grenze eines einzelnen Teams auf.

Flow ist der Fluss der Arbeit durch dein System. Dein Board bildet ihn ab, nicht andersherum. Wer die Spalten ändert, ohne die Arbeit zu ändern, hat nichts verbessert.

Flow-Messung heißt, den Wertstrom mit wenigen Kennzahlen zu beobachten statt mit vielen. Drei reichen: Cycle Time, Durchsatz und angefangene Arbeit. Wer seinen Wertstrom verbessern will, muss ihn vorher messen.

Kanban ist in seinem Kern radikal einfach. Es schreibt dir nicht vor, wie du arbeiten sollst, sondern setzt an dem an, wie du bereits arbeitest. Das Versprechen dahinter lautet: Hört auf, Neues anzufangen, und fangt an, Angefangenes fertigzustellen.

Der Service Delivery Manager, oft Flow Master genannt, kümmert sich um die rechte Seite des Boards: den reibungslosen Fluss der Arbeit durch das System.

Der Service Request Manager kümmert sich um die linke Seite des Boards, also um alles, was vor dem Arbeitsbeginn passiert. Er sorgt dafür, dass die Aufgaben in der richtigen Reihenfolge angegangen werden.

Ein Service Level Agreement ist die Zusage, in welcher Zeit eine bestimmte Art von Anfrage bearbeitet wird. In Kanban bildest du solche Zusagen über Serviceklassen ab.

Velocity misst, wie viel ein Team pro Sprint abarbeitet, gerechnet in Story Points. Das ist Output, nicht Wert. Als Gefühl für die eigene Geschwindigkeit taugt die Zahl, als Fortschrittsmaß nicht: Fortschritt zeigt sich an funktionierender Software.

Walking the Board heißt, im Daily nicht reihum die Menschen zu fragen, sondern das Board von rechts nach links durchzugehen. Der Blick wechselt von der einzelnen Aufgabe zum Fortschritt des Teams.

Der WiP-Limit-Simulator ist ein selbst entwickeltes Werkzeug, um Teamabläufe zu verstehen. Er zeigt grafisch, wie unterschiedliche Limits Durchsatz und Durchlaufzeit verändern.

Work in Progress ist die Menge an Arbeit, die ein Team gleichzeitig angefangen hat. Zu viele hohe Prioritäten treiben sie hoch, und am Ende steht ständiges Kontext-Switching und Stillstand.

Zustand hoher Produktionsgeschwindigkeit bei niedriger Feedback-Geschwindigkeit. Das System produziert kontinuierlich, erhält jedoch verzögertes oder schwaches Feedback.

Strukturelle Fähigkeit eines Systems, auf veränderte Umweltbedingungen zu reagieren. Adaptivität beschreibt keine Haltung oder Kultur, sondern die tatsächliche Möglichkeit zur Anpassung.

Zeitliche Synchronisation zwischen verschachtelten Rückkopplungsebenen (z. B. Strategie, Koordination, Operation).

Zustand schneller operativer Loops bei träger strategischer oder kapitalbezogener Loop. Operative Dynamik ist vorhanden, strategische Anpassung bleibt aus.

Entscheidungs-Latenz ist die Zeitspanne zwischen dem Moment, in dem ein relevantes Signal sichtbar wird, und dem Moment, in dem jemand verbindlich entscheidet. Wird sie größer als der Takt, in dem produziert wird, läuft die Entscheidung der Arbeit hinterher.

Feedback ist die beobachtbare Reaktion der Realität auf eine Handlung. Informativ wird sie erst durch den Abgleich mit der Handlungsabsicht. Feedback ist kein Meeting, keine Meinung und keine Planung, sondern eine reale Wirkung, die ins System zurückfließt.

Zeit, bis eine reale Wirkung als relevantes Signal im System sichtbar wird.

Gesamtdauer zwischen Signalentstehung und wirksamer Anpassung, bestehend aus: Zeit bis zur Sichtbarkeit des Signals, Zeit bis zur Entscheidung und Zeit bis zur Umsetzung. Beschreibt die zeitliche Dynamik der geschlossenen Loop.

Zustand hoher Feedback-Geschwindigkeit bei niedriger Work-Geschwindigkeit. Probleme werden gut erkannt, aber das System kann Erkenntnisse nicht schnell genug in veränderte Arbeit übersetzen.

Eine geschlossene Loop liegt vor, wenn Arbeit eine reale Wirkung erzeugt, diese Wirkung als Signal sichtbar wird, das Signal gegen die Handlungsabsicht abgeglichen wird und daraus eine Entscheidung folgt, die die nächste Arbeit verändert. Nur geschlossene Loops sind adaptiv.

Zeitspanne, in der ein Feedback-Signal handlungsleitend bleibt. Überschreitet die Feedback Response Time dieses Fenster, verliert das Signal strukturell an Relevanz.

Die Erwartung, welche Wirkung Arbeit erzielen soll. Macht Feedback bewertbar, indem sie einen Referenzpunkt für den Abgleich mit beobachteten Signalen liefert. Muss klar genug sein, um Feedback bewertbar zu machen, und offen genug, um unerwartete Signale zuzulassen.

Strukturelle Kopplung zwischen Kapitalallokation und operativer Realität.

Zeitkonstante der Kapitalallokation. Bestimmt, wie oft finanzielle Rahmenbedingungen angepasst werden können.

Zustand synchronisierter Work- und Feedback-Geschwindigkeit. Arbeit erzeugt Wirkung, Wirkung verändert Entscheidungen.

Strukturelle Möglichkeit eines Systems, aus Realität zu lernen. Beschreibt Architektur und Kopplung – nicht Performance.

Frequenz, mit der Arbeit erzeugt wird, die reale Wirkung entfalten kann.

Mindestwert eines Signals, ab dem es noch handlungsleitend wirkt.

Strukturelle Beziehung zwischen Handlung und Wirkung, bei der Wirkung zukünftige Handlung beeinflusst.

Das Schwungrad-Prinzip ist ein einfaches, mächtiges mentales Modell. Es zeigt, wie sich Vertrauen in nachhaltige, positive Team-Energie umwandeln lässt.

Zustand niedriger Produktions- und niedriger Feedback-Geschwindigkeit. Weder Bewegung noch Anpassung sind signifikant.

Zustand hoher Kapital- oder Entscheidungs-Latenz bei gleichzeitig hoher operativer Geschwindigkeit.

Zustand, in dem mindestens eine Kopplung zwischen Arbeit, Handlungsabsicht, Feedback, Entscheidung und zukünftiger Arbeit fehlt. Produktivität ist möglich, Adaptivität nicht.

Mehrere Rückkopplungsebenen mit unterschiedlichen Zeitkonstanten (z. B. Strategie, Koordination, Operation).

Handlung mit realer Wirkung in der Umwelt des Systems. Interne Aktivität ohne externe Wirkung gilt im Modell nicht als Work.

Adjourning ist eine spätere Ergänzung zum Tuckman-Modell und beschreibt die Auflösung eines Teams. Wichtiger als der Name ist der Befund dahinter: Sobald sich am Team etwas ändert, beginnt der ganze Zyklus wieder von vorn.

AgileEcho ist ein selbst entwickeltes Werkzeug, mit dem Teams anonymes Feedback sammeln, um ihre Zusammenarbeit zu verbessern.

Aktives Zuhören heißt, den Impuls zu unterdrücken, sofort zu antworten. Es bringt dir Informationen, die dir sonst entgehen, und verbessert die Qualität jedes Gesprächs im Team.

Ein Barcamp ist eine Veranstaltung ohne festes Programm: dezentral, von den Teilnehmern gestaltet und dynamisch. Wer kommt, bringt die Themen mit.

Burnout ist das Ergebnis eines Tempos, das ein Team nicht halten kann. Dagegen hilft kein Erholungsprogramm, sondern ein konstantes Arbeitstempo, mit dem sich auch nächsten Monat noch gute Arbeit liefern lässt.

Das Delegation Board hält fest, was im Delegation Poker vereinbart wurde: wer welche Entscheidung trifft. Es dokumentiert die getroffenen Entscheidungen und schafft Transparenz. Und es ist eure Landkarte durch die Autonomie-Stufen des Hackman-Modells.

Delegation Poker ist ein Werkzeug von Jürgen Appelo, mit dem ein Team klärt, wer welche Entscheidung trifft. Es macht aus dem vagen Wunsch nach mehr Verantwortung eine Vereinbarung, die alle sehen können.

Elastic Leadership ist ein Modell von Roy Osherove. Es gibt nicht den einen richtigen Führungsstil, sondern drei Modi, zwischen denen du wechselst. Im Survival-Modus führst du eng, im Self-Organizing-Modus greifst du nur noch ein, wenn es nötig ist.

Eine gesunde Fehlerkultur ist das Sicherheitsnetz, das einem Team mutige Entscheidungen überhaupt erst erlaubt. Die schlechte erkennst du an den Sätzen: „Das war ich nicht“ und „Wer ist schuld?“. Wo nach Schuld gesucht wird, riskiert bald niemand mehr etwas.

Das Hackman-Modell skizziert vier Reifegrade der Teamautonomie. Es hilft dir zu verstehen, wo dein Team steht und welche Rahmenbedingungen es braucht. Welche Führung passt, hängt direkt von dieser Stufe ab.

Konsens fragt: Sind alle dafür? Das Ziel ist die volle Zustimmung aller, und genau darin liegt die Falle. Wer auf Einstimmigkeit wartet, bekommt meistens den kleinsten gemeinsamen Nenner oder gar keine Entscheidung.

Konsent fragt: Hat jemand einen schwerwiegenden Einwand? Gesucht wird nicht Zustimmung, sondern die Abwesenheit von begründetem Widerstand. Niemand muss die Sache lieben, es reicht, wenn sie niemandem die Arbeit zerstört.

Meeting-Kultur meint, wie in einer Organisation Termine angesetzt, geführt und beendet werden. Das Ziel ist, mit weniger Terminen mehr zu erreichen.

Mikromanagement heißt, dass sich die Führungsebene in die tägliche Arbeit des Teams einmischt, statt ihr den Rahmen zu geben und zu vertrauen. Es ist kein Führungsstil, sondern das, was übrig bleibt, wenn Vertrauen fehlt.

Norming ist die dritte Phase im Tuckman-Modell. Das Team reißt sich zusammen und stellt Regeln auf, wie man miteinander umgeht.

Das One-on-One ist ein regelmäßiges Gespräch zwischen Führungskraft und Teammitglied und das wichtigste Ritual agiler Führung. Es geht nicht darum, was jemand getan hat. Die bessere Frage lautet: Worüber reden wir gerade nicht, worüber wir reden sollten?

Open Space ist ein Format für selbstorganisierten Wissensaustausch im Team. Während Peer Feedback auf das Lernen des Einzelnen zielt, geht es hier um das kollektive: Was einer weiß, sollen die anderen wissen können.

Peer Feedback ist Rückmeldung unter Kollegen auf gleicher Ebene, nicht von oben. Es zielt auf das individuelle Wachstum und ist am Anfang ungewohnt, weil es Mut kostet.

Performing ist die vierte Phase im Tuckman-Modell. Das Team ist durch den Zyklus durch und arbeitet gut miteinander.

Selbstorganisation heißt, dass ein Team seine Arbeit selbst einteilt und entscheidet, was als Nächstes dran ist. Sie ist kein Zustand der Anarchie, sondern das Ergebnis eines klaren Rahmens. Und sie hängt an einer unscheinbaren Fähigkeit: Arbeit in kleine, handhabbare Teile zu zerlegen.

Die Sechs Denkhüte sind eine Methode für komplexe Entscheidungen, bei denen viele Perspektiven eine Rolle spielen. Alle im Team nehmen nacheinander dieselbe Sichtweise ein: analytisch, emotional, kritisch, optimistisch, kreativ und auf Meta-Ebene.

Storming ist die zweite Phase im Tuckman-Modell. Die Maske fällt, die Konflikte werden offener, und es kann auch mal zu unangenehmen Worten kommen.

Ein Team ist die Stelle, an der das Wissen über die tägliche Arbeit liegt. Als Führungskraft wirst du die Prozesse deines Teams nie so tief durchdringen wie die Menschen, die täglich darin arbeiten. Daraus folgt die Aufgabe: Raum schaffen, statt Lösungen vorzugeben.

Das Team Canvas ist ein Workshop-Format, das Teamdynamik und Ziele auf einer Fläche sichtbar macht. Es bringt alle auf denselben Stand, bevor über einzelne Aufgaben geredet wird.

Vertrauen ist ein Vorschuss. Es entsteht nicht durch ein Bekenntnis, sondern durch Freiraum, den jemand tatsächlich abgibt. Die wichtigste Aufgabe von Führung ist, diesen Raum zu schaffen. Fehlt er, bleiben Mikromanagement und sinkende Wirksamkeit.

Akzeptanzkriterien sind die Bedingungen, die erfüllt sein müssen, damit der Product Owner eine Story abnimmt. Beim Hausbau wären das die Farbe der Wände und die Anzahl der Zimmer.

Das Backlog ist das Sammelbecken für alle rohen Ideen, Wünsche und Anforderungen. Seine Reihenfolge ist die eigentliche Aussage. Wenn jedes Feature Prio 1 bekommt, steht nach einem Monat ein Backlog mit zwanzig Prio-1-Einträgen da, und die Reihenfolge ist wieder offen.

Eine feste Deadline für ein komplexes Projekt ist im Grunde eine Wette gegen die Realität. Sie ist ein zweischneidiges Schwert. Wer nach dem Termin für das Gesamtprojekt gefragt wird, bietet besser keine große, vage Zahl an.

Dimensional Planning klärt das Wann, nachdem das User Story Mapping das Was geklärt hat. Zusammen nehmen die beiden Werkzeuge dem Kunden die Angst vor der Planlosigkeit.

Ein Epic ist eine große Anforderung, die in mehrere Stories zerfällt. Ob etwas Epic, Story oder Task heißt, ist zweitrangig. Am Ende gibt es eine Aufgabe, die jemand erledigen muss.

Ein Impediment ist ein Hindernis, das die Arbeit blockiert. Ein Board macht Blocker sofort sichtbar, damit sie im Zusammenhang der Arbeit besprochen werden statt in einem eigenen Termin.

Iterative Entwicklung heißt, in kurzen Zyklen zu arbeiten: planen, umsetzen, testen, liefern. Wenn du nur ein einziges agiles Konzept verstehen müsstest, dann dieses.

Ein Lastenheft beschreibt vorab, was geliefert werden soll. Das ist nicht per se falsch. Falsch wird es, wenn man sich starr daran hält, statt mit dem Kunden zusammenzuarbeiten.

Priorisierung heißt, eine Reihenfolge festzulegen und sie zu verantworten. Maßstab ist der echte Geschäftswert, nicht die Lautstärke der Anfrage. Viele Systeme scheitern nicht daran, dass zu langsam geliefert wird, sondern daran, dass niemand verbindlich entscheidet.

Das Product Backlog ist die geordnete Liste dessen, was am Produkt getan werden soll. Der Product Owner verantwortet die Reihenfolge und sorgt dafür, dass sie für alle sichtbar und verständlich ist.

Agile Projektplanung beantwortet die Frage nach dem Fertigtermin mit gemessener Geschwindigkeit statt mit einer Zusage. Aus der Velocity entwickelst du ein Gefühl dafür, was dein Team schafft.

Im Sprint Planning entscheidet ein Team, was es im nächsten Sprint umsetzt. Es reicht, die Aufgaben so weit verstanden zu haben, dass das Ziel klar ist. Der eigentliche Wert liegt in der Diskussion, die dabei entsteht.

Das Sprintziel sagt, worauf ein Sprint hinauslaufen soll. Es zu formulieren ist schwierig und trotzdem wichtig: Ohne Ziel kann sich ein Team auf nichts festlegen, und das Daily hat nichts zu beobachten.

Stakeholder sind die Menschen mit einem Anspruch an das Ergebnis: Kunden, Fachexperten, Kollegen aus anderen Bereichen. Sie sind mehr als passive Zuschauer. Ihr Bedürfnis nach Planung und Sicherheit ist legitim, und du kannst es erfüllen, ohne Flexibilität und Lernen aufzugeben.

Task-Splitting ist das gemeinsame Zerlegen einer großen Anforderung in kleine Tasks und Stories. Es ist mehr als eine technische Übung: Beim Zerlegen bringen alle ihre Erfahrung ein, und Missverständnisse fallen vorher auf statt hinterher.

Eine User Story ist kein Anforderungsdokument. Sie ist ein Versprechen für ein Gespräch. Das Was und Warum kommt vom Kunden, das Wie findet das Team. Wer die Lösung schon in die Story schreibt, nimmt dem Team die Expertise ab, für die es da ist.

User Story Mapping zeichnet die große Landkarte eines Projekts. Es klärt gemeinsam mit Kunde und Team, was entstehen soll, bevor irgendjemand über Termine redet.

User Tests beschreiben Schritt für Schritt, was ein Nutzer im Produkt tut. Große Tests werden in kleinere Teile zerlegt und nach Priorität geordnet.

WSJF steht für Weighted Shortest Job First und priorisiert nach Wert, Kosten und Dringlichkeit. Kurze, wertvolle Arbeit kommt zuerst.

Agile at Scale meint agiles Arbeiten über ein einzelnes Team hinaus. Der größte Feind der Skalierung ist die Haltung, dass nur du selbst es richtig machen kannst.

Ein Agile Coach begleitet Teams beim agilen Arbeiten, oft als neutraler Moderator. Die Rolle steht unter Rechtfertigungsdruck, zuletzt durch die Behauptung, KI werde sie ersetzen.

Eine agile Transformation ist der umfassende Wandel einer Organisation hin zu agilen Prinzipien und Arbeitsweisen. Sie ist mehr als die Einführung von Scrum oder Kanban, und genau diese Verwechslung ist der häufigste Fehler dabei.

Agile Verwaltung meint agiles Arbeiten in Behörden und öffentlichen Einrichtungen. Der Ansatz stammt aus der Softwareentwicklung und wird heute in vielen Branchen angewendet.

Das Daily ist ein kurzes tägliches Treffen, in dem ein Team seine Arbeit für den Tag plant. Es ist kein Statusreport für einen Vorgesetzten. Wenn reihum berichtet wird, was jeder gestern getan hat, ist es ein Ritual ohne Zweck.

Extreme Programming ist ein agiler Ansatz, der älter ist als das agile Manifest. Von ihm stammt der Gedanke, auf äußere Einflüsse zu reagieren, statt stur einem Plan zu folgen.

Der Product Owner entscheidet, was als Nächstes gebaut wird. Dazu gehören enger Kontakt zu Kunden und Stakeholdern, die Übersetzung ihrer Bedürfnisse in Stories und ein Backlog, das fortlaufend neu geordnet wird. Das Was und Warum kommt von dort, das Wie bleibt beim Team.

Die Retrospektive ist der Termin, in dem ein Team seine Zusammenarbeit prüft und ändert. Sie ist kein Kummerkasten und keine Therapiesitzung. Ohne Folgeschritt ist sie teuer: rund 1.200 € verbranntes Budget pro Durchführung.

Scrum ist das bekannteste agile Framework und zugleich das am häufigsten missverstandene. Es ist älter als das agile Manifest. Viele Teams greifen danach, weil Regeln und Rollen klar aufgeschrieben sind. Klarheit über Regeln ist aber nicht dasselbe wie Klarheit über den Zweck.

Der Scrum Master moderiert Prozesse, beseitigt Hindernisse und unterstützt das Team dabei, sich selbst zu organisieren. Die Rolle entsteht nicht durch ein Zertifikat. Nach einer Woche Schulung ist niemand Meister, und der Titel sagt nichts darüber, ob die Arbeit tatsächlich getan wird.

Shuhari ist ein japanisches Konzept aus dem Kampfsport und beschreibt einen Lernweg in drei Stufen: erst die Regeln verstehen, dann anpassen, schließlich meistern. Meisterschaft kommt nach den Regeln, nicht davor.

Agiles Arbeiten ist die tägliche Praxis, die eine Haltung mit Leben füllt. Die Haltung selbst heißt Agilität. Der Unterschied ist kein Wortspiel: Eine Haltung kannst du behaupten, eine Praxis siehst du daran, was ein Team am Dienstagmorgen tut.

Das agile Mindset ist das Verständnis der Prinzipien hinter den Praktiken. Wer es hat, befolgt nicht Regeln, sondern weiß, wofür sie da sind. Der Weg dorthin ist langsam und der einzige, der nachhaltig trägt.

Künstliche Intelligenz wird derzeit so hitzig wie substanzlos diskutiert, auch im agilen Feld. Die Behauptung, sie ersetze agile Coaches und Scrum Master, hält sich hartnäckig. Der untere Teil des agilen Eisbergs bleibt aber eine zutiefst menschliche Domäne.

Kontinuierliche Verbesserung, japanisch Kaizen, ist die Verpflichtung, aus dem Beobachteten zu lernen und sich ständig zu verbessern. Du schaust dabei permanent auf deine Produkte und auf deine Prozesse und fragst, was ihr besser machen könnt.

Value-Based-Pricing heißt, Arbeit nach ihrem Wert für den Kunden zu berechnen statt nach aufgewendeten Stunden.

Vibe Coding heißt, Software weitgehend von einer KI schreiben zu lassen und das Ergebnis nach Gefühl zu beurteilen. In seiner Reinform ignoriert es sämtliche Lektionen der letzten zwanzig Jahre.