ATDD ist ein praxisnaher Ansatz, um Anforderungen vor der Implementierung in Form von Akzeptanztests zu präzisieren. Richtig angewandt, fördert es Qualität, Transparenz und Zusammenarbeit. In Kombination mit TDD und BDD schafft ATDD eine konsistente Brücke von der Entwickler- zur Kundensicht.
ADKAR macht Veränderung auf Einzelebene steuerbar. Richtig eingebettet – iterativ, führungsstark, ergänzt durch System- und Strukturhebel – schließt es die Lücke zwischen Projektmeilenstein und tatsächlichem Verhalten.
Antifragility beschreibt die Fähigkeit von Organisationen, durch Störungen stärker zu werden. Während Resilienz Stabilität sichert, ermöglicht Antifragilität Entwicklung und Innovation unter Unsicherheit. Richtig eingesetzt – durch Experimente, Optionalität und eine passende Kultur – wird Antifragilität zu einem strategischen Vorteil in volatilen Märkten.
ADDIE bietet für Change und Transformation eine klare, belastbare Struktur: Analyse, Design, Entwicklung, Implementierung und Evaluation. Richtig eingesetzt – iterativ und kombiniert mit anderen Change-Ansätzen – steigert es die Erfolgswahrscheinlichkeit und führt zu nachhaltigen Ergebnissen.
Das Agile Manifest ist ein Grundlagendokument der agilen Bewegung, veröffentlicht im Februar 2001 von 17 Software-Fachleuten in Snowbird, Utah. Es beschreibt Werte und Prinzipien, die als Gegenentwurf zu schwergewichtigen, plangetriebenen Vorgehensmodellen entstanden sind. Statt auf detaillierte Prozesse und Werkzeuge setzt das Manifest auf Menschen, Zusammenarbeit, funktionierende Ergebnisse und Anpassungsfähigkeit.
Das ART Planning Board ist ein zentrales Transparenz- und Alignment-Werkzeug im SAFe PI Planning. Es schafft Klarheit über Features, Iterationen und Abhängigkeiten und ermöglicht so eine realistische, abgestimmte Planung. Auch jenseits von SAFe lässt sich das Prinzip einsetzen, um Schnittstellen und Abhängigkeiten zwischen Teams oder Abteilungen zu steuern.
Die ACMP Standard Methodology ist ein globaler Referenzrahmen für professionelles Change Management. Ihre fünf Prozessgruppen decken den gesamten Veränderungszyklus ab – von der Analyse über Strategie und Planung bis zur nachhaltigen Verankerung. Dank methodischer Neutralität lässt sie sich mit Modellen wie ADKAR oder Kotter kombinieren. Durch die CCMP-Zertifizierung, breite Anwendung in der Praxis und den Einsatz bei Beratungen wie CALADE trägt der Standard maßgeblich zur Professionalisierung von Veränderungsarbeit bei.
Der Agile Release Train (ART) ist ein zentrales Konstrukt im Scaled Agile Framework (SAFe). Er beschreibt ein langfristig bestehendes, cross-funktionales Team-of-Teams (meist 50–125 Personen), das gemeinsam einen Wertstrom („Value Stream“) bedient. Ein ART liefert in festen Takten – den Program Increments (PI) – kontinuierlich Wert an Kunden und Stakeholder.
Der Begriff „Train“ verdeutlicht: Alle Teams steigen gemeinsam ein, fahren im gleichen Rhythmus und liefern synchronisierte Ergebnisse.
Ambidextrous Organizations vereinen Effizienz im Kerngeschäft mit radikaler Innovation. Sie sind ein Balanceakt zwischen Stabilität und Wandel – mit großem Potenzial, aber auch erheblichen Risiken und Spannungen.
Die Summe der Erwartungen aller Stakeholder an ein Produkt wird als Anforderungen ausformuliert. Eine Anforderung beschreibt immer eine bestimmte Funktion oder Eigenschaft des Produkts. Sind alle Anforderungen umgesetzt worden, ist das Produkt fertig.
Agile Architektur ist die Art, wie Unternehmensarchitekten, Systemarchitekten und / oder Softwarearchitekten die architektonische Praxis in der agilen Softwareentwicklung anwenden. Eine Reihe von Kommentatoren hat ein Spannungsverhältnis zwischen traditioneller Softwarearchitektur und agilen Methoden entlang der Achse von Anpassung (Aufschieben von Architekturentscheidungen bis zum letztmöglichen Zeitpunkt) und Antizipation (Planung im Voraus) festgestellt.
Der ART Sync ist das zentrale Synchronisationsinstrument eines ARTs. Er stellt sicher, dass Teams gemeinsam an PI-Zielen arbeiten, Risiken früh erkennen und Business- sowie Technikperspektiven integriert betrachten. Richtig eingesetzt, fördert er Fluss und Wert; falsch eingesetzt, droht er ineffizient zu werden.
Der Architect Sync ist ein Schlüsselinstrument in SAFe, um Architekturentscheidungen frühzeitig, transparent und kollaborativ zu treffen. Er trägt dazu bei, die Balance zwischen strategischen Leitplanken und emergenter Innovation zu halten und so die Grundlage für nachhaltige Agilität zu schaffen.
Batch Size beschreibt die Größe von Arbeitspaketen in einem Prozess. Kleine Batchgrößen sind ein Schlüsselprinzip von Lean und SAFe, da sie schnelle Lernzyklen, geringeres Risiko und höhere Flexibilität ermöglichen – vorausgesetzt, Organisation und Technik unterstützen deren Umsetzung.
BizDevOps kombiniert Produktentwicklung und -betrieb, um bestehende Silos zu umgehen, Entwicklungszyklen zu verkürzen, Abhängigkeiten zu verringern und insgesamt die Produkt-Qualität zu erhöhen. Ein Ansatz, in welchem alle notwendigen Funktionen aus dem Unternehmen in einem Produktteam zusammenarbeiten. BizDevOps ist ein Ansatz in der Organisationsentwicklung, welcher auf den DevOps Prinzipien aufbaut, erweitert um die fachliche Komponente.
Bridges’ Transition Model macht deutlich: Veränderung gelingt nur, wenn neben den äußeren Schritten auch die innere Reise der Menschen gestaltet wird. Wer Endings aktiv begleitet, die neutrale Zone bewusst nutzt und den Neubeginn verankert, erhöht die Erfolgschancen von Transformationen signifikant.
Built-In Quality ist ein zentrales Prinzip des Scaled Agile Framework (SAFe). Es beschreibt die Notwendigkeit, dass Qualität nicht nachgelagert „hineingetestet“ wird, sondern von Anfang an in jede Aktivität des Entwicklungsprozesses eingebettet ist. In SAFe ist Built-In Quality eine Voraussetzung für Value Delivery: Ohne sie können Teams, Agile Release Trains (ARTs) und Solution Trains keinen kontinuierlichen Fluss von Werten für den Kunden sicherstellen.
Business Process Redesign (BPR) ist ein Managementansatz, der bestehende Geschäftsprozesse radikal überdenkt und von Grund auf neu gestaltet, um signifikante Leistungsverbesserungen in Kosten, Qualität, Service und Geschwindigkeit zu erzielen. Im Gegensatz zu kontinuierlichen Verbesserungsansätzen (KVP, Kaizen) zielt BPR auf fundamentale Prozesssprünge. Die beigefügte Abbildung zeigt die vier Phasen des BPR – von der Zieldefinition bis zur nachhaltigen Integration – und macht die logische Abfolge des Redesigns sichtbar.
Beckhard’s Change Model kombiniert die Change-Formel D × V × F > R mit einem dreiphasigen Veränderungsprozess. Es liefert Führungskräften und Change-Teams ein erprobtes Instrument, um Transformationen zu planen, zu steuern und nachhaltig zu verankern – von der ersten Diagnose über die emotional anspruchsvolle Übergangsphase bis zur Stabilisierung des neuen Zustands.
Das Burke-Litwin-Veränderungsmodell (Burke-Litwin Change Model) ist ein wissenschaftlich fundiertes Diagnose- und Interventionsmodell für Organisationen. Entwickelt von W. Warner Burke und George H. Litwin (1992) beschreibt es zwölf miteinander verbundene Dimensionen, über die sich Veränderungen in Organisationen vollziehen.
Burn-down- und Burn-up-Charts sind erprobte agile Visualisierungswerkzeuge. Das Burn-down-Chart zeigt den verbleibenden Aufwand, das Burn-up-Chart schafft zusätzliche Transparenz, weil es Scope-Änderungen sichtbar macht. Am wirksamsten sind sie als Hilfsmittel für Lernen und Kommunikation – nicht als Kontrollinstrument.
Business Owner sind im Scaled Agile Framework (SAFe) eine wichtige Stakeholder-Rolle, die primär für die Wertschöpfung verantwortlich ist, die ein Agile Release Train (ART) oder Solution Train liefert. Sie repräsentieren die geschäftlichen Interessen und stellen sicher, dass Investitionen im Einklang mit den Unternehmenszielen stehen.
Die Benefit Hypothesis ist ein zentrales Element von SAFe, um Outcome-Orientierung sicherzustellen. Sie ersetzt starre Business Cases durch überprüfbare Annahmen und fördert eine Kultur der Transparenz, des Lernens und des Wertfokus.
Der Business Context beschreibt den strategischen Rahmen, in dem ein Unternehmen, ein Programm oder ein Team arbeitet. Er umfasst Markt- und Regulierungsbedingungen, Kundenbedürfnisse, Wettbewerb sowie interne Faktoren wie Vision, Strategie und finanzielle Ziele.
Im Scaled Agile Framework (SAFe) steht CALMR für Culture, Automation, Lean Flow, Measurement, Recovery. Es ist der DevOps-Ansatz, den SAFe definiert, um die Continuous Delivery Pipeline aufzubauen und zu betreiben.
Change Fatigue beschreibt einen Zustand emotionaler und kognitiver Erschöpfung, Abstumpfung oder Apathie gegenüber organisatorischen Veränderungen – ausgelöst durch zu viele, zu schnelle oder schlecht integrierte Change-Initiativen. Wichtig: Change Fatigue ist keine medizinische Diagnose; sie überschneidet sich mit Arbeitsstress, ist aber von Burn-out (ICD-11) zu unterscheiden. Burn-out wird von der WHO als Syndrom infolge chronischen, schlecht gemanagten Arbeitsstresses beschrieben.
Clayton’s Änderungsraster, international als Change Curve bekannt, beschreibt den typischen emotional-kognitiven Verlauf, den Menschen und Teams in Unternehmensveränderungen durchlaufen. Das Modell stammt von Dr. Mike Clayton und adaptiert psychologische Verlaufsmodelle wie die Kübler-Ross-Kurve für organisatorische Kontexte. Es kombiniert eine Phasenfolge (Denial → Reaction → Resistance → Discovery (Exploration) → Acceptance → Commitment) mit zwei Achsen (Emotional Focus vs. Rational Focus) und unterscheidet eine negative von einer positiven Zone der Veränderung.
Cost of Delay (CoD, Verzögerungskosten) beschreibt den wirtschaftlichen Schaden oder entgangenen Nutzen, der entsteht, wenn ein Feature, Enabler oder Projekt später als möglich ausgeliefert wird. Der Begriff stammt aus der Produktentwicklung (Don Reinertsen, The Principles of Product Development Flow) und wurde in SAFe als zentrales Priorisierungskriterium übernommen.
Die Continuous Delivery Pipeline (CDP) ist der End-to-End-Wertstrom in SAFe, der neue Funktionalität von der Idee bis zur bedarfsgerechten Auslieferung bringt – bestehend aus Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD) und Release on Demand (RoD). Die CDP ist in SAFe’s DevOps/CALMR-Denke verankert (Culture, Automation, Lean Flow, Measurement, Recovery).
Der Coach Sync (früher Scrum of Scrums) ist ein Event auf Ebene des Agile Release Trains (ART). Er wird vom Release Train Engineer (RTE) moderiert und dient dazu, Abhängigkeiten zwischen Teams sichtbar zu machen, Impediments zu behandeln und den Fortschritt gegenüber den PI Objectives sicherzustellen.
Capabilities sind im Scaled Agile Framework (SAFe®) ein Work-Item-Typ auf Solution-Ebene. Sie beschreiben eine größere Geschäftsfähigkeit, die mehrere Agile Release Trains umfasst und typischerweise mehrere Program Increments zur Umsetzung braucht. Capabilities liegen im Solution Backlog und werden in kleinere Features zerlegt, die wiederum in die ART-Backlogs wandern. Damit bilden sie die Brücke zwischen Portfolio-Epics und ART-bezogenen Features.
Cross-Functional Teams (CFTs) sind end-to-end verantwortliche Einheiten mit heterogenen Kompetenzen (z. B. Produkt, Fachbereich, Design, Technik, Compliance), die gemeinsam ein klar umrissenes Outcome liefern. In agilen Kontexten sind sie klein (typisch bis zu 10 Personen) und verfügen über alle Fähigkeiten, um Wert ohne externe Übergaben zu erzeugen.
Die SAFe Core Values sind die vier Grundüberzeugungen, auf denen das Scaled Agile Framework aufbaut: Alignment, Transparency, Respect for People, und Relentless Improvement. Sie bilden das Wertefundament für Verhalten, Entscheidungen und Praktiken in allen Ebenen des Frameworks.
Mit SAFe 6.0 wurden die Core Values aktualisiert. Zuvor galten Alignment, Built-in Quality, Transparency, Program Execution. Heute lauten sie Alignment, Transparency, Respect for People, Relentless Improvement.
Der Confidence Vote (Zutrauensabstimmung) ist ein zentrales Element des PI Plannings im Scaled Agile Framework (SAFe). Er misst das Vertrauen der Beteiligten in die Tragfähigkeit der erarbeiteten PI Objectives und in die Fähigkeit des Agile Release Trains (ART), diese umzusetzen.
Capacity Allocation (Zuordnung von Kapazitäten) ist im Scaled Agile Framework (SAFe) das Mittel, wie die verfügbare Kapazität eines ARTs oder Teams auf unterschiedliche Arbeitstypen verteilt wird – z. B. Business Features, Enabler, Compliance-Arbeit oder Wartung/Schuldenabbau.
Das Dual Operating System koppelt hierarchische Zuverlässigkeit mit netzwerkartiger Geschwindigkeit. Es wird wirksam, wenn Entscheidungsrechte, Budgetflüsse, Metriken und Handover-Mechanismen präzise definiert sind – und wenn Führung paradoxe Anforderungen bewusst balanciert.
Delegation Poker ist ein wirkungsvolles Werkzeug, mit dem Teams und Führungskräfte gemeinsam klären, wer in welchen Situationen Entscheidungen trifft. Es ist ein entscheidender Schritt hin zu selbstorganisierter Arbeit und moderner agiler Führung. Dabei verlassen sowohl Führungskräfte als auch Teammitglieder bewusst ihre Komfortzone – allerdings nur so weit, wie es für alle stimmig ist. Das Werkzeug hilft, komplizierte und zeitraubende Entscheidungsprozesse aufzulösen, fördert Eigenverantwortung und schafft Sicherheit in Entscheidungssituationen. So wird aus Delegation kein Risiko, sondern eine gelebte Stärke im Teamalltag.
Design Thinking ist ein menschenzentrierter Innovationsansatz, der darauf abzielt, Produkte, Dienstleistungen oder Prozesse zu entwickeln, die echte Nutzerbedürfnisse erfüllen. Der Ansatz verbindet Empathie für den Anwender, kreative Ideenfindung und iteratives Experimentieren, um Lösungen für komplexe Probleme zu finden.
DAD ist ein kontextspezifisches Delivery-Framework mit großer Spannweite. Es entfaltet Stärke, wenn Engineering-Exzellenz, Governance-Leichtbau und erfahrene Moderation vorhanden sind. Schwach wird es, wenn Organisationen es bürokratisch auslegen, Rollen unklar halten oder ohne Outcome-Fokus implementieren.
Das Daily Scrum ist ein kurzes, tägliches Meeting des Scrum Teams. Es dient dazu, den Fortschritt in Richtung des Sprint-Ziels zu überprüfen und den Plan für die nächsten 24 Stunden anzupassen. Das Meeting ist auf 15 Minuten timeboxed und wird vom Entwicklungsteam selbst gestaltet.
Das Development Team ist eine der drei in Scrum definierten Verantwortlichkeiten, neben Product Owner und Scrum Master. Es besteht aus Fachleuten, die gemeinsam dafür verantwortlich sind, Product-Backlog-Einträge umzusetzen und am Ende jedes Sprints ein potenziell auslieferbares Inkrement zu erstellen.
Die Definition of Done (DoD) ist die formale Beschreibung des Zustands, in dem ein Inkrement alle geforderten Qualitätskriterien erfüllt. Sobald ein Product-Backlog-Eintrag die DoD erfüllt, trägt er zu einem nutzbaren, potenziell auslieferbaren Inkrement bei. Die DoD schafft Transparenz darüber, was „fertig“ wirklich bedeutet, und verhindert Missverständnisse zwischen Team, Product Owner und Stakeholdern.
Die Definition of Ready (DoR) ist ein zentrales Konzept agiler Arbeit. Sie beschreibt Kriterien, die ein Arbeitselement – etwa eine User Story, ein Feature oder ein Epic – erfüllen muss, bevor ein Team es zur Umsetzung übernimmt. Ziel ist, dass Anforderungen klar, verständlich und machbar sind. Erst dann kann ein Team verlässlich liefern, ohne sich in unnötigen Diskussionen, Blockaden oder Fehlentwicklungen zu verlieren.
Dynamic Capabilities sind die Fähigkeit von Organisationen, sich kontinuierlich neu zu erfinden, Chancen zu erkennen und sich selbst dafür zu verändern. Sie bieten einen Rahmen, um Resilienz, Agilität und Strategie in einen nachhaltigen Wettbewerbsvorteil zu übersetzen.
Das Eisbergmodell ist eine der anschaulichsten Metaphern, um die verborgene Komplexität von Veränderungsprozessen in Organisationen zu verstehen. Ähnlich wie bei einem echten Eisberg ist nur ein kleiner Teil der relevanten Faktoren direkt sichtbar, während der weit größere Teil unter der Wasseroberfläche verborgen bleibt. Im Kontext von Change Management steht der sichtbare Teil für Strukturen, Prozesse, messbare Ziele und beobachtbares Verhalten. Der unsichtbare Teil umfasst dagegen Einstellungen, Werte, Emotionen, unausgesprochene Normen, informelle Machtstrukturen und unbewusste Dynamiken.
Enterprise Agility (auch Business Agility) ist die Fähigkeit der gesamten Organisation, sich schnell, vorhersagbar und nachhaltig an veränderte Rahmenbedingungen anzupassen – mit klarem Kundennutzen bei stabilen Qualitäts- und Kostenprofilen. Das umfasst Strategie, Portfolio, Operating Model, Governance, Technologie und Kultur – nicht nur die IT.
Extreme Programming (XP) ist eine agile Softwareentwicklungsmethode, die auf kurze Iterationen, kontinuierliches Feedback und technische Exzellenz setzt. Iterationen dauern typischerweise 1–2 Wochen und liefern jeweils ein funktionierendes Inkrement. XP legt großen Wert auf Teamarbeit, Offenheit, Einfachheit und ständige Kommunikation.
ELMO steht für “Enough, Let’s Move On” und ist eine Methode, die Teams hilft, in Besprechungen oder Workshops fokussiert zu bleiben. Anstatt mündlich zu unterbrechen, halten Teilnehmende eine Karte mit dem ELMO-Motiv hoch, um ein Signal zu geben: „Das Thema ist ausreichend behandelt, lasst uns weitergehen.“
Der EU AI Act ist das europäische Regelwerk für künstliche Intelligenz. Er reguliert KI nicht als Technologie, sondern nach Risiko: Je größer der mögliche Schaden für Gesundheit, Sicherheit oder Grundrechte, desto strenger die Pflichten.
Reduce Queue Length bedeutet, die Länge von Warteschlangen im Wertstrom zu verringern. „Queues“ entstehen, wenn mehr Arbeit gestartet als fertiggestellt wird. Lange Queues führen zu Wartezeiten, verzögern Feedback, verschlechtern Vorhersagbarkeit und erhöhen das Risiko, dass Arbeit veraltet oder nie abgeschlossen wird. In SAFe wie in Lean ist die Reduktion von Queues ein zentraler Hebel für Flow-Optimierung.
Das Flight Levels Framework, entwickelt von Klaus Leopold, ist ein Denkmodell, das Organisationen hilft, Flow, Alignment und Transparenz über alle Ebenen hinweg zu schaffen. Es unterscheidet drei Flughöhen:
• Flight Level 1: Operative Teamarbeit.
• Flight Level 2: Koordination zwischen Teams/Wertströmen.
• Flight Level 3: Strategische Steuerung und Ausrichtung.
Im Unterschied zu Frameworks wie SAFe ist Flight Levels nicht-preskriptiv: Es schreibt keine Rollen oder Events vor, sondern fokussiert auf das Zusammenspiel der Ebenen.
Get Faster Feedback bedeutet, dass Ergebnisse und Hypothesen möglichst frühzeitig überprüft werden, um Risiken zu reduzieren, Lernen zu beschleunigen und Wert schneller zu liefern. Feedback erfolgt durch Kunden, Stakeholder, Systeme oder Daten – und ist ein zentraler Treiber von Lean-Agile Arbeitsweisen.
“Engpässe beseitigen“ bedeutet: Systematische Engpässe im Wertstrom identifizieren und gezielt auflösen, damit der Fluss von Arbeit nicht blockiert wird. Ein „Bottleneck“ ist jede Stelle, an der sich Arbeit staut – sei es durch limitierte Kapazität, Abhängigkeiten oder ineffiziente Prozesse. In SAFe ist das aktives Gestalten von Flow: Bottlenecks nicht hinnehmen, sondern sichtbar machen und beseitigen.
Minimise Handoffs and Dependencies bedeutet: Übergaben reduzieren und Abhängigkeiten abbauen, damit Arbeit schneller, fehlerärmer und autonomer durch Teams und Wertströme fließen kann. Jeder Handoff (z. B. Übergabe von Team A zu Team B) kostet Zeit, erzeugt Reibung und erhöht das Risiko von Missverständnissen. Abhängigkeiten zwischen Teams, ARTs oder externen Partnern sind eine Hauptursache für Verzögerungen.
Optimize Time “In the Zone” bedeutet, Teams und Individuen möglichst viel ungestörte Zeit für fokussiertes Arbeiten zu verschaffen. „In the Zone“ beschreibt den Zustand tiefer Konzentration (oft als „Flow State“ bekannt). Jede Unterbrechung durch Meetings, Kontextwechsel oder Wartezeiten reduziert diesen Zustand und verlangsamt den Wertfluss. In SAFe ist dies ein zentraler Hebel, um Produktivität und Qualität zu steigern.
Remediate Legacy Policies and Practices bedeutet, veraltete Regeln, Prozesse und Gewohnheiten aktiv zu hinterfragen und zu beseitigen, wenn sie den Wertfluss behindern. Viele Organisationen halten an Praktiken fest, die einst sinnvoll waren, heute jedoch zu Verschwendung, Verlangsamung oder Frustration führen. SAFe benennt dies explizit als einen der acht Beschleuniger für Flow.
„Visualisiere und begrenze WIP“ bedeutet, laufende Arbeit (Work in Process) auf jeder Flow-Ebene sichtbar zu machen und die Zahl paralleler Aufgaben bewusst zu begrenzen – für mehr Fokus, kürzere Durchlaufzeiten und bessere Vorhersagbarkeit.
Flow Accelerators sind acht Handlungsempfehlungen im Scaled Agile Framework®, die Organisationen helfen, den Wertfluss (Flow of Value) über Teams, ARTs und Portfolios hinweg zu beschleunigen. Sie sind praktische Hebel, um Hindernisse abzubauen, Engpässe zu beseitigen und kontinuierlich schneller, effizienter und kundenorientierter zu liefern.
Work in Smaller Batches bedeutet, Arbeit in kleinere, überschaubare Einheiten zu zerlegen, statt große, riskante „Big Bang“-Lieferungen anzustreben. Kleinere Batches reduzieren Risiko, beschleunigen Feedback, erhöhen Vorhersagbarkeit und machen Wert schneller sichtbar. In Lean und SAFe ist dieses Prinzip ein Kernelement von Flow-Optimierung.
Ein Gemba Walk ist eine Führungspraxis aus dem Toyota Production System (TPS) und dem Lean-Management. „Gemba“ (現場) bedeutet „der reale Ort“ – also der Ort, an dem Wertschöpfung tatsächlich stattfindet (Fabrikhalle, Büro, IT-System, Service Desk). Beim Gemba Walk gehen Führungskräfte, Coaches oder Berater zum Ort des Geschehens, um Prozesse zu beobachten, Mitarbeitende einzubeziehen, Ursachen zu verstehen und Verbesserungen zu fördern.
Goodhart’s Law besagt sinngemäß: Wenn eine Kennzahl zur Zielvorgabe wird, verliert sie ihre Aussagekraft als Messgröße. Ursprung ist die ökonomische Forschung von Charles Goodhart (1975) im Kontext der britischen Geldpolitik. Das Phänomen wurde später durch Sozialwissenschaften (Marilyn Strathern) und die Organisationsforschung verallgemeinert und gilt heute als zentrales Konzept in Ökonomie, Controlling, agiler Produktentwicklung und KI-Sicherheit.
Der Inspect & Adapt (I&A) Workshop ist ein zentrales Element im Scaled Agile Framework (SAFe). Er findet am Ende eines Program Increments (PI) statt und dient dazu, systematisch zu reflektieren, zu messen und Verbesserungen einzuleiten. Ziel ist es, nicht nur die Arbeitsergebnisse zu begutachten, sondern auch die Zusammenarbeit, Prozesse und Strukturen kontinuierlich weiterzuentwickeln.
Die IP Iteration (Innovation & Planning Iteration) ist ein zentrales Element im Scaled Agile Framework (SAFe). Sie findet am Ende eines Program Increments (PI) statt und dient als Puffer, Innovationsraum und Planungszeit. Während die regulären Iterationen auf Lieferung von Features und Stories fokussieren, schafft die IP Iteration bewusst Raum für Innovation, Weiterbildung, Exploration und Vorbereitung.
Ein Impediment (dt.: Hindernis oder Blockade) ist jedes Problem, das ein Team daran hindert, seine Arbeit effektiv und effizient zu erledigen. Impediments können technischer, organisatorischer, prozessualer oder zwischenmenschlicher Natur sein. Der Begriff wird vor allem im agilen Arbeiten (Scrum, SAFe, Kanban) genutzt, ist jedoch universell in Projekten und Organisationen anwendbar.
Ein Increment (Produktinkrement) ist das in sich nutzbare, integrierte Arbeitsergebnis einer Iteration, das auf allen bisherigen Inkrementen aufbaut. Es umfasst die Summe aller seit Produktbeginn „fertigen“ (Definition of Done) Product-Backlog-Einträge und befindet sich in einem potenziell auslieferbaren Zustand.
In Scrum entsteht mindestens ein Increment pro Sprint. In SAFe entstehen Team-Inkremente pro Iteration; auf ART-Ebene ergibt die Integration dieser Team-Inkremente das System-Inkrement. Über ein Program Increment (PI) hinweg (typisch 8–12 Wochen) liefert ein ART inkrementellen Wert in Form funktionierender Software oder Systeme; sichtbar u. a. in System Demos und beim Inspect & Adapt.
Das Johari Window ist ein von Joseph Luft und Harrington Ingham 1955 entwickeltes Kommunikations- und Lernmodell zur Verbesserung von Selbstwahrnehmung, Feedback-Kultur und Zusammenarbeit. Es visualisiert den Zusammenhang zwischen Selbstoffenbarung und Feedback in vier Feldern („Arenen“), die sich in ihrer Größe dynamisch verändern. Ziel ist es, die offene Fläche (Arena) zu vergrößern, also den Bereich, in dem Selbst- und Fremdwahrnehmung übereinstimmen.
Das Kanban Framework ist ein Ansatz für Agiles Arbeiten und kontinuierliche Verbesserung, der ursprünglich von David J. Anderson auf die Wissensarbeit übertragen wurde. Es baut auf Prinzipien des Toyota-Produktionssystems (Lean) auf und fokussiert auf die Visualisierung von Arbeit, Limitierung von Work in Progress (WIP) und kontinuierlichen Fluss.
Wichtig: Kanban ist kein starres Vorgehensmodell mit fixen Rollen oder Events, sondern ein flexibles, evolutionäres Change-Framework, das Organisationen hilft, ihre Prozesse Schritt für Schritt zu verbessern.
Das KATGAR-Change-Modell ist ein praxisnaher Orientierungsrahmen für ganzheitliche Veränderungen. Es verbindet strategische Klarheit, kontinuierliche Kommunikation, Menschenfokus, gemeinsames Lernen und kulturelle Verankerung zu einem flexiblen Handlungsgerüst. Obwohl es nicht wissenschaftlich standardisiert ist, liefert es Organisationen einen erprobten Bezugsrahmen, um komplexe Transformationen erfolgreich zu gestalten und nachhaltig zu verankern.
Das Kirkpatrick-Modell bietet eine klare, erprobte Struktur, um Trainings- und Transformationsmaßnahmen zu bewerten und zu verbessern. Indem es Teilnehmerreaktionen, Lernergebnisse, Verhaltensänderung und Organisationsergebnisse verbindet, hilft es Organisationen sicherzustellen, dass Investitionen in Menschen sich in konkretem Geschäftswert niederschlagen. CALADE verbindet das Modell mit modernen agilen und strategischen Praktiken, um Training und Transformation messbar, umsetzbar und nachhaltig zu machen.
Kotter’s 8-Step Model bietet einen rahmengebenden Ansatz für Führung im Wandel: Dringlichkeit schaffen, Koalition stärken, Vision kommunizieren, Beteiligung mobilisieren, Hindernisse abbauen, Erfolge sichtbar machen, Tempo halten, Kultur verankern. Richtig eingesetzt – iterativ, messbar und mit Adoption kombiniert – wird es zum Beschleuniger nachhaltiger Transformation.
Kaizen (改善) bedeutet „kontinuierliche Verbesserung“. Es ist eine Management- und Lernphilosophie, die jeden Tag, überall und von allen kleine, wirksame Verbesserungen einfordert – auf Basis eines wissenschaftlichen Vorgehens (PDCA/PDSA), Respekt vor den Menschen und konsequenter Problemlösung am Ort der Wertschöpfung (Gemba). Historisch hat Kaizen das Toyota Production System geprägt und bildet den Kern von Lean.
KI-Kompetenz ist das, was Menschen brauchen, um KI im Beruf sachkundig einzusetzen und ihre Risiken einzuschätzen. Artikel 4 der KI-Verordnung verpflichtet Anbieter und Betreiber seit Februar 2025, dafür Maßnahmen zu ergreifen. Seit Juli 2026 gilt eine abgeschwächte, aber weiterhin verbindliche Fassung.
Das Lean-Agile Center of Excellence (LACE) ist im SAFe®-Framework das dauerhafte Team, das den organisatorischen Wandel zu einer Lean-Agile-Unternehmenskultur führt, koordiniert und beschleunigt. Es ist eine Institutionalisierung des Change-Managements, vergleichbar mit einem Kompetenzzentrum, das Standards setzt, Methoden weiterentwickelt und die Skalierung agiler Arbeitsweisen über die gesamte Organisation hinweg sichert.
Living Strategy ist ein von Mario André Brückner entwickelter Ansatz zur partizipativen, iterativen und kontinuierlichen Strategiearbeit. Anders als klassische Strategiemodelle, die in mehrjährigen Zyklen und mit statischer Top-down-Planung arbeiten, versteht Living Strategy Strategie als lebendigen Prozess.
Living Transformation® ist ein leichtgewichtiges, inkrementelles Transformations-Framework. Es organisiert Veränderung nicht als einmaliges Programm, sondern als kontinuierlichen Zyklus von drei Monaten, das sogenannte Transformation Increment (TI). Jedes TI startet mit einem Transformation Increment Planning Event (TIPE), führt über klar definierte Events, Rollen und Artefakte zu überprüfbaren Ergebnissen („Transformation Changes“) und endet mit einem Measure & Improve. Kernprinzip: Veränderung entsteht von innen, mit klar hinterlegter Mitarbeiter-Kapazität – statt ausgelagerten Schattenorganisationen.
Large-Scale Scrum (LeSS) ist ein agiles Skalierungs-Framework, das auf den Prinzipien und Werten des Scrum Guide basiert. Es wurde von Craig Larman und Bas Vodde entwickelt und verfolgt das Ziel, Scrum auf mehrere Teams auszuweiten, die gemeinsam an einem Produkt arbeiten. Im Unterschied zu komplexeren Frameworks setzt LeSS auf Minimalismus und organisatorische Vereinfachung, um Kundennutzen zu maximieren und gleichzeitig strukturelle Komplexität zu reduzieren.
Lean Portfolio Management (LPM) ist ein Kernelement des Scaled Agile Framework (SAFe) und beschreibt den Ansatz, Strategie und Finanzierung einer Organisation mit agilen Umsetzungsstrukturen zu verbinden. Während klassische Portfoliosteuerung häufig auf Jahresbudgets, Projekte und Output-Controlling fokussiert, setzt LPM auf kontinuierliche Strategieumsetzung, Value-Stream-Budgets, Lean Governance und dezentrale Entscheidungsfindung. LPM ist damit der Brückenschlag zwischen CxO-Ebene und operativer Delivery – mit dem Ziel, Business-Agility auf Unternehmensebene herzustellen.
Leavitt’s Diamond ist ein klassisches Organisationsmodell, das 1965 von Harold J. Leavitt entwickelt wurde. Es beschreibt Unternehmen als System aus vier miteinander verbundenen Komponenten: Aufgaben (Tasks), Struktur, Technologie und Menschen (People). Die Grundannahme: Jede Veränderung einer dieser Komponenten wirkt sich zwangsläufig auf die anderen drei aus. Das Modell betont damit die Systemdynamik von Organisationen und dient als zentrales Werkzeug im Change Management und in der Organisationsentwicklung.
Little’s Law—auch Littles Gesetz—ist eine fundamentale Regel der Warteschlangentheorie aus dem Jahr 1961 (John D. C. Little, MIT), die den Zusammenhang zwischen Work in Progress (WIP), Durchsatz (Throughput) und Durchlaufzeit (Cycle Time/Lead Time) beschreibt. Formal lautet die Gleichung:
WIP = Throughput × Cycle Time
bzw. in klassischer Warteschlangentheorie: L = λ × W, wobei L die Anzahl im System und λ die Ankunfts- oder Abgangsrate ist. Diese Gesetzmäßigkeit gilt unabhängig von Verteilungsannahmen oder Systemdetails – vorausgesetzt, es handelt sich um stationäre Zustände.
Leading und Lagging Indicators sind komplementär: Leading ermöglicht frühzeitiges Steuern, Lagging sichert den Nachweis von Ergebnissen. Wer beide sauber koppelt, an Entscheidungen bindet und gegen Gaming schützt, kann Veränderung messbar, adaptiv und nachhaltig gestalten.
Lean Budgets in SAFe ersetzen projektbasierte Einzelbudgets durch Value-Stream-Budgets und schaffen damit eine leichte, schnell anpassbare Finanz- und Governance-Basis für die Portfolioarbeit. Lean-Agile Guardrails sind die klar definierten Leitplanken, die dieses Budgetmodell steuern und absichern. SAFe unterscheidet vier Guardrails:
1. Investitionen nach Horizonten lenken
2. Kapazität zielgerichtet allokieren
3. Signifikante Initiativen genehmigen
4. Kontinuierliche Business-Owner-Einbindung sicherstellen
Damit verbindet SAFe dezentrale Ausführung mit klarer finanzieller Steuerung.
Mob Programming (auch „Mobbing“ genannt) ist eine kollaborative Arbeitsweise, bei der ein gesamtes Team gleichzeitig an derselben Aufgabe, an derselben Workstation, mit demselben Fokus arbeitet. Das Konzept wurde ursprünglich von Woody Zuill bekannt gemacht und wird u. a. bei Tesla eingesetzt. Joe Justice beschreibt es als Kernpraktik, um extreme Innovationsgeschwindigkeit zu erreichen.
Magic Estimation ist eine agile Schätzmethode, mit der Teams in kurzer Zeit viele User Stories oder andere Product Backlog Items bewerten können. Im Gegensatz zu detaillierten Diskussionen beim Planning Poker ermöglicht Magic Estimation eine schnelle, relative Einschätzung der Komplexität. Dabei berücksichtigen Teams Aspekte wie Risiken, Unsicherheiten, Abhängigkeiten, Komplexität und Arbeitsvolumen.
Nexus ist ein schlankes Skalierungs-Framework, das Integration in den Mittelpunkt stellt. Es funktioniert nur dort, wo Organisationen ausreichend Reife in Engineering-Praktiken, Disziplin und Transparenz mitbringen.
Organizational Resilience bezeichnet die Fähigkeit einer Organisation, Schocks, Störungen und kontinuierliche Veränderungen zu absorbieren, sich schnell anzupassen und daraus gestärkt hervorzugehen. Resilienz geht über klassische Krisenreaktion hinaus: Sie umfasst die Proaktivität in Vorbereitung, die Agilität im Handeln und die Lernfähigkeit nach Ereignissen.
Objectives & Key Results (OKR) sind ein Rahmenwerk für die agile Strategieumsetzung auf Organisations-, Team- und individueller Ebene. Es verbindet qualitative Ziele (Objectives) mit messbaren Ergebnissen (Key Results). Typischerweise werden ein bis drei Objectives pro Zyklus definiert, die jeweils durch drei bis fünf Key Results konkretisiert werden. Das Leitprinzip lautet: weniger, aber fokussierter, um Prioritäten zu setzen und Wirkung zu erzielen.
Organisational Debt bezeichnet die aufgelaufenen strukturellen, prozessualen und kulturellen Altlasten einer Organisation – z. B. veraltete Richtlinien, Rollenmodelle, Entscheidungswege oder Gewohnheiten –, die den heutigen Wertfluss verlangsamen und Kosten „in Zinsen“ verursachen (mehr Koordination, Wartezeiten, Rework). Der Begriff wurde u. a. von Steve Blank geprägt („Organizational debt is like technical debt — but worse“) und von Aaron Dignan (Brave New Work) erweitert als „Zinslast, die entsteht, wenn Strukturen/Policies fix bleiben, während die Welt sich ändert“.
Planning Poker – auch bekannt als Scrum Poker – ist eine agile Schätzmethode, die auf Konsensbildung im Entwicklungsteam beruht. Sie wird vor allem in Scrum-Teams im Rahmen der Sprint Planning oder bei Backlog Refinements eingesetzt. Ziel ist es, die relative Komplexität und den Aufwand von User Stories oder Features zu schätzen.
Das Product Backlog Refinement (früher auch „Backlog Grooming“ genannt) ist eine fortlaufende Aktivität in Scrum, bei der die Product Backlog Items (PBIs) überprüft, detailliert, priorisiert und geschätzt werden. Anders als die fünf offiziellen Scrum-Events ist das Refinement nicht timeboxed, sondern findet kontinuierlich während des Sprints statt. Typischerweise sollte es nicht mehr als 10 % der Kapazität des Entwicklungsteams beanspruchen.
Portfolio Epics sind im Scaled Agile Framework (SAFe®) die größten, strategischen Initiativen auf Portfolioebene. Sie adressieren signifikante Investitionen, die maßgeblich Einfluss auf die Unternehmensstrategie, Wertströme oder das Geschäftsmodell haben. Beispiele sind der Eintritt in neue Märkte, die Entwicklung digitaler Plattformen oder der Aufbau neuer Produktlinien. Epics sind zu groß und komplex, um direkt von Agile Release Trains (ARTs) umgesetzt zu werden, und benötigen deshalb Analyse, Priorisierung und Steuerung im Portfolio-Kanban.
Portfolio Kanban ist in SAFe das visuelle Flusssystem zur Steuerung strategischer Initiativen (Portfolio Epics) – von der Idee bis zur Umsetzung. Es macht Entscheidungslogik, WIP (Work in Process), Risiken und Reifegrad der Vorhaben sichtbar und verknüpft Strategie (LPM, Lean Budgets & Guardrails) mit der Lieferung in Solution Trains und ARTs.
Das Product Backlog ist das zentrale Artefakt in Scrum und bildet eine geordnete Liste aller bekannten Anforderungen an das Produkt. Es enthält alles, was benötigt wird, um den Wert des Produkts zu maximieren – von Features über technische Verbesserungen bis hin zu Bugfixes oder experimentellen Hypothesen. Das Product Backlog ist dynamisch und niemals abgeschlossen. Es entwickelt sich kontinuierlich weiter, während das Produkt und die Organisation lernen.
In der agilen Produktentwicklung ist ein Increment (oft „Produktinkrement“) das nutzbare Arbeitsergebnis einer Iteration, das auf allen bisherigen Ergebnissen aufbaut. Jedes Inkrement ist die Summe aller bis dahin fertiggestellten Product-Backlog-Einträge. Der Scrum Guide verlangt, dass jedes neue Inkrement der Definition of Done entspricht und nutzbar ist. In der Praxis heißt das: Das Inkrement muss potenziell auslieferbar sein und alle Qualitätskriterien erfüllen – auch wenn der Product Owner sich gegen eine sofortige Auslieferung entscheidet.
Im Scaled Agile Framework (SAFe) ist der Product Owner (PO) ein festes Mitglied eines agilen Entwicklungsteams (in der Regel 5–11 Personen) und fungiert dort als „Stimme des Kunden“. Sein zentrales Ziel ist die Maximierung des Produktwerts. Er ist dafür verantwortlich, dass das Team stets an den wertvollsten Anforderungen arbeitet. Dazu wirkt der PO als Schnittstelle zwischen internen und externen Stakeholdern (z. B. Business Ownern, Kunden) und dem Entwicklungsteam. Er sorgt dafür, dass sich die Produktstrategie des Unternehmens und die kurzfristige Entwicklungsarbeit optimal ergänzen.
Im Scrum Framework ist der Product Owner (PO) eine der drei Verantwortlichkeiten im Scrum Team – neben dem Scrum Master und den Developern. Der PO ist verantwortlich für die Maximierung des Werts des Produkts, das durch die Arbeit des Scrum Teams entsteht. Er trägt die Verantwortung für das Product Goal, sorgt für Klarheit, Transparenz und Priorisierung des Product Backlogs und fungiert als zentrale Schnittstelle zwischen Stakeholdern und dem Scrum Team. Im Gegensatz zu skalierten Frameworks trägt der Product Owner in reinem Scrum sowohl die strategische als auch die taktische Verantwortung für das Produkt.
Das PI Planning ist ein zentrales Event im Scaled Agile Framework (SAFe). Es ist das Herzstück der Abstimmung im großen Maßstab und findet typischerweise alle 8 bis 12 Wochen statt. In diesem zweitägigen Planungsworkshop kommen alle Teams eines Agile Release Trains (ART) – oft 100+ Personen – zusammen, um gemeinsam Ziele, Abhängigkeiten und Prioritäten für das nächste Program Increment festzulegen.
Planning Poker ist eine erprobte agile Schätzmethode, die psychologische Erkenntnisse (Wideband Delphi, kollektive Intelligenz) mit praktischer Team-Moderation verbindet. Für erfahrene Scrum Master und agile Coaches ist es eine Schlüsselpraktik, um verborgene Risiken sichtbar zu machen, gemeinsame Verantwortung zu fördern und belastbare, wertorientierte Prognosen zu ermöglichen – im einzelnen Scrum Team ebenso wie in skalierten Umgebungen wie SAFe®, LeSS und Nexus. Bewusst eingesetzt stärkt Planning Poker sowohl Vorhersagbarkeit als auch das Lernen im Team und macht aus dem Schätzen einen Treiber kontinuierlicher Verbesserung.
Psychologische Sicherheit bezeichnet das geteilte Glaubenssystem in einem Team, dass man interpersonelle Risiken eingehen kann – etwa Ideen äußern, Fragen stellen oder Fehler zugeben – ohne Angst vor negativen Konsequenzen wie Ausgrenzung oder Bestrafung. Der Begriff wurde 1999 von Amy Edmondson (HBS) geprägt.
Ein Projektmanager ist im klassischen Projektmanagement die zentrale Rolle, die für die Planung, Steuerung und erfolgreiche Durchführung von Projekten verantwortlich ist. Seine Aufgaben umfassen die Koordination von Ressourcen, Terminen, Kosten und Qualität, das Risikomanagement sowie die Kommunikation mit allen Stakeholdern. In vielen Organisationen gilt der Projektmanager als „Single Point of Accountability“ für den Projekterfolg.
Der Release Train Engineer (RTE) ist eine zentrale Rolle im Scaled Agile Framework (SAFe®). Als Servant Leader und Coach unterstützt er den Agile Release Train (ART) – eine langfristig bestehende Einheit aus mehreren agilen Teams (50–125 Personen) – dabei, Wert systematisch und koordiniert zu liefern. Der RTE übernimmt in einem ART eine ähnliche Rolle wie der Scrum Master in einem einzelnen Team: Er befähigt, moderiert und schafft Rahmenbedingungen für Selbstorganisation und Wertorientierung.
Die Sprint Retrospektive ist eines der fünf offiziellen Ereignisse in Scrum (neben Sprint, Sprint Planning, Daily Scrum und Sprint Review). Sie findet am Ende jedes Sprints statt, nach dem Sprint Review und vor Beginn des nächsten Sprints. Ihr offizieller Zweck laut Scrum Guide ist es, den vergangenen Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und die Definition of Done zu überprüfen und Anpassungen für den nächsten Sprint abzuleiten.
Risk ROAMing ist eine Methode aus dem Scaled Agile Framework (SAFe), um Risiken in großen Planungsevents wie dem PI Planning zu identifizieren, zu klassifizieren und transparent zu managen.
„ROAM“ ist ein Akronym für vier mögliche Zustände von Risiken:
• Resolved (gelöst)
• Owned (jemand übernimmt Verantwortung)
• Accepted (bewusst akzeptiert)
• Mitigated (durch Maßnahmen verringert)
Die Solution Demo ist das Schaufenster des Solution Trains. Sie ergänzt die System Demos der ARTs und bietet einen End-to-End-Blick auf komplexe Lösungen. Damit ist sie ein entscheidendes Instrument für Transparenz, Feedback und Risikomanagement in großen SAFe-Implementierungen.
Die System Demo ist das Schaufenster des ART. Sie macht Fortschritt sichtbar, ermöglicht wertvolles Feedback und stärkt das Vertrauen zwischen Business und Delivery. In der Kombination aus Iterations-Demos und PI System Demo wird sie zum zentralen Motor für Transparenz, Alignment und kontinuierliche Verbesserung.
Der Scrum Master ist eine der drei zentralen Verantwortlichkeiten im Scrum-Framework, neben Product Owner und Developern. Als Servant Leader unterstützt er Scrum Team und Organisation dabei, Scrum zu verstehen, anzuwenden und kontinuierlich zu verbessern. Er führt den Prozess, nicht die Menschen – er ermöglicht Selbstorganisation und fördert eine Kultur von Offenheit, Transparenz und stetiger Verbesserung.
Ein Solution Train ist das Organisationskonstrukt in SAFe, mit dem mehrere Agile Release Trains (ARTs) und Lieferanten koordiniert werden, um eine große integrierte Lösung zu entwickeln (z. B. komplexe Software-Plattformen oder cyber-physische Systeme). Er gehört zur Large Solution-Konfiguration und bringt zusätzliche Rollen, Events und Artefakte ein (u. a. STE, Solution Management, Solution Architect/Engineering, Pre-/Post-PI-Planning, Solution Intent).
Ein Sprint(oder Iteration) ist das grundlegende Zeitfenster im Scrum Framework. Er ist ein Container für alle Scrum-Events – Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective – und dient der kontinuierlichen Lieferung von Wert. Der Scrum Guide beschreibt Sprints als den Herzschlag von Scrum, in dem Ideen in Wert verwandelt werden. Sprints sind immer gleich lang, maximal vier Wochen, und laufen unmittelbar aufeinander: Der nächste Sprint beginnt sofort nach Abschluss des vorherigen. Dieses Prinzip schafft eine feste Kadenz, vergleichbar mit dem gleichmäßigen Treten beim Fahrradfahren – es gibt nie eine „Pause ohne Sprint“.
Das Sprint Review ist eines der fünf offiziellen Scrum-Ereignisse. Es findet am Ende jedes Sprints statt – nach der Fertigstellung des Inkrements und vor der Sprint Retrospektive. Zweck ist es, Ergebnis und Richtung zu inspizieren: Das Scrum Team und eingeladene Stakeholder betrachten das Produktinkrement (nur „Done“ gemäß Definition of Done), prüfen was sich im Umfeld geändert hat und passen das Product Backlog gemeinschaftlich an. Das Review ist ein Arbeits- und Kooperationsformat, kein Statusmeeting und keine formale Abnahme.
Systemisches Coaching ist eine prozessorientierte, lösungs- und ressourcenfokussierte Begleitung von Einzelpersonen, Teams und Organisationen. Es basiert fachlich u. a. auf Systemtheorie, Konstruktivismus und Kybernetik zweiter Ordnung: Wirklichkeit wird als sozial konstruiert verstanden; der Coach arbeitet nicht als Fachratgeber, sondern gestaltet den Dialog- und Reflexionsprozess, in dem Klient:innen eigene Lösungen entwickeln.
System Architect/Engineer ist eine Schlüsselrolle im Scaled Agile Framework (SAFe). Sie verantwortet die technische Vision und Architektur einer Lösung auf ART- oder Solution-Ebene. Während Business und Product Management die „Was“-Fragen beantworten (welche Features/Value), sorgt System Architect/Engineering für das „Wie“ – also technische Konsistenz, Skalierbarkeit und Nachhaltigkeit.
Die SAFe Principles sind zehn fundamentale Handlungsprinzipien des Scaled Agile Framework. Sie geben Organisationen eine gemeinsame Denkweise, um komplexe Entscheidungen zu treffen, Lean-Agile-Arbeitsweisen wirksam umzusetzen und langfristig Wert zu schaffen. Während die Core Values kulturelle Leitplanken darstellen, beschreiben die Prinzipien das „Warum“ und „Wie“ hinter den Methoden und Praktiken von SAFe.
Das Scrum Team ist die grundlegende Einheit in Scrum. Es ist klein, crossfunktional und selbstmanagend: Product Owner, Scrum Master und Developer verantworten gemeinsam, dass in jedem Sprint ein wertvolles, nutzbares Inkrement entsteht.
Der Solution Train Engineer (STE) ist im Scaled Agile Framework (SAFe) das Pendant zum Release Train Engineer (RTE) auf Solution-Ebene. Während ein RTE die Koordination innerhalb eines Agile Release Trains (ART) sicherstellt, trägt der STE Verantwortung für die Koordination mehrerer ARTs und Supplier, die gemeinsam eine komplexe Lösung liefern.
Das Sprint Backlog ist eines der drei Artefakte in Scrum. Es gibt den Developern einen strukturierten Überblick über die für den aktuellen Sprint geplante Arbeit. Anders als das langfristige Product Backlog enthält es nur die Einträge, die auf das Sprint-Ziel einzahlen. Es besteht aus drei Elementen: dem Sprint-Ziel, den ausgewählten Product-Backlog-Einträgen und einem Plan zu deren Umsetzung. Das Sprint-Ziel beschreibt, warum der Sprint wertvoll ist, die Einträge definieren was geliefert wird, und der Plan skizziert wie. Für Erstellung und Aktualisierung sind die Developer verantwortlich.
Der Sprint-Fortschritt beschreibt, wie weit das Scrum Team auf dem Weg zum Sprint-Ziel ist. Die Developer sind dafür verantwortlich, den Fortschritt täglich im Daily Scrum zu überprüfen und das Sprint Backlog entsprechend anzupassen. Gemessen wird am Grad der Wahrscheinlichkeit, das Sprint-Ziel zu erreichen – nicht an der Zahl abgeschlossener Aufgaben.
Scrum ist ein leichtgewichtiges, aber hochwirksames Rahmenwerk für die Lösung komplexer Probleme. Es hilft Menschen, Teams und Organisationen, Wert durch adaptive Lösungen zu schaffen – auf Basis von Empirie und Lean Thinking.
Servant Leadership (dienende Führung) ist ein Führungsstil, bei dem die Führungskraft in erster Linie die Rolle eines Unterstützers einnimmt. Anstatt Anweisungen zu geben oder Macht auszuüben, befähigt sie ihre Mitarbeitenden, ihr volles Potenzial zu entfalten. Die Führungskraft stellt sich in den Dienst des Teams, indem sie Hindernisse beseitigt, Rahmenbedingungen schafft und die Selbstorganisation fördert.
Das Team Canvas ist ein strukturiertes, kollaboratives Werkzeug, mit dem Teams Mission, Ziele, Rollen, Werte, Regeln und Erfolgskriterien gemeinsam klären und verbindlich festhalten. Entwickelt wurde es von Alex Ivanov und Mitya Voloshchuk, inspiriert durch das Business Model Canvas von Alexander Osterwalder. Es dient als Team-Charter auf einer Seite und wird bei Kick-offs, Teambildung, Neuausrichtungen, Konfliktklärungen sowie in regelmäßigen Reviews eingesetzt.
In skalierten agilen Umgebungen richtet eine Teststrategie die Qualitätspraktiken über mehrere Teams, Programmebenen und Releases hinweg aus. In SAFe® ist Testen in Built-in Quality verankert: Qualität ist kein Nachgedanke, sondern Voraussetzung für Flow. Die Strategie verbindet Test-First-Praktiken, Automatisierung und Integration mit der gemeinsamen Kadenz der Program Increments.
Team-Motivation bezeichnet die kollektiven Rahmenbedingungen, Führungsstile, Strukturen und Werkzeuge, die die intrinsische Motivation von Teammitgliedern fördern und gleichzeitig externe Barrieren reduzieren. Motivation in Teams entsteht nicht in erster Linie durch externe Anreize, sondern durch ein Umfeld, das Autonomie, Sinn, Meisterschaft und Zugehörigkeit ermöglicht.
Test-Driven Development (TDD) und Behavior-Driven Development (BDD) sind Test-First-Praktiken und zentrale Elemente des Built-In-Quality-Prinzips im SAFe.
TDD ist eine Entwicklungstechnik, bei der Entwickler:innen zuerst einen fehlschlagenden Test schreiben, bevor sie die entsprechende Funktionalität implementieren. So wird sichergestellt, dass Code immer anhand klarer, überprüfbarer Kriterien entsteht.
BDD erweitert TDD, indem das Verhalten eines Systems in einer für Business und Technik gleichermaßen verständlichen Sprache beschrieben wird. So entsteht eine gemeinsame Basis für Entwickler:innen, Tester:innen und Business-Stakeholder.
Beide Praktiken sorgen dafür, dass Anforderungen früh validiert werden, Software wartbar bleibt und Inkremente konsistent den Kundenerwartungen entsprechen.
Tokens sind die kleinsten Verarbeitungseinheiten, mit denen viele KI-Sprachmodelle (Language Models) arbeiten. Wer Tokens versteht, versteht besser, warum Prompts manchmal gekürzt werden müssen, warum lange Dokumente nicht immer vollständig verarbeitet werden können und warum KI-Anwendungen Kosten, Geschwindigkeit und Antwortqualität über die Länge und Struktur von Eingaben steuern. Tokens sind damit ein Schlüsselbegriff für den praktischen Einsatz generativer KI in Unternehmen.
Team Topologies (Matthew Skelton, Manuel Pais) ist ein praxisnahes Organisationsmodell, um Teams für schnellen Wertfluss zu strukturieren. Kernelemente sind vier Teamtypen (Stream-aligned, Enabling, Complicated-Subsystem, Platform) und drei Interaktionsmodi (Collaboration, X-as-a-Service, Facilitating). Leitend ist die Begrenzung kognitiver Last je Team sowie die bewusste Gestaltung von Team-Schnittstellen im Sinne von Conway’s Law.
Technische Schulden sind Design- oder Implementierungsentscheidungen, die zukünftige Änderungen verteuern oder erschweren. Der Begriff geht auf Ward Cunningham (1992) zurück: Er verglich unvollständigen oder suboptimalen Code mit einem Kredit – er ermöglicht zunächst schnelle Lieferung, verlangt jedoch „Zinsen“ in Form erhöhter Wartungs- und Anpassungskosten, wenn er nicht zeitnah getilgt wird.
Eine Teststrategie in der Hardwareentwicklung beschreibt die übergreifenden Prinzipien, Verantwortlichkeiten, Methoden und Nachweise, mit denen elektronische und mechatronische Systeme über den gesamten Lebenszyklus hinweg auf Funktionalität, Sicherheit, Zuverlässigkeit und Konformität geprüft werden. Sie verankert „Built-in Quality“ von der Konzeptphase bis in die Serie, ordnet Testebenen und -arten, Normenanforderungen und Produktionsprüfungen systematisch ein und definiert messbare Qualitätsziele.
Eine Software-Teststrategie ist das organisationsweite Leitbild dafür, was getestet wird (Qualitätsziele), wie (Methoden, Stufen, Automatisierung), wann (Pipelines, Gates) und wer (Rollen). Sie verbindet präventive Ansätze (TDD, BDD, Design for Testability) mit aufdeckenden (Regression, exploratives Testen), integriert Automatisierung in CI/CD und koppelt Qualität an Geschäftsergebnisse und Flow-Kennzahlen.
Testautomatisierung ist der gezielte Einsatz von Software-Tools und Frameworks, um Tests zu entwerfen, auszuführen, Ergebnisse zu vergleichen und Berichte zu erzeugen – reproduzierbar, schnell und mit klarer Evidenz. In SAFe ist Automatisierung Kernelement von Built-In Quality und der Continuous Delivery Pipeline: Ohne hohe Automatisierungsgrade sind kurze Iterationen, kontinuierliche Integration und verlässliche Systemdemos nicht nachhaltig machbar.
Die Theory of Constraints (TOC) ist eine Managementphilosophie, entwickelt von Eliyahu M. Goldratt. Sie besagt, dass jede Organisation oder jedes System durch einen einzigen Engpass limitiert wird – und dass gezielte Verbesserungen dieses Engpasses den schnellsten Weg zur Steigerung des Durchsatzes (Throughput) darstellen. Alle anderen Optimierungen außerhalb des Engpasses führen bestenfalls zu lokalen, ineffektiven Verbesserungen.
Timeboxing ist eine Technik des Zeitmanagements, bei der für eine Aktivität ein fester Zeitraum definiert wird, in dem diese Aufgabe begonnen und abgeschlossen werden soll – unabhängig davon, ob das Ergebnis perfekt ist. Nach Ablauf der Zeit endet die Aktivität, wird reflektiert und ggf. angepasst.
Das Toyota Production System (TPS) ist ein integriertes sozio-technisches Managementsystem, das Wertschöpfung durch Jidoka („Automatisierung mit menschlichem Augenmaß“) und Just-in-Time (JiT) radikal auf Fluss, Qualität und Verschwendungsfreiheit ausrichtet. Die beiden Säulen werden seit den 1950ern von Toyota systematisch entwickelt und bilden die Basis dessen, was später als „Lean“ bekannt wurde.
Eine User Story ist eine kurze, leicht verständliche Beschreibung einer Anforderung aus Sicht der Anwenderin oder des Anwenders. Sie ist ein zentrales Werkzeug agiler Arbeit (Scrum, SAFe®, Kanban) und folgt oft einer festen Formulierung, ergänzt um Akzeptanzkriterien.
Work in Process (WIP) beschreibt die Anzahl oder Menge an Aufgaben, die sich aktuell in Bearbeitung befinden, aber noch nicht abgeschlossen sind. Der Begriff stammt ursprünglich aus der Lean Production und wurde von Toyota geprägt, hat aber im Kontext von Wissensarbeit, Scrum und Kanban besondere Bedeutung: Zu viel WIP verlangsamt den Flow und erhöht Verschwendung.
Muda (Verschwendung), Mura (Unregelmäßigkeit/Schwankung) und Muri (Überlastung/Unzumutbarkeit) sind die drei Kernursachen von Ineffizienz im Toyota Production System (TPS). Ziel des TPS ist, Muri zu vermeiden, Mura auszudesignen und Muda zu eliminieren – in genau dieser Reihenfolge, weil Unregelmäßigkeit und Überlastung typischerweise erst die sichtbare Verschwendung erzeugen.
Weighted Shortest Job First (WSJF) ist eine Priorisierungsmethode, die in SAFe (Scaled Agile Framework) verbreitet ist. Sie berechnet eine Priorität für Arbeitspakete basierend auf dem Cost of Delay (CoD) geteilt durch die Job-Dauer (Duration) — also dem Verhältnis von wirtschaftlichem Verlust durch Verzögerung zu benötigter Umsetzungszeit. WSJF folgt dem Lean-Prinzip, den wirtschaftlich wertvollsten Nachfolger möglichst schnell zu liefern. In SAFe wird CoD typischerweise als Summe aus Business Value, Time Criticality und Risk Reduction / Opportunity Enablement verstanden.