Ask HN: Recommended Kanban books I’m interested i learning about Kanban. I know agile and Scrum. Which books about Kanban do you recommend? |
Ask HN: Recommended Kanban books I’m interested i learning about Kanban. I know agile and Scrum. Which books about Kanban do you recommend? |
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.
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
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.
https://www.infoq.com/lean?utm_source=infoq&utm_medium=heade...
I personally recommend free e-book:
"Kanban and Scrum - Making the Most of Both" by Mattias Skarin , Henrik Kniberg:
https://www.infoq.com/minibooks/kanban-scrum-minibook?utm_so...
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).