Who prioritizes? On a large team, most tasks require at least some collaboration and discussion. Kanban seems very chaotic for a large team, with priorities constantly shifting. With sprints, everyone on the team is in agreement about the priorities for the next N weeks, and you regroup at the end to iterate.
As a manager, how do I know how long a Kanban task should take? How do I know how long it's been in-progress, or how much is left? (With sprints, the idea is that every task should be defined as completable within N weeks. So it's pretty simple to estimate when deliverables will be done.)
Business is very chaotic. Admittedly, we (where I work) are a very bare-bones team, so we are quicker on our feet than a larger organization.
The main issue we would run into with "sprints" was that the business world-view didn't stay fixed for 2 weeks at a time. There was always something that came up and got bumped in priority. This led to people feeling disappointed that "we blew the sprint".
In reality, "the sprint" doesn't matter. Solving business problems matters. Kanban (Wikipedia says it's just japanese for "billboard" i.e. "big priority board") is just a way of explicitly stating the current priorities so that you can react to them.
> As a manager, how do I know how long a task should take?
You still break down big tasks into small tasks and estimate them. The planning process isn't really any different than with sprints, it's just that you're more free to make trade-offs in real time.
Isn't the idea of the sprint there to protect developers from having the priorities shift under their feet every two minutes? It's easier to get work done if you know you can focus on a task for a few weeks and not be forced to context-switch suddenly.
Under Kanban the way that is protected is by enforcing "don't start something new until your current task is finished."
Obviously life is messy and it doesn't always work out that way, but it tends to be closer to reasonable if you break the size of the tasks down enough. I can reasonably anticipate what I will be doing on a given day. Possibly even the next couple days. I have a good idea what I'll be doing in a week, but any number of things could happen before then.
Another thing to keep in mind is that the changes I'm talking about are "course correction" type changes. I.e. "We have projects X, Y, Z ongoing. Z has suddenly become more important, so we're going to bump it's priority." This is vastly different from a business that is managed incompetently where one day we are trying to sell milkshakes and the next we're in the tuxedo business.
It reminds me of a comment I heard regarding earthquake safe buildings: "They are scarier because everything moves more. But since they move more, they don't fall over"
As a manager, how do I know how long a Kanban task should take? How do I know how long it's been in-progress, or how much is left? (With sprints, the idea is that every task should be defined as completable within N weeks. So it's pretty simple to estimate when deliverables will be done.)