Have a max of Work In progress that can be in the DOING lane based on size of team. Once that limit is hit, nothing else can move into the DOING lane, if other's are finished, they go help others until work starts moving into the DONE lane.
DONE means DONE, if it needs QA, Documentation, install script, whatever, it stays in DOING until it's truly DONE.
> DONE means DONE, if it needs QA, Documentation, install script, whatever, it stays in DOING until it's truly DONE.
Once you have this, you can expand the DOING with additional columns to represent those other stages.
If you implement a new (particularly user-facing) feature, you need to update your manuals. That may be a technical writer, it may be the developer or the tester, may be a team effort, doesn't matter really. So your columns (if this is a requirement for your business) become:
| TODO | PROGRAM | UPDATE MANUAL | REVIEW | DONE
This is one of the nice things about kanban. It's very fluid, really nothing is set in stone. Allow the board to represent the real process as you discover it.
To be clear, kanban cannot be directly compared to agile. Kanban is a tool, not a process, framework, or manifesto.
In all work, you have Done, and done. Capital-D done is when something is ready to be shipped (note: doesn't mean error free, just means it's as far as you're getting). Lower-d done is intermediate states. The kanban board allows you to capture those and relate it to your workforce and workload.
If I have 5 developers, practically speaking we cannot be working on more than 5 development tasks at a time. The kanban board visualizes how much we have going on and allows us to see when we've overreached. If I have 2 tech writers, again we can practically only work on up to two changes to the manual at a time. The kanban board visualizes this, and makes a useful tool within any production or development workflow.
Capital-D Done is that final column (integrated into the master branch, sitting on the loading dock, whatever). Lower-d done is captured by movement between states (Dev -> Test -> Review -> Manual Update -> Done). Of course, it also should be noted that movement can be backwards. This isn't Waterfall, we know that something may move back to dev or test from test or review.
The particular utility with agile is that it helps address the agile manifesto preference for people over processes. A process expressed on a kanban board is not set in stone (as a formally signed off Capital-P Process document would be in a typical enterprise shop). It's much more fluid, and can be redefined to capture the level of information needed by the team and those they work with (partner teams, or management).
I assume you've briefed yourself about Kanban by reading its Wikipedia article or something similar. "Kanban in Action" by Marcus Hammarberg and Joakim Sunden is a very good read if you're just starting to learn about Kanban.
I might recommend reading "Kanban from the Inside" by Mike Burrows. Where "Kanban in Action" is a very practical explanation, "Kanban from the Inside" focuses on the core values.
Afterward, assuming you have the basics of Kanban under your belt, I would recommend reading "Kanban Maturity Model" by David J. Anderson and Teodora Bozheva. It goes into great detail on specific Kanban practices, but it's hard to recommend this book unless you already have a good grasp of the basic concepts.
Have a max of Work In progress that can be in the DOING lane based on size of team. Once that limit is hit, nothing else can move into the DOING lane, if other's are finished, they go help others until work starts moving into the DONE lane.
DONE means DONE, if it needs QA, Documentation, install script, whatever, it stays in DOING until it's truly DONE.