Agile Theater
Visible Agile activity (rituals, ceremonies, tooling) without meaningful outcome improvement in speed, predictability, or business impact.
Why it matters: Naming theater early prevents teams from scaling overhead instead of scaling value.
Related: /work-with-me/fixing-your-agility , /services
Operating-System Constraint
The highest-leverage systemic bottleneck in how priorities, decisions, and work flow across leadership, portfolio, and delivery.
Why it matters: If you solve the wrong constraint, local optimization looks busy but leaves core outcomes unchanged.
Related: /work-with-me/speed-and-impact-breakthrough , /work-with-me
Feature Factory
A delivery mode focused on shipping more features without validating whether those features improve customer or business outcomes.
Why it matters: High output can hide low impact. Naming feature-factory behavior helps leaders shift to outcome ownership.
Related: /blog/the-value-of-the-feature-factory , /services
Product Lab
A way of working where teams run product bets with explicit hypotheses, tight feedback loops, and outcome accountability.
Why it matters: Product labs help teams learn before they scale an idea that has not earned confidence yet.
Related: /work-with-me/figure-out-your-product-operating-model-strategy , /work-with-me/speed-and-impact-breakthrough
Product Operating Model
The practical system connecting strategy, product decisions, team topology, governance, and delivery behaviors around outcomes.
Why it matters: It is the difference between shipping features and shipping measurable business results.
Related: /product-operating-model , /work-with-me/figure-out-your-product-operating-model-strategy
Coordination Tax
The speed and focus penalty paid when teams spend too much energy on alignment overhead caused by dependencies and competing priorities.
Why it matters: Reducing coordination tax increases throughput without automatically increasing headcount.
Related: /blog/when-and-why-do-we-need-a-product-operating-model , /work-with-me/portfolio-agility
Portfolio Flow
How work moves through a portfolio from idea to delivered value, including intake quality, WIP discipline, and decision cadence.
Why it matters: Portfolio flow determines whether strategy gets realized or drowned in too much parallel work.
Related: /work-with-me/portfolio-agility , /the-portfolio-agility-trail-map
Right-to-Left Planning
A planning approach that starts from desired outcomes and delivery constraints, then pulls work through in a realistic sequence.
Why it matters: It reduces over-commitment and helps leadership avoid starting more than the system can finish.
Related: /work-with-me/portfolio-agility , /blog/actively-managing-portfolio-flow
Initiative Overload
A state where too many strategic initiatives run in parallel, creating hidden queues, context switching, and slower completion.
Why it matters: Initiative overload is a primary cause of execution drag even in teams with strong local practices.
Related: /blog/actively-managing-portfolio-flow , /work-with-me/speed-and-impact-breakthrough
WIP Limit
An explicit policy that caps active work to protect flow, expose bottlenecks, and improve completion predictability.
Why it matters: Without active WIP management, teams optimize starting work instead of finishing value.
Related: /blog/limiting-work-in-progress-wip-in-scrum-with-kanban-what-when-who-how/?ref=glossary , /work-with-me/get-professional-about-scrum-and-kanban
Flow Stewardship
Leadership behavior that actively protects focus, limits overload, and removes systemic blockers instead of only asking for status updates.
Why it matters: Teams cannot sustain flow if leadership keeps injecting conflicting priorities.
Related: /work-with-me/create-a-business-level-operating-system-leveraging-agility , /about
AI Activity vs AI Impact
AI activity is experimentation volume; AI impact is sustained business outcome change tied to ownership and measurable adoption.
Why it matters: Many organizations mistake pilot output for strategic progress.
Related: /ai-strategy , /work-with-me/ai-transformation-strategy-to-execution
AI Transformation
Changing how an organization chooses, funds, steers, and adopts AI work so faster tools can turn into business results. It shifts the focus from tool rollout, vendor selection, and prompt training to the constraints that limit flow to value.
Why it matters: Sprinkling AI across a broken operating model creates more noise and pilot theater. The useful work is changing governance, prioritization, and workflows so AI speed has somewhere valuable to go.
Related: /work-with-me/ai-transformation-strategy-to-execution , /ai-strategy
AI Value Realization
The discipline of checking whether AI-driven speed turns into customer, financial, risk, or workflow value rather than just more output.
Why it matters: AI makes it easy to generate more code, content, and options. If review, product validation, or user adoption cannot absorb that speed, the investment mostly creates queues.
Related: /work-with-me/ai-transformation-strategy-to-execution , /ai-strategy
AI Operating Model
The set of roles, decision rights, funding mechanisms, and learning loops designed to coordinate human + artificial intelligence to solve business constraints.
Why it matters: AI initiatives behave like product development under high uncertainty. Traditional project controls often create false certainty exactly when leaders need faster learning.
Related: /ai-strategy , /work-with-me/ai-transformation-strategy-to-execution
Agentic Development Lifecycle
A product and engineering lifecycle built for AI-assisted work, where specs, review, validation, and deployment keep pace with faster code generation.
Why it matters: When AI can turn code around in hours, slow planning and review loops become visible bottlenecks. The lifecycle has to manage the whole flow, not just the coding step.
Related: /ai-strategy , /work-with-me/ai-product-development-lifecycle
Spec-driven Development
A software development flow where a validated specification is written before code generation, giving AI enough context to produce work that can be reviewed and trusted.
Why it matters: AI generates code faster than many teams can review it. Spec-driven Development moves more thinking upstream into design and keeps validation explicit downstream.
Related: /ai-strategy , /work-with-me/ai-product-development-lifecycle
Adoption Signal
An observable behavior change showing that teams are truly using a new practice, tool, or operating model in day-to-day work.
Why it matters: Without adoption signals, transformation work defaults to activity tracking instead of outcome tracking.
Related: /blog/aarrr-pirate-metrics-for-change-adoption , /work-with-me/ai-transformation-strategy-to-execution
Evidence-Oriented Change
Running transformation as iterative bets with explicit hypotheses, leading indicators, and adaptation decisions.
Why it matters: This avoids big-batch transformation programs that consume energy without proving progress.
Related: /work-with-me/speed-and-impact-breakthrough , /blog/think-it-build-it-ship-it-tweak-it-a-business-fable
OKRs (Objectives and Key Results)
A goal-setting framework where Objectives define the qualitative direction and Key Results are measurable signals of progress toward that direction — connecting strategy to measurable outcomes at every level.
Why it matters: OKRs fail when they become reporting theater. Done well, they focus teams on outcomes over output and create alignment without micromanagement.
Related: /blog/fix-your-okrs-back-to-first-principles , /work-with-me/strategic-alignment-and-execution-at-scale-leveraging-okrs
SAFe (Scaled Agile Framework)
A configurable framework for scaling agile and lean practices across large organizations — combining Scrum, Kanban, Lean, and systems thinking into a structured operating model with defined roles, events, and artifacts.
Why it matters: SAFe provides a shared language for scaling; its value depends on how faithfully and contextually it is implemented rather than mechanically adopted.
Related: /blog/deconstructing-safe-criticism-focusing-on-the-spc-role , /work-with-me/scale-agility-leveraging-the-scaled-agile-framework
Kanban
A method for managing and improving knowledge work by making work visible, limiting work in progress, and actively managing flow — enabling teams to deliver value more predictably without prescribing iteration boundaries.
Why it matters: Kanban surfaces systemic bottlenecks that sprints can hide, making it especially powerful for operational and support contexts alongside product development.
Related: /blog/actively-managing-portfolio-flow , /work-with-me/get-professional-about-scrum-and-kanban
Value Stream
The end-to-end sequence of steps — from customer need to delivered value — that defines how work actually flows through an organization, cutting across team and department boundaries.
Why it matters: Most bottlenecks live at value-stream handoffs, not within individual teams. Optimizing teams in isolation without mapping the full stream produces local efficiency with system-level drag.
Related: /blog/actively-managing-portfolio-flow , /work-with-me/portfolio-agility
Cost of Delay
The economic impact of not delivering a piece of value sooner — quantifying what is lost per unit of time a feature, decision, or capability is delayed.
Why it matters: Cost of Delay reframes prioritization from "what is most important" to "what is most urgent given the rate of value loss" — a critical shift for portfolio decisions.
Related: /blog/don-reinertsens-cost-of-delay-intuition-exercise-a-facilitators-guide , /work-with-me/portfolio-agility
Business Agility
The organizational capability to sense market shifts, make fast decisions, and redirect resources to the highest-value opportunities — extending agile thinking beyond product delivery into leadership, strategy, and operations.
Why it matters: Technical agility alone cannot sustain competitive advantage; business agility requires changes in how leaders prioritize, fund, and govern — not just how teams deliver.
Related: /blog/how-to-drive-towards-business-agility-without-falling-into-transformation-theater-fireside-chat-with-jesper-boeg , /work-with-me
Cycle Time
The elapsed time from when work actively begins on an item to when it is delivered — a flow metric that reflects actual team throughput rather than velocity estimates.
Why it matters: Cycle time tells you how fast your system actually delivers; reducing it requires understanding and removing real bottlenecks, not increasing team effort.
Related: /blog/actively-managing-portfolio-flow , /work-with-me/get-professional-about-scrum-and-kanban