The fundamental idea behind Kanban was WIP Constraint Management.

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.

▲

okovooo 3 hours ago | parent [-]

"WIP" does not work - it only seems that you are in control of the process. It may work for the same type of tasks (hammering a nail), but in my practice, where all tasks are different, it did not work anywhere.

▲

TipsForCanoes 13 minutes ago | parent | next [-]

> "WIP" does not work

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

▲

wpietri an hour ago | parent | prev [-]

It has worked fine for me on a variety of software projects for more than 20 years. Here's a project I documented back in 2004, where we used physical cards: https://williampietri.com/writing/2004/teamroom/

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.

	▲	okovooo 24 minutes ago \| parent [-]
		I understand what you mean, but I think this is a self-deception of control. After thinking about it, I implemented WIP on the process (board), but only in the form of an "excess indicator".