When the program office runs Waterfall and the delivery team runs Scrum
A lot of teams don't get to pick one methodology. The client contract or the internal audit function is gated on formal phases and sign-offs — discovery, design approval, build, UAT — while the people actually writing code want sprints, a backlog, and a Kanban board they update daily. Force everyone onto one system and something breaks: either the sprint team starts maintaining a shadow Excel timeline for the steering committee, or the compliance side loses visibility into what's actually done versus what's still "in progress" on a card nobody reopened.
The fix isn't picking a side. It's mapping the two views onto the same underlying work instead of maintaining them separately: a BPMN process defines the formal gates (design approved → build → UAT → sign-off), and each gate corresponds to a real state a task or column can be in on the board. Move the card, the process instance advances; nobody re-types status into a second tool.
Symptoms and cost of running two disconnected systems
| Symptom | Cost |
|---|---|
| Steering committee timeline lives in a separate deck from the sprint board | Two versions of "done"; someone reconciles them by hand before every review |
| Gate approval tracked in email threads | Nobody can say which gate a piece of work is actually at without asking |
| Sprint velocity reported without mapping back to program phase | Finance and delivery argue about progress using different numbers |
| Audit trail reconstructed after the fact | Compliance review takes days instead of a query |
A six-step framework for mapping BPMN gates to Kanban flow
1. Model the real gates, not an idealized process
Draw the BPMN process for what your program actually requires — design sign-off, security review, UAT, go-live — not a generic textbook diagram. Each gate is a state a task needs to pass through, not just a milestone on a slide.
2. Map each gate to a Kanban column or status
In WKFGo, StatusColumnMap binds a task's board column to a status the process cares about, so a card moving from "In Review" to "Approved" is the same event as the process instance clearing that gate — not two separate updates.
3. Let sprints run inside the gates, not around them
Between two formal gates, the team plans and runs normal Scrum: backlog, sprint, standup, retro. The BPMN layer doesn't care how the team gets from "build started" to "build complete," only that the gate criteria are met when it does.
4. Give the process owner one view, not two
The person accountable for the formal process should be able to see gate status without asking the dev team for a manual update — that's the whole point of connecting the two systems instead of running them in parallel.
5. Scope access by role
Not everyone needs to see or move every gate. A client-facing PM may need read access to sign-off status without edit rights on the sprint board; a developer needs the reverse. Feature-level access keeps both groups working in the same system without stepping on each other.
6. Pilot on one program before rolling out the mapping org-wide
Run the gate-to-column mapping on one active program for two sprints, retro on what the process owner still can't see from the board alone, then adjust before asking every team to adopt it.
Anti-patterns to avoid
- Running the BPMN process and the Kanban board as two unrelated systems that someone reconciles manually
- Modeling gates nobody actually enforces, so the diagram drifts from reality within a month
- Giving every role edit access to every gate "to keep things simple"
- Treating the mapping as a one-time setup instead of revisiting it when the program's real gates change
How WKFGo helps
WKFGo's BPMN workflow editor (/workflows) models the formal process, and StatusColumnMap ties each gate to a real Kanban column so a card move is a gate transition — not a second data entry step. Process instances (ProcessInstance) carry the audit trail compliance needs, while the board underneath still runs ordinary Scrum or Kanban day to day. MCP tools like list_tasks, get_context_pack, and decision_inbox let an AI assistant or a steering-committee brief read the same state, grounded in the same data — not a second, drifting source of truth.
The honest limit: BPMN mapping is worth setting up when a real external gate — a client sign-off, a compliance audit, a regulator — requires it. If your team is purely internal and nobody outside engineering cares about formal phases, plain Kanban is simpler and the BPMN layer is overhead you don't need yet.
Getting started this week
Pick one program that already has a formal gate coming up — a client sign-off, a UAT window, an audit checkpoint. Model just that gate in BPMN, map it to the column the team already uses for "ready for review," and run one sprint through it. Name a single process owner who checks whether the gate status on the board matches reality. Adjust the mapping, not the process, if it doesn't.
Frequently Asked Questions
Do we need to model the whole program in BPMN before starting?
No — model the next gate that's actually coming up and expand from there. A program-wide diagram built before anyone has tested the mapping against real work is usually wrong in ways you won't find until it matters.
Does the process owner need to be technical?
No. The process owner is accountable for gate criteria and sign-off, not for how the dev team runs its sprints underneath.
Can this coexist with an existing PMO tool during migration?
Yes — export and links let you run both in parallel while people get comfortable, rather than forcing a hard cutover.
What's the AI's role here?
MCP tools read the same board and process state a human would — grounded status for a steering-committee brief, not a chatbot guessing at progress.
Ready to put this into practice?