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).
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).