#kanban tips (1/3)
Model the work, not the “workers”. With team member magnets, checklists, and markers...the bottom design can more than adequately model the work
If work ever “moves left” (e.g. QA/demo passes an item “back to dev”), then the top dsgn breaks. It is all doing.
Model the work, not the “workers”. With team member magnets, checklists, and markers...the bottom design can more than adequately model the work
If work ever “moves left” (e.g. QA/demo passes an item “back to dev”), then the top dsgn breaks. It is all doing.
Another classic anti-pattern is team/individual lanes and “splitting” the work. The bottom option will probably catalyze the right conversations....though the top option with string can also do the trick. (2/4) #kanban
A compromise if teams want their own card for some reason... is a hybrid board with “epics” (larger chunks of work), and all of their related cards.(3/4) #Kanban
Make use of the cards...a lot of what people bake into the board layout...can be put on the card (e.g. checkboxes for testing, demo, multiple assignees, task lists, etc.) (4/4) #Kanban
For @northerncodemky
If QA truly doesn’t start upstream (please let them :)), and there is a hard handoff to test, you might want to considering something like this.
At least this is calling the kettle black. My guess, though, is that testing is “working” on the items earlier
If QA truly doesn’t start upstream (please let them :)), and there is a hard handoff to test, you might want to considering something like this.
At least this is calling the kettle black. My guess, though, is that testing is “working” on the items earlier
