Dynamic Solution Trains · Solution Sync
Solution Sync
The Solution Sync keeps the Solution Roadmap reliable after the Solution Conference. It turns representative alignment into recurring update cycles, immediate decisions and closed-loop realignment between the Solution Train, Solution Areas and ARTs.
Connect
What is the change rate of your Solution Train?
The deck starts with a simple diagnosis: estimate how much the Solution Train roadmap changes during execution. The answer does not have to be exact. It is enough to reveal whether the train needs more alignment, more realignment or a different update cadence.
Stable roadmap
Only minor changes; the overall plan is fairly stable.
Mostly works
The initial plan works, but parts of the plan need correction.
Mixed reality
Around half of the plan is no longer optimal.
High volatility
The larger part of the plan does not work out as expected.
Small stable core
Only a small part of the initial plan can be executed as planned.
Discovery mode
Almost everything changes; realignment capability becomes the operating system.
Fundamental assumption
No one is allowed to plan the work for someone else.
A Solution Conference creates a starting point. In Solution Trains, only representatives are invited to the conference, so the alignment is hardened afterwards through update cycles with the people who do the work.
Concept 1
Update cycles make the roadmap trustworthy.
The deck frames reliability as a spiral: if the roadmap is not updated often enough, people stop relying on it. If update cycles are fast enough, the roadmap becomes the shared basis for decisions again. At least one update cycle per sprint is needed; one update cycle per week is recommended.
Solution Conference
Creates the first integrated roadmap hypothesis.
Solution Area refinement
Solution Areas check feasibility and update their own boards.
Solution Sync
Representatives integrate feedback and update the Solution Roadmap.
Final Solution Sync
Turns the latest roadmap into PI-Planning-ready input.
Roadmap relationship
Solution Area Roadmaps are the complement of the Solution Roadmap.
The Solution Roadmap represents the integrated alignment of all Solution Area Roadmaps. Each Solution Area Board shows team-level feasibility, neighboring Solution Areas, suppliers, and dependencies that must be fed back into the Solution Train level.
Concept 2
From alignment to realignment.
The higher you scale, the less stable an initial plan becomes over time. A lightweight organization therefore needs to reserve enough capacity for realignment and to decide quickly when the roadmap is drifting.
Before execution
Everyone who contributes to a plan is involved. It is usually plannable and less time-critical.
During execution
Only the people or teams affected by a change realign. It is often time-critical and not plannable upfront.
Speed matters
The faster the network realigns, the sooner it can get back into flow.
Concept 3
The Solution Sync is a decision event.
Information meetings are toxic for agile environments. A Solution Sync should be able to make immediate decisions, update roadmap artifacts and pull in subject matter experts or decision holders when the issue requires them.
Mini-PI-Planning
Run Solution Syncs as compact realignment loops.
The deck describes Solution Sync as a Mini-PI-Planning: create transparency, identify the issues that need resolution, use breakouts to solve them, then come back together to decide and realign.
All together
Get alignment on what changed and find important issues.
Breakouts
Resolve problem spaces with the people closest to the work.
Realignment
Come together, make decisions and update the roadmap.
Open issues
Carry unresolved issues explicitly into the next sync cycle.
Concept 4
Prepare Solution Sync decisions in advance.
If someone needs a decision in the next Solution Sync, they create an entry in the online Solution Sync Backlog and request the attendance of the people needed to make that decision.
Decision request
What decision should the next Solution Sync make?
Required people
Which representatives, SMEs or decision holders must join?
Prepared evidence
Which roadmap, board, dependency or constraint must be available?
Artifact update
Which Solution Roadmap or Solution Area Board will change?
Exercise 11 · 30 minutes
Running a Solution Sync
The exercise asks participants to design the cadence and choreography of Solution Syncs: how often they run, how they alternate with Solution Area Syncs and how the sync pattern may change across the second half of the PI.
Choose cadence
Daily, every second day, twice a week, weekly or once per sprint.
Alternate with Solution Area Sync
Design how local validation feeds the next Solution Sync.
Prepare participants
Decide who joins by default and who is available on standby.
Debrief trade-offs
Discuss cadence, overhead, decision quality and roadmap reliability.
Next step
Use Solution Sync to keep the Solution Roadmap alive.
Solution Conference creates the first alignment. Solution Roadmap makes it visible. Solution Sync keeps it reliable by turning new information into decisions and roadmap updates.
Back to Solution Roadmap Open Solution Conference Open Workshop Map