Migrate from Kanban to ForgeSDLC

Start with the comparison: ForgeSDLC vs Kanban — flow, WIP, and where Forge adds ceremony intent and Versonas.

Forge embraces pull-based flow. This kit adds a lightweight spine so product, engineering, and assurance stay aligned without turning every column on the board into a meeting. Matrix context: Forge vs traditional methodologies.

Principles

Keep visualization, WIP limits, and service classes where they help
Charge = the decision-oriented slice of work in motion—not every card on the wall
Pause for reasons, not dates: refinement, planning (batch commitment if you use one), daily sync, review, Assay Gate when releasing, retro (meetings model)
Versonas when a discipline body of knowledge should govern the decision—not for every card move

Week 0–1

Submodule Blueprints; start with SDLC + disciplines that match your risk (often Testing, DevOps, Security for web products) (adoption playbook)
Define Charge explicitly: e.g. “In progress + blocked + awaiting decision,” or your team’s equivalent
Add a short daily sync if you drifted to fully async-only: Charge, blockers, decision owners

Flow-friendly planning

Use replenishment / commitment meetings the way you already do; layer Versona previews when incoming work touches regulated data, contracts, or shared architecture

Boards and tools

No requirement to replace Trello/Jira/Azure boards—map Sparks to your cards/tasks (naming reference)
If Kanban felt “everything optional,” Forge’s named ceremony intents restore inspection and improvement without Scrum’s fixed sprint box

Release and quality

Introduce Assay Gate discipline where you need evidence tied to acceptance criteria and IDs (ceremonies)
Log cross-cutting decisions (Ember Log, ADR, directive) so flow does not lose the audit trail

Anti-patterns

Using Versonas as status meetings
Expanding WIP inside “Charge” until it becomes the whole board—keep Charge small and committable

Next: Sponsors hub · Adoption playbook