Day 1 · Module 02 · Follow the Flow
Follow the Flow
This dedicated module page is ready for participants to map the coordination context, identify the Business Objectives at risk, and diagnose the Flow Problems that make those outcomes less likely.
- 01Learning frame
- Module 2 inside the shared 4C training architecture
- 02Total time
- 60 minutes
- 03Concrete Practice
- 15 min exercise + 5 min debrief
- 04Participant output
- Prioritized objectives + Flow Problems
- 05Module handoff
- One qualified Conference Candidate
C1 · Connection · 5 minutes
Where does most elapsed time disappear?
Begin with lived experience and treat every answer as a hypothesis. Ask tables for one real item and one place where it waits; capture exact verbs such as waits, returns, splits or escalates.
What moves?
Name the concrete work, decision, capability, customer case or evidence chain—not the whole transformation.
Where does it stop?
Look for waiting, return loops, splitting, queues and late decisions.
Who feels it?
Customer, operations, supplier, ART, platform or central function?
What is missing?
Decision, information, capacity, interface, authority or feedback?
What repeats?
One incident is a story; repetition suggests a system pattern worth testing.
“Where does most elapsed time disappear in your current flow?”
Speaker Notes
Activate current experience and convert vague frustration into observable hypotheses about where work waits, returns, splits or escalates.
How to facilitate
- Give tables a short prompt: name one real item and one place where elapsed time disappeared.
- Capture verbs exactly: waits, returns, splits, escalates, re-enters, queues, replans.
- Ask who felt the delay: customer, operations, supplier, ART, platform or central function.
Listen and watch for
- Generic statements such as communication is bad, dependencies hurt or we have too many meetings.
- Examples that are too large to trace, such as the transformation, the portfolio or all delivery.
- Stories that describe a symptom but not yet where work stopped.
Avoid
- Correcting participants too early. Treat early answers as hypotheses to test later.
- Starting a solution discussion. Park meeting ideas, governance ideas and role ideas.
- Letting one dramatic incident replace the search for repeated system patterns.
C2 · Concept · Slide 15 · Structural backbone
Use the Landscape as context—not as an organizational inventory
The five elements define what must eventually be understood to prepare a Value Stream Conference. In this 60-minute module, they act as one connected diagnostic model rather than five separate exercises.
Value Stream Landscape
ARTs, Solution Trains, Solution Areas, central functions, suppliers, traditional departments, shared platforms, customers and operations.
Business Objectives
The outcomes whose achievement probability is at risk because several units must align, sequence work or decide together.
Shared Initiatives
Cross-value-stream work such as architecture, AI/data, toolchain, compliance, supplier integration or transformation roadmaps.
Capacity Estimation
A rough view of where real capacity is available, constrained or already consumed by operations, maintenance, compliance or shared enablers.
Flow Problems
Observable interruptions where value waits, returns, splits, overloads shared capacity or misses timely decisions and feedback.
That scope is narrow enough for fifteen minutes and still produces a useful input for the next module.
Speaker Notes
Introduce Slide 15 as the structural backbone: Landscape, Business Objectives, Shared Initiatives, Capacity and Flow Problems are context layers for one diagnosis.
How to facilitate
- Explain that the five elements are not five separate mini-workshops in this module. They are layers that help the group understand why a problem is cross-boundary.
- Name the live practice boundary clearly: participants will actively use Business Objectives and Flow Problems; the other three layers remain context and validation prompts.
- Point to the highlighted cards and say that the exercise uses those two layers because fifteen minutes are available.
Listen and watch for
- The Landscape becoming an exhaustive organization inventory.
- Capacity discussions drifting into utilization comparisons rather than constraints that affect the objective.
- Shared Initiatives being treated as solutions before the Flow Problem is stated.
Avoid
- Asking for perfect org data before continuing.
- Classifying every large topic as a Value Stream Initiative.
- Losing the Business Objective in favor of an interesting but irrelevant structural detail.
C2 · Concepts · 25 minutes
Only the concepts that improve the diagnosis
The 60-slide Trainer Library contains optional depth and cases. The online path compresses it into seven participant-facing concepts while preserving its central distinction: diagnose the current interruption before designing another meeting.
-
01
Symptom is not Flow Problem
Separate the observed pain, the flow interruption, the cause hypothesis and the solution idea.
-
02
Objective sets direction
A Business Objective explains why the flow matters and which impact deserves attention first.
-
03
Flow Item is the thread
A capability, change, decision, customer case or evidence chain can be followed from Trigger to Value Point.
-
04
Three flow dimensions
Customer/product, technical/system and collaboration/decision flows rarely share the same bottleneck.
-
05
Eight diagnostic lenses
Use WIP, bottlenecks, handoffs, feedback, batch size, queues, realignment latency and legacy policies as search prompts.
-
06
Evidence has maturity
Move from suspicion to example, recurring pattern, measured evidence and objective impact—without pretending certainty.
-
07
Conference candidate is a test
Material impact, cross-boundary scope, observable evidence and conference leverage must all be visible.
Speaker Notes
Give only the concepts that make the practice sharper: distinguish symptom and Flow Problem, select an objective, follow an item, use three dimensions and make evidence visible.
How to facilitate
- Move briskly. Each concept earns its place only if it helps the group state a better Flow Problem.
- Use one running example if needed: an objective at risk because an interface decision arrives after ART commitments.
- Keep repeating the contrast: diagnosis first, conference design later.
Listen and watch for
- Solution language hidden in problem statements, such as we need an architecture sync.
- Objectives written as activities rather than outcomes.
- Flow Items that cannot be traced from Trigger to Value Point.
Avoid
- Teaching every optional research lens in detail.
- Making the evidence ladder feel like a maturity judgment.
- Letting participants believe the numeric score will replace judgment.
C3 · Concrete Practice · 15-minute exercise
Business Objectives at risk → prioritized Flow Problems
The group does not design the conference yet. It makes endangered outcomes visible, links them to current-state Flow Problems and selects the problem whose removal would most improve achievement probability.
Two quiet minutes prevent the loudest frustration from becoming the group’s problem statement by default.
-
0–2
Silent scan: objectives at risk
Each participant writes down the Business Objectives that feel endangered. Use one note per objective and add owner or time horizon when known.
-
2–5
Share and cluster the objectives
Put the notes together, merge duplicates and make local, shared, strategic, regulatory and technical outcomes visible without debating solutions.
-
5–7
Prioritize the objectives
Select the two or three objectives where current flow creates the greatest risk and where cross-unit coordination matters most.
-
7–12
Connect candidate Flow Problems
For each prioritized objective, ask which waiting, overload, handoff, feedback, batch, queue, realignment or policy problem reduces its achievement probability.
-
12–15
Prioritize the Flow Problems
Rank the strongest problems by impact, scope, urgency, coordination need and conference leverage. Select one candidate for Module 3.
| Business Objective at risk | Observable risk or impact | Candidate Flow Problems | Evidence or validation gap |
|---|---|---|---|
| Outcome + horizon + owner | What is becoming less likely? | Where does work wait, return, overload or receive feedback too late? | Example, pattern, measure, source or explicit unknown |
Prioritized Objective shortlist
Two or three Business Objectives whose achievement is materially threatened by current flow.
Prioritized Flow Problem backlog
Observable problems ranked by impact, scope, urgency, coordination need and likely conference leverage.
One qualified Conference Candidate
The problem that should drive Module 3: which decisions, people and prepared artifacts are required?
Speaker Notes
Run the fifteen-minute exercise so participants move from individual objective risk to a prioritized Flow Problem backlog without designing the solution.
How to facilitate
- Start with two quiet minutes. This creates individual thinking time before group convergence.
- Push for a short objective shortlist before discussing Flow Problems.
- Ask which problem, if reduced, would most improve achievement probability for the prioritized objective.
Listen and watch for
- The group arguing about portfolio priority instead of coordination risk.
- Flow Problems that are only symptoms, such as launch is late or quality is bad.
- Too many problems. Depth on one or two strong interruptions beats a wall of generic frustrations.
Avoid
- Solving the problem during the practice.
- Requiring perfect evidence before writing a candidate. Unknowns can be explicit validation gaps.
- Letting one department define a cross-boundary problem alone.
C3 · Concrete Practice · 5-minute debrief
Challenge the diagnosis before it becomes an agenda item
Use a neighboring group or a rapid plenary review. Repair only the most consequential gap; do not rebuild the whole map or debate solutions.
Which prioritized Business Objective would become more achievable if this Flow Problem were reduced?
What exactly waits, returns, splits, overloads or gets decided too late—and where?
Which units, roles, platforms, suppliers or functions make the problem cross-boundary?
What evidence exists today, and what remains an explicit validation gap?
Could a shared decision or artifact update materially change the flow—and what must Module 3 infer?
To achieve [objective], [flow item or work] must move from [trigger / start] to [value point]. Today, [observable interruption] at [boundary] causes [impact], supported by [evidence or explicit gap]. No single unit can resolve this because [cross-boundary reason].
Speaker Notes
Stress-test the strongest candidate so the next module receives a problem statement that can determine decisions, people and prepared artifacts.
How to facilitate
- Use the five questions quickly. The goal is to expose the most consequential gap.
- Require evidence or an explicit validation gap before accepting the candidate.
- Make the cross-boundary reason visible: no single ART, function or supplier should be able to resolve the whole issue alone.
Listen and watch for
- A problem statement that hides a preferred solution.
- Evidence that cannot be connected to a Business Objective or Value Point.
- Cross-boundary language that only means many people are annoyed, not that shared decisions or artifacts are needed.
Avoid
- Rebuilding the full map during the debrief.
- Demanding final root-cause proof in five minutes.
- Letting the debrief become a debate about who is to blame.
C4 · Conclusion · 5 minutes
See the system. Focus the objective. Qualify the problem.
Module 2 ends with a diagnosis—not a calendar design. Participants should be able to explain the selected candidate in thirty seconds and show where every clause comes from.
Use the five-part Landscape to set the coordination context.
Prioritize the Business Objectives whose achievement is genuinely at risk.
Link those objectives to observable Flow Problems rather than preferred solutions.
Make evidence, uncertainty, cross-boundary scope and conference leverage explicit.
Carry one qualified candidate into Ability to Decide.
“Our priority objective is [objective]. It is at risk because [Flow Problem] causes [impact]. We know this from [evidence]. Value Stream-level action is needed because [cross-boundary reason].”
Speaker Notes
Close with a crisp pitch and a clean handoff to Ability to Decide: the group knows what must flow, where it breaks and why a shared decision system is needed.
How to facilitate
- Ask for a thirty-second pitch using the displayed structure.
- Listen for objective, Flow Problem, impact, evidence and cross-boundary reason.
- Connect directly to Module 3: now we determine the decisions, people, prepared artifacts and update owners.
Listen and watch for
- The pitch omitting the Business Objective and only naming the local pain.
- The pitch sounding like an agenda or meeting proposal instead of a diagnosis.
- Confidence being overstated where the group only has a suspicion or one example.
Avoid
- Starting agenda design in the closing minutes.
- Accepting vague language such as alignment problem or dependency problem.
- Ending without a clear candidate for Module 3.
Trainer notes
Protect the investigation from premature conference design
Make the interruption observable enough that Module 3 can infer required decisions, people, inputs and artifact owners.
Shorten examples before shortening participant practice. Keep solution ideas on a visible parking lot.
Generic labels such as “communication”, “dependencies” or “too much WIP”. Ask: what waits, where, for whom and with which evidence?
Research grounding
The ideas behind the compressed online path
The primary source is the Module 2 Trainer Library. These public references support the instructional design, current-state mapping, evidence language and cross-boundary flow lenses used on this page.
- 4Cs instructional design A Quick Guide to the 4Cs Map
- Current-state mapping Lean Enterprise Institute · Value Stream Mapping
- Flow evidence The Kanban Guide
- Technical coupling DORA · Loosely Coupled Teams
- Flow accelerators SAFe · Accelerating Product Flow
Module handoff
From Flow Problem to Ability to Decide
The selected Conference Candidate becomes the input for deciding which people, decisions, prepared artifacts and update owners are needed.