Joel claims that Trello can be used for kanban. This is not true because Trello doesn't support WIP (Work-In-Progress) limits without which you don't have kanban.
If you want to know your team's capacity, you have to limit the number of tasks they work on at the same time. Once you limit WIP, several interesting things will happen:
* A backlog of tasks will emerge.
* You will be able to measure how much time is spent on each task.
* Tasks will get finished faster.
The first two results are not very surprising because by introducing WIP limits, you have effectively eliminated multitasking, but how on earth, do tasks get finished faster?
Unlike computers with multiple processor cores, our brains have one or at best two cores. Without WIP limits, when there are too many tasks to work on, we spend more time on switching tasks than the tasks themselves.
Bottlenecks become visible. Since everyone is working on a limited number of tasks, some finish theirs on time, some get overloaded, and some cannot finish their work because they need input from those who are overloaded. Team members with free capacity can help those who are overloaded. Better yet, they can even come up with ideas on how to fix the newly discovered bottlenecks.
Disclaimer: I am the author of http://flow.io , a lean project management application based on kanban.
> Trello doesn't support WIP (Work-In-Progress) limits
To be fair, bulletin boards with index cards don't have WIP limits either.
It is unlikely a system light enough for frictionless kanban will have an accurate understanding of the work-width (units of work / units of time) of a given task. For example, in your tour, "58% complete" of "Custom CSS for homepage" is suspiciously precise.
Saying kanban is a task board with WIP limits is a bit like saying Lean Startup is about releasing buggy first version MVPs. It's cargo culting at best. Kanban is about keeping focus, creating quality gates, pull vs. push and so much more than just WIP limits. You can always limit WIP manually. How hard is it to simply choose to limit the WIP on a board column?
Your comment doesn't respond to what he said. He said that without WIP limits, you don't have kanban, while you responded to a statement that kanban is only task boards plus WIP.
The two are not equivalent. It is as if I said that without polite discourse you don't have a productive debate, and someone else called me an idiot for claiming that good manners and threaded comments are all HN needs.
Automagic WIP limits may not be necessary for imlementing kanban, but that's a deign debate, not a what-is-kanban debate. You may have a good point about whether WIP limits are necessary for a good "implementing kanban" application.
I disagree. I think WIP really needs to be a built in concept of a kanban app. The thing about WIP is it points out bottle necks and problems in your process quickly and concisely. It's pretty common for teams to go over WIP, and do it willingly, to allow the red flag the system produces to point out to the rest of the team the problem.
If you have to mentally keep track of WIP, inside each team member's head, you lose pretty much all of that.
Rigid rules means you can't adapt to reality. Adapting to reality is necessary for good software development.
Sometimes you just can't let something else wait until you are done with what you were doing. Sometimes you were doing something that can't meaningfully progress until something else has been fixed. Rigid computer enforced rules like that just mean that people will have to work around them, wasting energy and producing the wrong things.
WIP limits shouldn't be rigidly enforced. Instead a warning should show when you are over WIP, and some stats gathered in the background. If your team goes over WIP occasionally, it's usually fine. If you go over WIP a lot, your process is broken somehow. How, when, who and where you went over WIP can give you a lot of info on where your bottlenecks are and how to improve your process.
I've been on a Kanban team for the past year now and I can say with confidence that if our tool didn't track WIP, we would be less effective as a team.
I like trello specifically because I can create a list called 'Work in Progress (MAX 5 ITEMS)' and it will more or less do what you've described, without forcing process on you. Not sure how well this scales to big teams I'll admit.
I have downvoted you, on principle, because you advocated a religious method of software development and that you preach some psycobable to make it seem right.
Software development needs to be flexible because each problem is unique and different from all the others in important aspects.
Kanban is a tool on a long, long, long list of tools which software developers should learn to use, modify adapt and improve to become better programmers. Trello is one item on that list. And yes, it can be used for Kanban, if the team wants to -- just like you could use an actual whiteboard.
If you want to know your team's capacity, you have to limit the number of tasks they work on at the same time. Once you limit WIP, several interesting things will happen:
* A backlog of tasks will emerge.
* You will be able to measure how much time is spent on each task.
* Tasks will get finished faster.
The first two results are not very surprising because by introducing WIP limits, you have effectively eliminated multitasking, but how on earth, do tasks get finished faster?
Unlike computers with multiple processor cores, our brains have one or at best two cores. Without WIP limits, when there are too many tasks to work on, we spend more time on switching tasks than the tasks themselves.
Bottlenecks become visible. Since everyone is working on a limited number of tasks, some finish theirs on time, some get overloaded, and some cannot finish their work because they need input from those who are overloaded. Team members with free capacity can help those who are overloaded. Better yet, they can even come up with ideas on how to fix the newly discovered bottlenecks.
Disclaimer: I am the author of http://flow.io , a lean project management application based on kanban.