Getting Quick Starting Points Without Mortgaging the Future
Introducing the Current Working System as Part of the Amplio Capability Development System
Frameworks are often justified as “a good starting point.” And to be fair, they do provide one. They give structure where there is uncertainty, a way to begin when the path isn’t clear. But there’s a hidden cost to that starting point. What begins as guidance quickly becomes gravity. Teams align around it, organizations invest in it, and before long, the starting point becomes the system itself—whether or not it actually fits the work being done.
When this is pointed out, the response is usually the same: “It’s just a starting point.” But that assumes something we rarely question—that a good starting point must eventually be abandoned or worked around. That trade-off is accepted as inevitable. It shouldn’t be. The real issue isn’t that frameworks provide a starting point. It’s that they provide one that is fixed, rather than one that is designed to evolve.
There’s another problem that makes this worse: the starting point is almost always chosen without a real diagnosis. It’s selected based on familiarity, popularity, or what others are doing—not on what is actually happening in the system. Without understanding where delays occur, how work flows, or what constraints are present, even a well-designed framework is likely to be misapplied. The result isn’t just that the starting point becomes fixed—it’s that it was often the wrong starting point to begin with.
Ironically, certification makes this even worse as it makes changing frameworks, and the corresponding certification exams, a slow-moving process. This is why the ACDS also includes several advanced practices that are missing in popular frameworks.
This is where the idea of the Current Working System comes in. Instead of adopting a predefined structure, we begin by understanding how work is actually happening today—how value flows, how decisions are made, and where learning is occurring or blocked. From there, we make deliberate changes based on what we see, and evaluate those changes through real outcomes. There is always a current working system. The difference is whether we are constrained by it—or continuously improving it.
1. Introduction — What This Is and Why It Works
The Amplio Capability Development System (ACDS) is a system for developing capability through diagnosis, guided action, and continuous learning embedded in real work.
It integrates effective practices in the context of:
System dynamics (how workflows)
Cognitive dynamics (how people perceive and decide)
Learning dynamics (how capability is built over time)
A common challenge in organizational improvement is finding a “starting point.” Most approaches solve this by providing a framework. But frameworks often become stagnation points—adopted without understanding, enforced without adaptation, and sustained even when they no longer work.
The ACDS solves this differently. It creates a current, agreed-upon workflow called the Current Working System.
This provides a structured starting point without becoming a fixed, stagnant solution.
Instead of being implemented, it is:
Selected based on diagnosis
Treated as a hypothesis
Evaluated through real outcomes
Adjusted or abandoned based on evidence
This shifts the focus from:
Implementing a solution
to
Learning how the system actually works
The result is not standardization of work, but standardization of learning about work.
2. The Amplio Capability Development System
The Amplio Capability Development System develops capability through:
Diagnosis of the system
Guided changes in how work is structured, and decisions are made
Continuous learning embedded in execution
Its purpose is not to introduce practices, but to:
Improve flow
Improve decision-making
Accelerate learning
3. The Role of the Current Working System
Within this system, the Current Working System provides a structured way to test changes to how work flows and how decisions are made. It is not a framework to implement, but a hypothesis to evaluate—selected based on diagnosis, applied in context, and continuously tested through real outcomes.
What makes this approach effective is not the current working system itself, but how it is used. The current working system is only evaluated when key conditions are in place, assessed through explicit failure signals, and changed or abandoned when it does not improve flow, outcomes, or learning. This prevents teams from mistaking activity for progress or persisting with ineffective approaches.
In this way, the current working system enables coherent, system-level change while preserving Amplio’s core principle: we are not standardizing work—we are standardizing how we learn about and improve the system.
The current working system is applied using a scientific mindset. It is not treated as a solution to implement, but as a hypothesis to test. Based on the system diagnosis, we form a view of what changes to structure, flow, and decision-making might improve outcomes. That view is then applied in real work and evaluated through observable results—flow, stakeholder outcomes, and learning. If the expected improvements do not occur, the current working system is adjusted or abandoned. This ensures that progress is driven by evidence and feedback, not by adherence to a predefined approach, and prevents the starting point from becoming a stagnation point.
3.1 What the Current Working System Is
The Current Working System is:
A testable configuration of capabilities used within the system to accelerate learning and improvement
It is used to:
Make changes visible and coherent
Avoid random, disconnected interventions
Provide a baseline for learning
3.2 What It Is Not
The Current Working System is not:
A required structure
A best practice
A default starting point
4. How It Works (Flow of Use)
4.1 Step 1 — Diagnose the System
Identify:
Where delays occur
Where feedback is too slow or missing
Where decisions are misaligned
What capabilities are missing
You can run a diagnosis on the basis of what’s missing (see figure 1) or by asking questions about what your challenges are (see figure 2).
Figure 1. Diagnosing by looking for what’s missing.
Figure 2. Diagnosing by looking for challenges.
4.2 Step 2 — Select or Shape a Current Working System
Based on the diagnosis:
Choose or adapt a Current Working System
Treat it as:
A hypothesis about what will improve flow, learning, and outcomes
In addition to providing insights on what needs to be added or improved, the diagnostic provides insights on choices to make. These include:
- Flow vs Sprints
- Estimation methods
- Value flow architecture choices
- Classes of service
- The extent to implement Value Driven Objectives (VDO, an advanced requirements approach that goes well beyond user stories).
4.3 Step 3 — Apply It in the Work
Use the current working system to:
Guide decisions
Align teams
Structure flow
But:
Do not enforce it rigidly
Do not assume it is correct
There are no police involved in this.
4.4 Step 4 — Observe and Learn
Evaluate:
Flow (speed, WIP, delays)
Outcomes (stakeholder value)
Learning (ability to adapt and improve)
4.5 Step 5 — Evaluate the Current Working System (Guardrails)
Before making any adjustments, evaluate the current working system using three guardrails.
Why this matters (Amplio alignment):
Without valid conditions:
Feedback is distorted
You violate diagnosis before solution
You lose cause-effect visibility
4.5.1 Guardrail 1 — Preconditions (Before You Trust the Current System)
Purpose: Ensure valid evaluation conditions
Question:
Are we actually applying this current working system as intended?
Check for:
WIP is explicitly limited
If not → flow signals are invalid
Work is aligned to the methods we’ll be implementing.
If not → outcome signals are meaningless
Intake is controlled
If not → system is unstable
Teams are attempting to finish work
If not → you are measuring activity, not flow
Dependencies are visible
If not → delays will be misattributed
If these are not true:
Do not evaluate the current working system. Fix the conditions first.
4.5.2 Guardrail 2 — Failure Signals (Is the Current Working System?)
Purpose: Detect lack of improvement
Question:
What evidence tells us this current working system is not beingn effective?
Look for:
Flow signals
Work is not finishing faster
WIP is stable or increasing
Lead time variability is high
Outcome signals
Stakeholder objectives are not improving
QVRs are not delivering meaningful value
Learning signals
Same problems persist across cycles
Teams cannot explain why things are happening
Adjustments are reactive, not informed
Critical rule:
Busyness is not evidence of improvement.
If failure signals appear:
Assume the current working system is wrong or incomplete
—not that people need to try harder
4.5.3 Guardrail 3 — Exit Conditions (When to Change or Abandon the Current Working System)
Purpose: Prevent persistence with ineffective approaches
Question:
When do we stop using the current working system—or parts of it?
Trigger exit when:
Flow does not improve after 2–3 meaningful feedback cycles
Stakeholder outcomes remain unchanged or degrade
Teams are compensating around the current working system
Local optimizations are increasing
System constraints are unchanged
Levels of exit:
Adjust
Modify parts of the current working system
Change policies
Replace components
Swap structural elements
Abandon
Discard the current working system entirely
Return to diagnosis
Critical rule:
Loyalty is to learning—not to the current working system.
4.6 Step 6 — Adjust the System
Modify the current working system
Replace parts of it
Or abandon it entirely
5. The Key Integration Principle
The Current Working System is not how we standardize work.
It is how we standardize learning about work.
6. Why This Is Effective
Because you are still honoring the axioms:
1. Diagnosis before solution
The current working system is created as a result of the diagnosis
Not applied blindly
2. Inherent simplicity
Inherent simplicity is the principle that even complex systems are driven by a small number of underlying factors. By identifying these key dynamics—such as delays, dependencies, and feedback timing—you can understand what is actually shaping outcomes. This allows you to focus on what matters most, rather than being overwhelmed by surface-level complexity.
You are testing system-level configurations
Not adding practices randomly
3. Learning over implementation
The goal is:
Faster feedback
Better decisions
Not compliance
4. Language shapes perception
This must be stated frequently, as people see what is being spoken.
Calling it a “current working system” (or hypothesis-based system)
prevents people from seeing it as fixed
7. The Real Advantage
Without this approach:
Changes are isolated
Practices are added without coherence
Cause and effect are unclear
With this approach:
You create coherent, testable system changes
instead of fragmented improvements
8. The Current Working System (Detailed Structure)
8.1 A. System Alignment (Why we are doing anything)
Stakeholders
We must agree who our critical stakeholders are. And we must attend to their values, success criteria, and constraints.
8.2 B. Work Definition & Intake (What enters the system)
Intake Process
Gate work based on:
Alignment to VDO
Value vs delay cost
Explicitly limit intake (this is where most systems fail)
Book of Work
Single visible system of:
Committed work
Options
Organized by:
QVRs
Not features or teams
Classes of Service
Define policies for:
Expedite
Fixed date
Standard
Make trade-offs visible
8.3 C. Flow Design
Value Flow Architecture
Design the system, don’t inherit it.
The team draft practice
Includes:
Dev Teams
Organized around value delivery, not components
Capable of finishing work (not just starting)
Shared Services / DevOps
Managed as part of the system
Not external dependencies
Policies for access and prioritization
Value Flow Architecture Patterns
Cross-Functional Teams
Core teams
Shared team member
Borrow Team Member
Focused Solution Teams
Basic Lean-Agile Software Teams (BLAST)
Managing WIP
Explicit WIP limits across:
Teams
Value streams
Focus:
Finish rate
Not utilization
Value Stream Management
Creating awareness (inherent problem)
Measure:
Flow time
Delay
Rework
Optimize:
Whole system
Not local efficiency
8.4 D. Planning & Coordination
Big Room Planning (Reframed)
Not commitment ceremony
Used for:
Alignment on QVRs
Dependency visibility used for later dependency removal
Learning loops
8.4 E. Team-Level Execution
Flow / Sprints
Teams choose:
Flow-based or timeboxed
Based on:
Nature of work
Variability
Objective Stories
Replace user stories
Structured around:
Stakeholder
Objective
Measurable change
Connect directly to VDO
Team Estimation
Used sparingly
Purpose:
Enable sequencing
Not prediction theater
8.6 F. Management System
Management Role
Shift from:
Task oversight
toSystem design
Responsibilities:
Maintain alignment
Manage WIP
Enable flow
8.7 G. Learning & Adaptation
Core Coaching with the Amplio Learning Kata
The Amplio Learning Kata is a structured way of building capability through guided, step-by-step learning embedded in real work. It focuses on helping people see what matters, make better distinctions, and apply what they learn immediately—rather than separating learning from doing. Instead of prescribing answers, it develops the ability to diagnose, decide, and improve continuously.
Focus on:
Seeing the system
Improving decision-making
Not:
Enforcing practices
Dealing with Complexity
Use:
Smaller batches
Faster feedback
Avoid:
Over-analysis
Premature structure
8.8 H. Continuous Adjustment
Every element above is:
A hypothesis
Evaluated by:
Flow metrics
Stakeholder outcomes
Adjusted based on:
Evidence, not opinion
8.9 I. Explicit Feedback Loops
Define:
Where feedback occurs
What signals matter
How decisions change
8.10 J. System Constraints Visibility
Make constraints explicit:
Prevent local optimization
Preserve system focus
If you don’t explicitly identify constraints:
People will optimize locally
You lose inherent simplicity