ATDD is a practical, acceptance-focused approach to clarifying requirements before implementation begins. When applied effectively, it enhances quality, transparency, and collaboration. Together with TDD and BDD, it creates a consistent bridge from the developer’s perspective to the customer’s acceptance view.
ADKAR makes change manageable at the individual level. Applied iteratively, reinforced by leadership and systemic enablers, it bridges the gap between project milestones and real behavior change.
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 provides a robust structure for change and transformation: analysis, design, development, implementation, and evaluation. Applied iteratively and combined with change-specific models, it significantly increases the likelihood of sustained success.
The Agile Manifesto is a foundational document of the agile movement, published in February 2001 by 17 software experts in Snowbird, Utah. It defines a set of values and principles that emerged as an alternative to heavyweight, plan-driven approaches to software development. Instead of focusing on detailed processes and tools, the manifesto emphasizes people, collaboration, working outcomes, and adaptability.
The ART Planning Board is a central transparency and alignment tool in SAFe PI Planning. It clarifies features, iterations, and dependencies, enabling realistic, coordinated planning. Beyond SAFe, the concept can be adapted to manage interfaces and dependencies in other large, multi-team environments.
The ACMP Standard Methodology defines the profession’s baseline for effective change management. Its five process groups ensure that readiness, strategy, planning, execution, and reinforcement are addressed in every initiative. By being methodology-neutral, it integrates with complementary models and provides consistency across industries. Through professional certifications and adoption in practice, it has become a central reference point for leading transformations successfully.
The Agile Release Train (ART) is a central construct in the Scaled Agile Framework (SAFe). It describes a long-term, cross-functional team of teams (usually 50–125 people) that jointly serves a value stream. An ART continuously delivers value to customers and stakeholders in fixed cycles called product increments (PI).
The term "train" illustrates that all teams get on board together, move at the same pace, and deliver synchronized results.
Ambidextrous Organizations combine efficiency in the core with radical innovation in new domains. They embody stability and change simultaneously – offering high potential but also facing significant cultural, structural, and leadership challenges.
The sum of all stakeholders' expectations of a product is formulated as requirements. A requirement always describes a specific function or property of the product. Once all requirements have been implemented, the product is complete.
But how can we ensure that the requirements are formulated in such a way that the finished product actually meets the expectations of the stakeholders? What we need are high-quality requirements that contain all the necessary information for the people implementing them and do not allow for individual interpretation.
Agile architecture is the way in which enterprise architects, system architects, and/or software architects apply architectural practice in agile software development. A number of commentators have identified a tension between traditional software architecture and agile methods along the axis of adaptation (postponing architectural decisions until the last possible moment) and anticipation (planning ahead).
The ART Sync is the central synchronization mechanism of an ART. It ensures alignment to PI objectives, transparency on dependencies, and integrated business-technical discussion. Properly facilitated, it fosters flow and value delivery; poorly facilitated, it risks devolving into ineffective reporting.
The Architect Sync is a core SAFe mechanism for making architectural decisions early, transparently, and collaboratively. It ensures the balance between long-term guardrails and emergent innovation, creating the foundation for sustainable agility at scale.
Batch size defines the scope of work processed in one cycle. Small batch sizes are a cornerstone of Lean and SAFe, as they enable faster learning cycles, lower risk, and greater flexibility – provided that organizational and technical conditions support their implementation.
BizDevOps combines product development and operations to bypass existing silos, shorten development cycles, reduce dependencies and increase overall product quality. It is an approach in which all necessary functions from within the company work together in a product team. BizDevOps is an approach to organisational development that builds on DevOps principles and expands them to include technical components.
Bridges’ Transition Model shows that transformation succeeds only when both the external change and the inner human journey are addressed. By deliberately guiding people through Endings, the Neutral Zone, and New Beginnings, organizations can reduce resistance, shorten adjustment times, and embed lasting change.
Built-In Quality is one of the core principles of the Scaled Agile Framework (SAFe). It emphasizes that quality cannot be inspected in at the end of the process, but must be embedded in every activity from the start. In SAFe, Built-In Quality is a prerequisite for value delivery: without it, Agile Teams, Agile Release Trains (ARTs), and Solution Trains cannot maintain the predictable flow of value to customers.
Business Process Redesign (BPR) is a radical, strategy-driven approach to fundamentally rethinking and transforming end-to-end business processes. Popularized in the early 1990s by Michael Hammer and James Champy (Reengineering the Corporation, 1993), BPR focuses on breakthrough performance in cost, quality, speed, and service. Unlike continuous improvement methods (e.g., Kaizen), BPR does not merely optimize existing processes but re-creates them from scratch to meet new strategic objectives.
Beckhard’s Change Model unites the D × V × F > R formula with a three-phase transformation process. It gives leaders and change agents a robust framework to design, steer, and sustain transformation—from the first diagnosis through the emotionally demanding transition to stable, measurable outcomes.
The Burke–Litwin Change Model is a research-based diagnostic and intervention framework for organizational change. Developed by W. Warner Burke and George H. Litwin (1992), it identifies twelve interrelated dimensions that explain how change unfolds within an organization.
Burn-down and Burn-up charts are proven agile visualization tools. Burn-down highlights remaining work, while Burn-up offers greater transparency by showing scope changes. They are most effective when applied as aids for learning and communication, not as mechanisms of control.
In the Scaled Agile Framework (SAFe), Business Owners are a key stakeholder role. They are primarily accountable for the business outcomes delivered by an Agile Release Train (ART) or Solution Train. They represent business interests and ensure that investments align with enterprise goals.
The Benefit Hypothesis is a key SAFe element for ensuring outcome orientation. It replaces rigid business cases with testable assumptions and fosters a culture of transparency, learning, and value focus.
The Business Context defines the strategic frame in which a company, program, or team operates. It includes market trends, regulatory requirements, customer expectations, competition, and internal factors such as vision, strategy, and financial goals.
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 describes a state of emotional and cognitive exhaustion, numbness, or apathy toward organizational change—triggered by too many, too rapid, or poorly integrated change initiatives. Important: Change fatigue is not a medical diagnosis; it overlaps with work-related stress but must be distinguished from burnout (ICD-11). Burnout is described by the WHO as a syndrome resulting from chronic, poorly managed work-related stress.
Clayton’s Change Curve describes the typical emotional-cognitive journey individuals and teams undergo during organizational change. The model was developed by Dr. Mike Clayton, adapting psychological transition models (such as the Kübler-Ross curve) for organizational settings. It consists of a sequence of phases (Denial → Reaction → Resistance → Discovery (aka Exploration) → Acceptance → Commitment), and features two axes (Emotional Focus vs. Rational Focus) as well as a distinction between a negative zone and a positive zone of change.
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.
The CDP is SAFe’s end-to-end value stream from idea to on-demand release, comprising Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand, anchored in DevOps/CALMR.
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 are a work item type in the Scaled Agile Framework (SAFe) at the solution level. They describe a larger business capability that spans multiple ARTs (Agile Release Trains) and typically requires several Program Increments (PIs) to implement. Capabilities are located in the solution backlog and are broken down into smaller features, which in turn end up in the ART backlogs. Capabilities thus form the bridge between portfolio epics and ART-related features.
Cross-functional teams (CFTs) are end-to-end responsible units with heterogeneous competencies (e.g., product, department, design, technology, compliance) that work together to deliver a clearly defined outcome. In agile contexts, they are small (typically up to 10 people) and have all the skills to generate value without external handovers.
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.
The Confidence Vote is a core element of PI Planning in SAFe. It measures the trust of participants in the feasibility of the PI Objectives and in the ART’s ability to deliver them.
In SAFe, Capacity Allocation is the mechanism by which an ART or team distributes its available capacity across different work types – business features, enablers, compliance work, or maintenance/debt reduction.
The Dual Operating System pairs hierarchical reliability with network speed. It succeeds when decision rights, budgets, metrics and handovers are explicit—and when leaders consciously balance paradoxes. Living Transformation® and Living Strategy raise cadence, discipline and outcome focus of the second system.
Delegation Poker is a playful method for coordinating the areas of responsibility and decision-making powers between team members and managers and creating clarity. The transparency gained also helps to align the different expectations of managers and team members.
Design thinking is an approach that focuses on creating compelling products or solutions from the user's perspective (customer-centric). Like design sprints, design thinking is a solution approach for challenges that are chaotic or complex according to the Cynefin framework.
DAD is a context-sensitive delivery framework. It is strong when paired with engineering excellence, lightweight governance, and skilled facilitation; weak when applied bureaucratically, lived with unclear roles, or driven without outcomes.
The Daily Scrum is a short, daily meeting of the Scrum team. It serves to review progress toward the Sprint goal and adjust the plan for the next 24 hours. The meeting is timeboxed to 15 minutes and is organized by the development team itself.
The Development Team is one of the three accountabilities defined in Scrum, alongside the Product Owner and the Scrum Master. It consists of professionals who are collectively responsible for delivering Product Backlog Items and creating a potentially releasable Increment at the end of each Sprint.
Development Teams are self-organizing (they decide how best to accomplish the work) and cross-functional (they have all the skills needed to deliver a complete Increment from concept to release).
The Definition of Done (DoD) is the formal description of the state of the Increment when it meets all required quality criteria. Once a Product Backlog Item meets the DoD, it contributes to a usable, potentially releasable Increment. The DoD creates transparency about what “done” truly means and prevents misunderstandings between teams, Product Owners, and stakeholders.
The Scrum Guide specifies: when multiple Scrum Teams work on the same product, they must share a common DoD. Team-specific additions are allowed, but they cannot replace or undermine the product-level DoD.
The Definition of Ready (DoR) is a central concept in agile working. It describes a series of criteria that a work item—for example, a user story, a feature, or an epic—must fulfill before it can be taken on by a team for implementation. The aim is to ensure that requirements are clear, understandable, and feasible. Only then can the team deliver reliably without getting bogged down in unnecessary discussions, blockages, or misguided developments.
Dynamic Capabilities capture an organization’s ability to constantly reinvent itself, sense opportunities, and transform accordingly. They integrate resilience, agility, and strategy into a framework for sustainable advantage in dynamic environments.
Enterprise agility (also known as business agility) is the ability of the entire organization to adapt quickly, predictably, and sustainably to changing conditions – with clear customer benefits and stable quality and cost profiles. This encompasses strategy, portfolio, operating model, governance, technology, and culture – not just IT.
Extreme Programming (XP) is an agile software development methodology focused on short, iterative cycles, continuous feedback, and technical excellence. Iterations usually last 1–2 weeks and deliver working software increments. XP emphasizes teamwork, openness, simplicity, and constant communication.
The ELMO card helps a team stay on topic during discussions, i.e. maintain focus. It allows you to say "Enough, let's move on" without actually saying it. The card is held up by one participant in the group or, in remote meetings, held up to the camera or posted as an image in the chat.
Reduce queue length means reducing the length of queues in the value stream. Queues arise when more work is started than is completed. Long queues lead to waiting times, delay feedback, reduce predictability, and increase the risk of work becoming obsolete or never being completed. In SAFe, as in Lean, reducing queues is a key lever for flow optimization.
The Flight Levels Framework, developed by Klaus Leopold, is a conceptual model that helps organizations create flow, alignment, and transparency across all levels. It distinguishes between three flight levels:
• Flight Level 1: Operational teamwork.
• Flight Level 2: Coordination between teams/value streams.
• Flight Level 3: Strategic control and alignment.
Unlike frameworks such as SAFe, Flight Levels is non-prescriptive: it does not prescribe roles or events, but focuses on the interaction between the levels.
Reduce queue length means reducing the length of queues in the value stream. Queues arise when more work is started than is completed. Long queues lead to waiting times, delay feedback, reduce predictability, and increase the risk of work becoming obsolete or never being completed. In SAFe, as in Lean, reducing queues is a key lever for flow optimization.
Get Faster Feedback means that results and hypotheses are reviewed as early as possible in order to reduce risks, accelerate learning, and deliver value faster. Feedback comes from customers, stakeholders, systems, or data—and is a key driver of lean-agile working methods.
Address bottlenecks means identifying systematic bottlenecks in the value stream and resolving them in a targeted manner so that the flow of work is not blocked. A bottleneck is any point where work accumulates—whether due to limited capacity, dependencies, or inefficient processes. In SAFe, this is actively shaping flow: don't accept bottlenecks, but make them visible and eliminate them.
Minimise Handoffs and Dependencies means reducing handovers and dependencies so that work can flow faster, with fewer errors and more autonomy across teams and value streams. Every handoff (e.g., transfer from Team A to Team B) costs time, creates friction, and increases the risk of misunderstandings. Dependencies between teams, ARTs, or external partners are a major cause of delays.
Optimize Time “In the Zone” means giving teams and individuals as much undisturbed time as possible for focused work. "In the Zone" describes a state of deep concentration (often known as "flow state"). Any interruption due to meetings, context switching, or waiting times reduces this state and slows down the flow of value. In SAFe, this is a key lever for increasing productivity and quality.
Remediate Legacy Policies and Practices means actively questioning and eliminating outdated rules, processes, and habits that hinder the flow of value. Many organizations cling to practices that once made sense but now lead to waste, slowdowns, or frustration. SAFe explicitly identifies this as one of the eight accelerators for flow.
The Flow Accelerators are eight recommendations for action in the Scaled Agile Framework that help organizations accelerate value flow across teams, ARTs, and portfolios. They are practical levers for removing obstacles, eliminating bottlenecks, and continuously delivering faster, more efficiently, and in a more customer-focused manner.
Reducing batch size is a core Lean-Agile principle that accelerates flow, reduces variability, and lowers hidden costs while enabling faster feedback and earlier risk discovery. In SAFe, it is applied through decomposition (Epics → Features → Stories), PI Planning with smaller increments, and Lean Budgets funding value slices. Benefits include greater predictability, faster learning, and adaptability—though challenges like over-slicing, cultural resistance, and the need for vertical slicing skills remain. Advanced practices such as set-based design, WSJF prioritization, and flow metrics help optimize batch size. At CALADE, we see it as a mindset shift toward value-driven delivery that enhances learning and reduces systemic risk.
A Gemba Walk is a management practice from the Toyota Production System (TPS) and lean management. "Gemba" (現場) means "the real place" – i.e., the place where value creation actually takes place (factory floor, office, IT system, service desk). In a Gemba Walk, managers, coaches, or consultants go to the place where things happen to observe processes, involve employees, understand causes, and promote improvements.
Goodhart’s Law shows that when metrics become targets, they stop being reliable measures. By designing rich, adaptive measurement systems and fostering a culture of learning, organizations can turn this warning into a strategic advantage—ensuring that metrics drive real progress instead of mere gaming.
This final English version has been verified for correctness, logical consistency, and smooth readability.
The Iceberg Model is a powerful metaphor for understanding the hidden complexity of organizational change. Like an iceberg, only a small part of the factors that determine the success of a change initiative are visible above the waterline. These visible elements include structures, processes, measurable goals, and observable behaviors. Beneath the surface lies the much larger, invisible part: mindsets, values, emotions, unwritten rules, informal networks, and power dynamics.
The Inspect & Adapt (I&A) workshop is a central element of the Scaled Agile Framework (SAFe). It takes place at the end of a Program Increment (PI) and serves to systematically reflect, measure, and initiate improvements. The aim is not only to evaluate the work results, but also to continuously develop collaboration, processes, and structures.
In agile product developments, an Increment (often “Product Increment”) is the working output of an iteration that builds upon all previous work. Each Increment is the sum of all “done” Product Backlog items completed so far. For example, the Scrum Guide defines an Increment as “the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints” – and requires that each new Increment be “Done” (meeting the team’s Definition of Done) and be in usable condition . Similarly, Scrum Alliance notes that a product increment is “whatever you previously built, plus anything new you just finished in the latest Sprint, all integrated, tested, and ready to be delivered or deployed” .
The IP iteration (Innovation & Planning Iteration) is a central element in the Scaled Agile Framework (SAFe). It takes place at the end of a Program Increment (PI) and serves as a buffer, innovation space, and planning time. While regular iterations focus on delivering features and stories, the IP iteration deliberately creates space for innovation, training, exploration, and preparation.
An impediment is any obstacle that prevents a Scrum or agile team from making progress toward its goals. Impediments can arise on different levels: within the team, in the organizational environment, or through external dependencies. Typical examples include technical problems, unclear requirements, conflicts within the team, or organizational bottlenecks such as missing decisions.
An Increment (Product Increment) is the usable, integrated work result of an iteration that builds on all previous increments. It represents the sum of all “Done” Product Backlog items since the beginning of the product and must be in a potentially releasable state.
In Scrum, at least one Increment is created per Sprint. In SAFe, Team Increments are created per iteration; at the ART level, these integrate into a System Increment. Over the course of a Program Increment (PI) (typically 8–12 weeks), an ART delivers incremental value in the form of working software or systems, demonstrated in System Demos and during Inspect & Adapt.
The Johari Window, developed in 1955 by psychologists Joseph Luft and Harrington Ingham, is a classic framework for self-awareness, feedback culture, and interpersonal communication. It illustrates how information about an individual is shared and perceived, showing the dynamic interplay between self-disclosure and feedback. The model’s purpose is to enlarge the Open Area, where self-perception and external perception overlap, thereby strengthening trust, transparency, and collaboration.
The Kanban Framework is an approach to agile working and continuous improvement that was originally applied to knowledge work by David J. Anderson. It is based on principles from the Toyota Production System (Lean) and focuses on the visualization of work, limiting work in progress (WIP), and continuous flow.
Important: Kanban is not a rigid process model with fixed roles or events, but a flexible, evolutionary change framework that helps organizations improve their processes step by step.
The KATGAR Change Model provides a practical, holistic framework for leading organizational change. By combining strategic clarity, ongoing communication, people-centered motivation, shared learning, and cultural anchoring, it enables organizations to design and sustain meaningful transformation. Although not an academic standard, KATGAR offers a robust, field-tested approach for experts seeking to achieve lasting impact in complex change environments.
The Kirkpatrick Model offers a clear, proven structure to evaluate and improve training and transformation initiatives. By connecting participant reactions, learning outcomes, behavioral change, and organizational results, it helps organizations ensure that investments in people translate into tangible business value. CALADE integrates this model with modern agile and strategic practices to make training and transformation measurable, actionable, and sustainable.
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 (改善) means "continuous improvement." It is a management and learning philosophy that calls for small, effective improvements every day, everywhere, by everyone – based on a scientific approach (PDCA/PDSA), respect for people, and consistent problem solving at the place of value creation (Gemba). Historically, Kaizen has shaped the Toyota Production System (TPS) and is at the core of Lean.
In the SAFe framework, the Lean-Agile Center of Excellence (LACE) is the permanent team that leads, coordinates, and accelerates organizational change toward a lean-agile corporate culture. It is an institutionalization of change management, comparable to a competence center that sets standards, further develops methods, and ensures the scaling of agile working methods across the entire organization.
Living Strategy is an approach to participatory, iterative, and continuous strategy work. Unlike traditional strategy models, which operate in multi-year cycles and with static top-down planning, Living Strategy® understands strategy as a living process:
• in short cycles (strategy sprints),
• with active participation from the organization (not just the board or staff),
• closely linked to implementation and feedback,
• made visible through clear artifacts (e.g., strategy backlog).
The goal: strategy becomes connectable, adaptable, and permanently effective—not just a piece of paper in a filing cabinet.
Living Transformation® is a lightweight, incremental transformation framework. It organizes change not as a one-time program, but as a continuous three-month cycle, known as a Transformation Increment (TI). Each TI starts with a Transformation Increment Planning Event (TIPE), leads to verifiable results ("Transformation Changes") via clearly defined events, roles, and artifacts, and ends with a Measure & Improve. Core principle: Change comes from within, with clearly defined employee capacity – instead of outsourced shadow organizations.
Large-Scale Scrum (LeSS) is a framework for scaling Scrum to larger product development efforts. It is built on the same values, principles, and rules as defined in the Scrum Guide, but applies them to multiple teams working on one product. LeSS emphasizes simplicity, transparency, and learning, aiming to scale Scrum without adding unnecessary complexity or management layers.
Lean Portfolio Management (LPM) is a core element of the Scaled Agile Framework (SAFe) and describes the approach of combining an organization's strategy and financing with agile implementation structures. While classic portfolio management often focuses on annual budgets, projects, and output controlling, LPM focuses on continuous strategy implementation, value stream budgets, lean governance, and decentralized decision-making. LPM thus bridges the gap between the CxO level and operational delivery—with the goal of creating business agility at the enterprise level.
Leavitt’s Diamond is a classic organizational model developed by Harold J. Leavitt in 1965. It conceptualizes an organization as a system with four interdependent components: Tasks, Structure, Technology, and People. The core insight is that any change in one component inevitably affects the other three. This systems view makes Leavitt’s Diamond a fundamental tool for change management, organizational development, and transformation programs.
Little's Law is a fundamental rule of queueing theory from 1961 (John D. C. Little, MIT) that describes the relationship between work in progress (WIP), throughput, and cycle time/lead time. The formal equation is:
WIP = Throughput × Cycle Time
or, in classical queueing theory: L = λ × W, where L is the number in the system and λ is the arrival or departure rate. This law applies regardless of distribution assumptions or system details—provided that the conditions are stationary.
Leading and lagging indicators are complementary: leading enables early steering, lagging proves results. When combined thoughtfully, anchored in decisions, and safeguarded against gaming, they allow organizations to make change measurable, adaptive, and sustainable.
Lean budgets in SAFe replace project-based individual budgets with value stream budgets, creating a lightweight, rapidly adaptable financial and governance foundation for portfolio work. Lean-Agile Guardrails are the clearly defined guidelines that control and secure this budget model. SAFe distinguishes between four guardrails:
1. Directing investments according to horizons
2. Allocate capacity in a targeted manner
3. Approve significant initiatives
4. Ensure continuous business owner involvement
In this way, SAFe combines decentralized execution with clear financial control.
Mob Programming (sometimes referred to as “mobbing”) is a collaborative software and product development practice in which the entire team works together at the same time, on the same task, using the same computer or workstation. The concept was popularized by Woody Zuill and has since been adapted by organizations such as Tesla, where Joe Justice has described its role in enabling ultra-fast innovation cycles.
Magic Estimation is a fast, collaborative technique for relative sizing of many Product Backlog Items (PBIs) at once. The team silently places items into story-point “buckets” (e.g., 1, 2, 3, 5, 8, 13, 20 …), iteratively reorders them, and holds brief, focused discussions only where disagreement persists. Also known as Silent Grouping or Affinity Estimation, it is most effective when teams need to size a large backlog quickly.
Nexus is a lean scaling framework placing integration at its core. It succeeds only when organizations have sufficient maturity in engineering practices, discipline, and transparency.
Organizational Resilience is the ability not only to withstand crises but to use them as drivers of renewal and learning. Successful organizations build redundancy, foster trust and psychological safety, train for crisis readiness, and embed resilience into strategy. Applied pragmatically, resilience becomes a competitive advantage in volatile markets, balancing stability with innovation.
Objectives & Key Results (OKR) is a framework for agile strategy execution at organizational, team, and individual levels. It combines qualitative goals (Objectives) with measurable outcomes (Key Results). Typically, one to three Objectives are defined per cycle, each supported by three to five Key Results. The guiding principle is fewer but focused, ensuring prioritization and clarity of impact.
Organizational debt refers to the accumulated structural, procedural, and cultural legacy issues of an organization—e.g., outdated guidelines, role models, decision-making processes, or habits—that slow down today's value flow and incur costs "in interest" (more coordination, waiting times, rework). The term was coined by Steve Blank ("Organizational debt is like technical debt — but worse") and expanded upon by Aaron Dignan (Brave New Work) as "interest charges that arise when structures/policies remain fixed while the world changes."
Planning Poker – also known as Scrum Poker – is an agile estimation technique based on team consensus. It is most often used in Scrum during Sprint Planning or Backlog Refinement sessions. The purpose is to estimate the relative complexity and effort of User Stories or features.
Product Backlog Refinement (formerly known as “Backlog Grooming”) is a continuous activity in Scrum where Product Backlog Items (PBIs) are reviewed, clarified, prioritized, and estimated. Unlike the five official Scrum events, Refinement is not timeboxed but occurs throughout the Sprint. It should typically consume no more than 10% of the Development Team’s capacity.
In the Scaled Agile Framework (SAFe), portfolio epics are the largest strategic initiatives at the portfolio level. They address significant investments that have a major impact on corporate strategy, value streams, or the business model. Examples include entering new markets, developing digital platforms, or establishing new product lines. Epics are too large and complex to be implemented directly by Agile Release Trains (ARTs) and therefore require analysis, prioritization, and control in the portfolio Kanban.
In SAFe, Portfolio Kanban is the visual flow system for managing strategic initiatives (portfolio epics) – from idea to implementation. It makes decision logic, WIP (work in process), risks, and the maturity level of projects visible and links strategy (LPM, lean budgets, and guardrails) with delivery in Solution Trains and ARTs.
The Product Backlog is the central artifact in Scrum and represents an ordered list of everything known to be needed in the product. It contains all work items that may deliver value: features, bug fixes, technical improvements, experiments, or enablers. The Product Backlog is dynamic and never complete. It evolves as the product and the organization learn. Work can begin as soon as there are enough well-defined items – completeness is neither required nor possible.
In the Scaled Agile Framework (SAFe), the Product Owner (PO) is a dedicated member of an Agile Team (typically 5–11 people) and acts as the “voice of the customer.” The PO’s main responsibility is to maximize product value by ensuring the team always works on the most valuable items. The role bridges business stakeholders and development teams, ensuring that short-term delivery aligns with long-term product strategy.
In Scrum, the Product Owner (PO) is one of the three accountabilities within the Scrum Team, alongside the Scrum Master and the Developers. The PO is accountable for maximizing the value of the product resulting from the team’s work. This role owns the Product Goal, ensures the clarity, transparency, and prioritization of the Product Backlog, and acts as the primary link between stakeholders and the Scrum Team. Unlike in scaled frameworks, in pure Scrum the Product Owner carries both strategic and tactical accountability for the product.
PI Planning (Program Increment Planning) is a central event in the Scaled Agile Framework (SAFe). It is the heart of large-scale coordination and typically takes place every 8 to 12 weeks. In this two-day planning workshop, all teams of an Agile Release Train (ART) – often 100+ people – come together to jointly define goals, dependencies, and priorities for the next Program Increment.
Planning Poker is a proven agile estimation technique that blends psychological insight (Wideband Delphi, collective intelligence) with practical team facilitation. For experienced Scrum Masters and agile coaches, it is a key practice for exposing hidden risks, fostering joint ownership and enabling accurate, value-driven forecasting—whether in single Scrum teams or in scaled environments like SAFe, LeSS and Nexus. Used thoughtfully, Planning Poker strengthens both predictability and team learning, turning estimation into a powerful driver of continuous improvement.
Psychological safety refers to the shared belief system within a team that it is acceptable to take interpersonal risks—such as expressing ideas, asking questions, or admitting mistakes—without fear of negative consequences such as exclusion or punishment. The term was coined in 1999 by Amy Edmondson (HBS).
The Project Manager is a traditional role in project-based work, accountable for planning, coordinating, and delivering projects within predefined scope, time, and budget constraints. A Project Manager typically serves as the central point of responsibility for aligning resources, managing risks, and ensuring stakeholders are informed and engaged.
In classical project management (e.g., PMI, PRINCE2, IPMA), the Project Manager balances the “iron triangle” of scope, time, and cost, while also addressing quality, risk, and stakeholder expectations. This role is widespread in industries where predictive, milestone-driven planning is dominant.
The Release Train Engineer (RTE) is a core role in the Scaled Agile Framework (SAFe®). Acting as a servant leader and coach, the RTE supports the Agile Release Train (ART) – a long-lived team of agile teams (typically 50–125 people) – in delivering value in a coordinated and predictable way. The RTE plays a role for the ART that is comparable to what a Scrum Master is for a single team: enabling, facilitating, and creating the conditions for self-organization and value delivery.
The Sprint Retrospective is one of the five official Scrum events (alongside the Sprint, Sprint Planning, Daily Scrum, and Sprint Review). It is held at the end of each Sprint, after the Sprint Review and before the next Sprint begins. According to the Scrum Guide, its purpose is to inspect how the last Sprint went with respect to individuals, interactions, processes, tools, and the Definition of Done, and to identify improvements for the next Sprint.
Risk ROAMing is a method from the Scaled Agile Framework (SAFe) for identifying, classifying, and transparently managing risks in large planning events such as PI Planning.
"ROAM" is an acronym for four possible states of risk:
• Resolved
• Owned (someone takes responsibility)
• Accepted (consciously accepted)
• Mitigated (reduced through measures)
The Solution Demo is the showcase of the Solution Train. It complements System Demos by providing an end-to-end perspective on complex solutions. Properly executed, it becomes a critical mechanism for transparency, feedback, and risk management in large-scale SAFe implementations.
The System Demo is the showcase of the ART. It provides visibility into progress, enables meaningful feedback, and builds trust between business and delivery. Through iteration demos and the PI System Demo, it becomes a cornerstone of transparency, alignment, and continuous improvement.
The Scrum Master is one of the three core accountabilities in the Scrum framework, alongside the Product Owner and Developers. A Scrum Master is a servant leader who supports the Scrum Team and the organization in understanding, applying, and continuously improving Scrum. They lead the process, not the people – enabling self-organization and fostering a culture of openness, transparency, and continuous improvement.
A Solution Train is the organizational construct in SAFe that coordinates multiple Agile Release Trains (ARTs) and suppliers to develop a large integrated solution (e.g., complex software platforms or cyber-physical systems). It is part of the Large Solution configuration and introduces additional roles, events, and artifacts (including STE, Solution Management, Solution Architect/Engineering, Pre-/Post-PI Planning, Solution Intent).
In Scrum, the Sprint is the fundamental timebox. It is the container for all Scrum events – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective – and enables continuous delivery of value. The Scrum Guide describes the Sprint as the heartbeat of Scrum, where ideas are turned into value. Sprints are of consistent length, never longer than four weeks, and follow one another without gaps: the next Sprint begins immediately after the previous one ends. This establishes a steady cadence, comparable to the rhythm of pedaling a bicycle – there is never a moment without a Sprint.
The Sprint Review is one of the five official Scrum events. It takes place at the end of each Sprint – after the Increment is completed and before the Sprint Retrospective. Its purpose is to inspect the outcome and adapt the direction: the Scrum Team and invited stakeholders review the Product Increment (only items that meet the Definition of Done), discuss what has changed in the environment, and collaboratively adapt the Product Backlog. The Sprint Review is a working session, not a status meeting or formal acceptance gate.
Systemic Coaching is a process-oriented, solution- and resource-focused approach for supporting individuals, teams, and organizations. It is grounded in systems theory, constructivism, and second-order cybernetics: reality is understood as socially constructed; the coach does not act as an expert who provides answers but as a facilitator of dialogue and reflection in which clients develop their own solutions.
System Architect/Engineeriis a key role in the Scaled Agile Framework (SAFe). It is responsible for the technical vision and architecture of a solution at the ART or solution level. While business and product management answer the "what" questions (which features/value), System Architect/Engineering takes care of the "how" – i.e., technical consistency, scalability, and sustainability.
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.
The Scrum Team is the fundamental unit of Scrum. According to the Scrum Guide 2020:
“The Scrum Team is small and cross-functional. It consists of one Scrum Master, one Product Owner, and Developers.”
There are exactly three accountabilities in a Scrum Team. Adding extra formal roles is discouraged, as it undermines team unity and contradicts Scrum principles.
In the Scaled Agile Framework (SAFe), the Solution Train Engineer (STE) is the counterpart to the Release Train Engineer (RTE) at the solution level. While an RTE ensures coordination within an Agile Release Train (ART), the STE is responsible for coordinating multiple ARTs and suppliers that jointly deliver a complex solution.
In short, the STE is the chief facilitator, coach, and servant leader for the entire Solution Train.
The Sprint Backlog is one of the three artifacts in Scrum. It provides the Development Team with a structured view of the work planned for the current Sprint. Unlike the long-term Product Backlog, the Sprint Backlog contains only the items relevant to the Sprint Goal. It consists of three elements: the Sprint Goal, the selected Product Backlog Items (PBIs), and a plan for delivering them during the Sprint. The Sprint Goal describes why the Sprint is valuable, the PBIs define what will be delivered, and the plan outlines how the work will be carried out. The Developers are accountable for creating and updating the Sprint Backlog.
Sprint progress describes how far the Scrum Team has advanced toward achieving the Sprint Goal. Developers are accountable for inspecting progress daily in the Daily Scrum and adapting the Sprint Backlog accordingly. Progress is measured by the likelihood of achieving the Sprint Goal, not by the number of completed tasks.
Scrum is a lightweight yet highly effective framework for complex problem solving. According to the Scrum Guide 2020:
“Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.”
Scrum is founded on empiricism (decisions based on experience and observation) and lean thinking (focusing on essentials, maximizing value). While originating in software development, Scrum is now applied in many industries, including product design, marketing, and organizational development.
Servant leadership was coined by Robert K. Greenleaf in the 1970s. At its core, it is an attitude in which leaders serve first before they lead: they create conditions in which people, teams, and organizations can develop their potential. Unlike traditional leadership models, the focus is not on control or status, but on responsibility, support, and creating meaning.
The Team Canvas is a structured, collaborative tool that helps teams clarify and agree on their mission, goals, roles, values, rules, and success criteria. It was created by Alex Ivanov and Mitya Voloshchuk, inspired by Alexander Osterwalder’s Business Model Canvas. The Team Canvas serves as a one-page team charter and is widely used for kick-offs, team formation, alignment, conflict resolution, and regular reviews.
In scaled agile environments, a test strategy aligns quality practices across multiple teams, program layers, and releases. In SAFe, testing is embedded in Built-in Quality: quality is not an afterthought but a prerequisite for flow. The strategy connects test-first practices, automation, and integration with the shared cadence of Program Increments.
Team Motivation refers to the collective conditions, leadership styles, structures, and tools that foster the intrinsic motivation of team members while reducing external barriers. Motivation in teams does not primarily result from external incentives but emerges through an environment that provides autonomy, purpose, mastery, and belonging.
Test-Driven Development (TDD) and Behavior-Driven Development (BDD) are test-first practices embedded in SAFe’s principle of Built-In Quality.
TDD is a development technique where developers write a failing test before implementing the corresponding functionality, ensuring that code evolves to meet testable requirements.
BDD extends TDD by describing system behavior in business-readable language, creating a shared understanding between developers, testers, and business stakeholders.
Both practices ensure that requirements are validated early, software remains maintainable, and increments are always aligned with customer expectations.
Team Topologies (Matthew Skelton, Manuel Pais) is a practical organizational model for structuring teams for rapid value flow. The core elements are four team types (stream-aligned, enabling, complicated subsystem, platform) and three interaction modes (collaboration, X-as-a-service, facilitating). The guiding principles are limiting the cognitive load per team and consciously designing team interfaces in line with Conway's Law.
Technical debt refers to design or implementation decisions that make future changes more expensive or difficult. The term was coined by Ward Cunningham (1992), who compared incomplete or suboptimal code to a loan – it enables rapid delivery initially, but requires "interest" in the form of increased maintenance and adaptation costs if it is not repaid promptly.
A test strategy in hardware development defines the overarching principles, responsibilities, methods, and evidence used to ensure that electronic and mechatronic systems meet requirements for functionality, safety, reliability, and compliance across the product lifecycle. It provides the long-term quality framework for design, validation, and production, integrating test levels and methods, industry standards, and measurable quality
A software test strategy is the organization-wide framework describing what to test (quality goals), how (methods, levels, automation), when (pipelines, gates), and who (roles). It combines preventive approaches (TDD, BDD, design-for-testability) with detective ones (regression, exploratory), integrates automation into CI/CD, and ties quality to business outcomes and flow metrics.
Test automation is the deliberate use of software tools and frameworks to design, execute, compare results, and report tests—reliably, repeatably, and fast. In SAFe, automation is a core enabler of Built-In Quality and the Continuous Delivery Pipeline: without high automation, short iterations, continuous integration, and credible System Demos are not sustainably achievable.
The Theory of Constraints (TOC) is a management philosophy developed by Eliyahu M. Goldratt. It states that every organization or system is limited by a single bottleneck – and that targeted improvements to this bottleneck are the fastest way to increase throughput. All other optimizations outside the bottleneck lead, at best, to local, ineffective improvements.
Timeboxing is a time management technique in which a fixed period of time is defined for an activity, during which this task should be started and completed – regardless of whether the result is perfect. Once the time has elapsed, the activity ends, is reflected upon, and adjusted if necessary.
The Toyota Production System (TPS) is an integrated socio-technical management system that radically focuses value creation on flow, quality, and waste elimination through jidoka ("automation with human judgment") and just-in-time (JiT). These two pillars have been systematically developed by Toyota since the 1950s and form the basis of what later became known as "lean."
A user story is a short, easy-to-understand description of a requirement from the user's perspective. It is a key tool in agile working (Scrum, SAFe, Kanban) and often follows this format:
"As [role], I want [function] to [benefit]."
Example: "As a customer, I want to be able to track my order online so that I know the delivery status at any time."
User stories help teams focus on customer benefits rather than technical details.
Work in Process (WIP) describes the number or quantity of tasks that are currently in progress but not yet completed. The term originally comes from lean production and was coined by Toyota, but it has special significance in the context of knowledge work, Scrum, and Kanban: Too much WIP slows down the flow and increases waste.
Muda (waste), Mura (irregularity/fluctuation), and Muri (overburden/unreasonableness) are the three root causes of inefficiency in the Toyota Production System (TPS). The goal of TPS is to avoid Muri, eliminate Mura, and eliminate Muda – in precisely this order, because irregularity and overload typically cause visible waste in the first place.
Weighted Shortest Job First (WSJF) is a prioritization method commonly used in SAFe (Scaled Agile Framework). It calculates a priority for work packages based on the cost of delay (CoD) divided by the job duration — i.e., the ratio of economic loss due to delay to the time required for implementation. WSJF follows the lean principle of delivering the most economically valuable successor as quickly as possible. In SAFe, CoD is typically understood as the sum of business value, time criticality, and risk reduction/opportunity enablement.