I struggled for years with the kanban structures at tech companies. There's a basic problem: the unit of the board is not of fixed size. If it's a doable task, then where to the projects and ends that it's part of get tracked? If it's projects and ends, then where is my actual todo list? And then you realize that some projects have lots of subparts and some have three actions to be done.
I've also been running a Getting Things Done system for a couple decades as well, and I've basically gone back to a hierarchical todo list that I work down.
The funny thing is that actual kanban in industrial settings doesn't work this way at all. It was completely misunderstood when brought over to software. In manufacturing, you have a series of work stations with different machines. You want to optimize for producing the right things in the shortest amount of time (which is not the same as optimizing keeping all the work stations busy). So if you need a finished product X, you write out a card for X and hand it to the last workstation to produce X...if they don't have too many cards already (to limit work in progress). They write a kanban card for each upstream step and pass them to the upstream stations, who keep going back until you get a kanban card for parts or raw materials to be ordered or fetched from storage. Then the cards are attached to the output of each stage as it moves back down. Since each stage can only take a certain number of cards, you intrinsically limit the amount of unfinished inventory.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.