The best Kanban board is a physical one. You are also not going to be able to put 200 items on it.
That’s a feature, not a bug.
That’s a feature, not a bug.
One of the big benefits of a physical kanban board is that the limited space means people only write down the stuff they really care to keep track of. For me it has never resulted in people forgetting anything important. It means they don't write down the unimportant stuff.
It's possible that some people would write down a lot of trivia or fantasy features, especially to start. The best response to that is to let them write the cards and then sort them according to actual priorities. But I've never seen anybody persist in that behavior very long. If they do, I think it's a sign of organization problems that tools can at best mask, never fix.
I think this can also be true of virtual kanban boards (e.g., GitHub's kanban view) if you keep people focused on the kanban view. Then they learn to focus on what's being worked on and the near-term to-do list. You can have a backlog column and let people fill it up as much as they want, but as long as you groom the top 20 cards or so to be your actual current priorities, people eventually adapt.
There is no job where all work is equally important, where all ideas are equally good. Even in emergency rooms, where triage is a vital concept. I think it's ok if finding a new poster for the break room gets dropped because there's too much work treating patients right now.
Unfortunately, so many people have been doing cargo-cult agile for so long that now the word "kanban" means 'task board with columns' to most people.
It should not be possible to put 200 items into a column on a Kanban board unless the team is actually shown to have the capacity to work on them without causing a bottleneck.
These days I'm on an all-remote team, and we use GitHub's kanban interface with WIP limits. That also works fine, and them main difference form how I worked back then is that we no longer do estimates.
I'm not sure what went wrong for you, but my strong suggestion is not to think of it as a task board. Think of it as a board that lists units of value. E.g., features delivered, research completed, messes cleaned up. We do sometimes make task breakdowns for cards, but that happens as we start work on the card, and it's just a checklist somewhere (for us currently, in the GitHub issue via Markdown checklists).
An important mindset shift for a lot of teams to use kanban boards well is to get away from siloing and toward collaboration. For my teams, cards were generally not individual achievements, but things we collaborated on.
I think it's also important for software teams to have a BLOCKED column between TODO and WORKING. The only cards that should count against your WIP limit are the ones that people are truly working on that day. If there's something you can't work on for some external reason, move it to BLOCKED. Then before a card is taken from TODO, try getting any BLOCKED item going first. It's also worth talking in your retrospectives about common reasons things end up blocked, and I like to set a pretty low limit for blocked cards to force discussion.
Happy to discuss further, but kanban approaches definitely work well for software.
Such a bold statement when you must know that countless people have a very different experience. Kanban the team methodology is about process efficiency and avoiding bottlenecks.
WIP limits are triggers to redirect resources to the bottleneck is that causes the pileup. Example: If there is pileup of PRs needing review, that is the trigger for devs on the team to stop making new PRs and switch to doing reviews.
Kanban is certainly not the best methodology for all team tasks but where it fits it works very well.
Sadly, for a lot of teams "we are doing kanban" means nothing more than "we are using a task board with columns" or worse "we have no constraints or flow controls and do everything ad hoc."
I ask because in my experience the main 2 reasons are either a manager who doesn't understand the kanban methodology and uses it incorrectly or that it simply doesn't benefit the workload of the team trying to use it.
I don't know what that means in relation to the Kanban methodology.
What I'm looking for is something like, "my manager attempted to improve our cycle time by introducing limits on the number of tasks that can be in each state on our board. When a limit is exceeded, we are expected to take a predefined action to help clear the bottleneck that caused the pile up. It doesn't work and we still have bottlenecks and have not improved cycle time or efficiency."
If all your manager is doing is putting arbitrarily limits on WIP columns, that's unlikely to accomplish much and thats not Kanban. This kind of limit is only beneficial for the person who starts too many tasks without finishing them. The Kanban methodology is about team efficiency, not individual task limits.
edit: typos
If I understand it correctly it moves the signaling in-band so it can be handled at a locally distributed level, that is, each local parts consuming system is responsible for directly signaling it's upstream supplier to provide more parts and this is done by putting the signals on the parts bins or making the parts bins themself the signals.
I guess there is also that weird software logistics thing that appropriated the kanban term but because software logistics is very different from manufacturing logistics has little to do with actual kanban. shrugs. It's probably still a backpressure signaling thing however.