3 ms·

Add WIP limits to your columns. That means no cases can be added without other ones been completed first.

by UK-AL 10y ago

lmm 10y ago
That doesn't help. If you have n people you need to allow n tasks in progress. The problem is one person being on the same task for 6 months.
- UK-AL 10y ago
  Honestly I don't think that's an issue, if you lead developer is keeping on top of the kanban board, he will notice it and address it. Most Kanban boards allow you set to mark items if they go past a certain time. Manage by exception. If most cases just take a few days, set up some kind of system to mark the outlining cases out. Then you can investigate and address these exceptional cases if required.
  - lmm 10y ago
    > if you lead developer is keeping on top of the kanban board, he will notice it and address it. Do you have some extra process that makes this happen? I don't remember anything in the version of kanban I saw that implied the lead developer should be doing this. > Manage by exception. If most cases just take a few days, set up some kind of system to mark the outlining cases out. Then you can investigate and address these exceptional cases if required. In the project I'm thinking of it wasn't a single exception; rather the length of a typical task gradually crept up (from below 2 weeks at the point when we switched from scrum) until it was normal to have tasks lasting multiple months.
    - UK-AL 10y ago
      Then you leadership is not doing it right. Cases should take days at most, more then that they should be broken up. The whole point of Kanban is to have everything visible and known. If your not looking at the Kanban board and taking action based things that look wrong whats the point?
      - lmm 10y ago
        > Then you leadership is not doing it right. Cases should take days at most, more then that they should be broken up. It's easy - and useless - to make this about people. The point is, this is a problem that we didn't have under Scrum, with the same people. > The whole point of Kanban is to have everything visible and known. If your not looking at the Kanban board and taking action based things that look wrong whats the point? At what point does it look wrong? If the idea is to have everything visible why does Kanban generally include fewer stats than other processes? I was always told the "whole point" was limiting work in progress.
        UK-AL 10y ago
        It's a problem under scrum as well. Just because the sprint is ending doesn't mean the case will finish. They just get dragged into the next sprint
        lmm 10y ago
        That's not supposed to happen, and the process says that in that case you have to at the very least re-estimate. If a ticket is really taking forever, at some point the estimate for the time to finish it will be more than a sprint, at which point you're obliged to split it up.

Add WIP limits to your columns. That means no cases can be added without other ones been completed first.

by UK-AL 10y ago

Add WIP limits to your columns. That means no cases can be added without other ones been completed first.

lmm 10y ago

That doesn't help. If you have n people you need to allow n tasks in progress. The problem is one person being on the same task for 6 months.

UK-AL 10y ago
Honestly I don't think that's an issue, if you lead developer is keeping on top of the kanban board, he will notice it and address it. Most Kanban boards allow you set to mark items if they go past a certain time. Manage by exception. If most cases just take a few days, set up some kind of system to mark the outlining cases out. Then you can investigate and address these exceptional cases if required.
- lmm 10y ago
  > if you lead developer is keeping on top of the kanban board, he will notice it and address it. Do you have some extra process that makes this happen? I don't remember anything in the version of kanban I saw that implied the lead developer should be doing this. > Manage by exception. If most cases just take a few days, set up some kind of system to mark the outlining cases out. Then you can investigate and address these exceptional cases if required. In the project I'm thinking of it wasn't a single exception; rather the length of a typical task gradually crept up (from below 2 weeks at the point when we switched from scrum) until it was normal to have tasks lasting multiple months.
  - UK-AL 10y ago
    Then you leadership is not doing it right. Cases should take days at most, more then that they should be broken up. The whole point of Kanban is to have everything visible and known. If your not looking at the Kanban board and taking action based things that look wrong whats the point?
    - lmm 10y ago
      > Then you leadership is not doing it right. Cases should take days at most, more then that they should be broken up. It's easy - and useless - to make this about people. The point is, this is a problem that we didn't have under Scrum, with the same people. > The whole point of Kanban is to have everything visible and known. If your not looking at the Kanban board and taking action based things that look wrong whats the point? At what point does it look wrong? If the idea is to have everything visible why does Kanban generally include fewer stats than other processes? I was always told the "whole point" was limiting work in progress.
      - UK-AL 10y ago
        It's a problem under scrum as well. Just because the sprint is ending doesn't mean the case will finish. They just get dragged into the next sprint
        lmm 10y ago
        That's not supposed to happen, and the process says that in that case you have to at the very least re-estimate. If a ticket is really taking forever, at some point the estimate for the time to finish it will be more than a sprint, at which point you're obliged to split it up.