10 ms·

Is “doing Kanban” just having tasks on a board without any sort of sprint structure? I feel like it’s a bit of a false equivalence. While I won’t ever defend al

Is “doing Kanban” just having tasks on a board without any sort of sprint structure? I feel like it’s a bit of a false equivalence. While I won’t ever defend all the cruft that comes with Scrum, the article seems like a bit of a straw man.

TobyTheDog123 3y ago
I also don't fully understand what "doing Kanban" means - like you, I see Kanban as a type of board rather than a method of going through said board (maybe because of a lack of understanding of process & an over-indulgence in Trello's marketing). That being said, I would say that having a Kanban board without any sprint structure (or any attached micromeetings) would skyrocket my productivity. The two-week sprint thing is meaningless to me - in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint, it's an utterly meaningless distinction.
- baby 3y ago
  Kanban is about organizing the work to be done and periodically revisiting the board to understand the work done and what’s next (which involves reprioritizing, pivoting, etc.) Some people might debate on how active a kanban board should be.
  - beoberha 3y ago
    This goes back to my original post. Is this “doing Kanban” or is this just another process using a Kanban board?
  - IshKebab 3y ago
    That sounds identical to how companies I've worked for "do agile". A kanban board. Every two weeks you revisit the board, see what got done, prioritise what to do next (usually by dragging it from the "backlog" to "todo" column).
    - baby 3y ago
      Could be much worse in practice. You could have retrospects every two weeks, daily standups, messages every day from your nontechnical manager asking you for estimate markers on each of the tasks, breaking down tasks further, renaming tasks they don’t understand but other engineers do, etc.
- beoberha 3y ago
  I’ve fortunately never had to do Scrum other than an internship where I had no idea what was actually going on. We do almost exactly what you describe. We just take tasks off the board and we don’t have sprints.
- OJFord 3y ago
  This is exactly how I feel. Then we talk about 'complexity points', explicitly not time, but then say only X of them fit into a two week fixed time window. So then overflow them (or pull new work in) as required as you say anyway, it's pointless? Whatever the management benefit supposedly is, seems like it could be achieved with declaring current (not 'sprint'^) goals, and a filter for tickets done/progressed in a given date range? (^Even the language is depressing: sprint, ticket, points, standup, sit down, keep moving, ...)
- theshrike79 3y ago
  > in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint That's not Scrum then. You don't add stuff mid-sprint, that's the whole point. Unless the world is literally on fire, you don't touch the sprint content. What's your scrum master doing when you get stuff added? It's their job to prevent it. And if work overflows, you need to spend time grooming the tasks to manageable chunks and adjust the team velocity. You can always pick up more tasks if you run out of stuff to do.
  - ResearchCode 3y ago
    Why do you need a "scrum master" to prevent that? Linux kernel seems to be doing just fine without them. The real solution is of course not to have any "sprints" at all. A manageable chunk of work is a 3 to 6 month project. Non-tech enterprise treat software engineers as children and create bad software. FAANG and adjacent companies treat software engineers more as professionals and create better software.
    - theshrike79 3y ago
      Linux kernel is more like Kanban than an Agile project, you can't really compare it to a project with an actual client who pays money to receive features in a timeframe. Stuff gets done when it's done and the BFDLs decide when the feature gets into the actual kernel. Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing requirements or not what the customer wanted because there is no way to change course after the project specification was locked. ...or you spend so much time doing an exact specification that the Agile team has already delivered 3 incremental versions.
      - ResearchCode 3y ago
        I don't see what use a "scrum master" is. That sounds like a small task for the software engineer or their real manager. There is nothing showing that heavy agile actually leads to features being developed earlier. In my experience it's the opposite as you build up heavy tech debt by micro-managing and optimizing for a 2 week return instead of the long term. Waterfall were 1 to 2 year projects with heavy up-front administration. 3 to 6 months is well-balanced and that's what the "elite" companies and research groups tend to use. Two weeks is the current fad at non-tech enterprise.
- liveoneggs 3y ago
  That's the whole trick with "doing Kanban". You don't need special magic methods to do your work- just pick up a ticket and do the work, repeat forever.
dgdosen 3y ago
They're prioritized tasks. They're pulled through. Simplicity is the structure.
- beoberha 3y ago
  I get that, that’s what I do with my team, but I’ve never heard that referred to as “doing Kanban”. Maybe I’m just being pedantic, but writing an article to say “you don’t need Scrum, just pull tasks off the board” completely misses the point of why teams use Scrum.
  - dgdosen 3y ago
    They're also visualized (on a kanban board) - are you doing that? Make work visible.
    - beoberha 3y ago
      For us, visibility isn’t an issue. I would say estimations are by far the biggest struggle we have in “doing Kanban”. Luckily, they’re not super important for us and I usually bubble up a very rough estimate in monthly reports to management, but in an org where they matter more, I can absolutely see why Scrum gets adopted the way it does.
      - dgdosen 3y ago
        Why do you estimate when using a kanban? You might look at an item and break it down for simplicity. You also might go in with a goal of 'one card per member per day' or something similar. But nothing should be fixed to an estimate. If something is delayed, it should show up stuck in a lane. Respond as needed.
        JakeAl 3y ago
        Because work is deadline driven by whoever is paying the teams' salaries. If you can't accurately estimate when you can get it done, you break it down until you can you get replaced by someone who can.
brezelgoring 3y ago
If you're doing reactive work, an oversimplified explanation of Kanban is to just put pending jobs on the board sorted by priority and that's about it. Doing proactive work means you can choose what goes on the board and that's where the nuance could happen. In my previous job we used it and I liked it, but I haven't used Scrum before so I can't comment as to how effective it could be.
rgoulter 3y ago
"kanban" is all about maximizing flow of completed tasks, and minimizing/limiting work in progress. Someone is either working on a task, or idle. A task is either being worked on (making progress), or it's not being worked on. -- A task will get completed quicker if you can minimize the amount of time it's "in progress" but not being worked on. If you have 5 workers and 15 tasks in progress, 10 of those tasks won't be making progress. Often, a task may be blocked by requiring some action from someone else. (e.g. PR review, or more resources, or blocked on some other task). The 'kanban board' is about visualizing work in progress. -- By visualising the work in progress, it's easier to identify bottlenecks & inefficiencies.
- woolion 3y ago
  So if I follow well, the interest is in having all different types of 'blocking stages' in the pipeline so that you can identify the points that slow down your process. With the right tool, and provided the tasks are accurately tracked, you get good statistics pointing to where you should optimize the workflow. However, it's not so simple to read. In some cases tasks were blocked because of a superficial or nonexistent analysis, which required to get more information. Which is a clear break of the flow, since it has to be paused for the time before the meeting can happen. But sometimes, the analysis can be fairly bad and very time-consuming on the other department, making the broken flow more efficient than the flowy one if you account for the whole team and not only developer time. Which seems to me that it's a good idea to optimize for flow only after you have enough consistency in the process, but still a powerful tool.
seanhunter 3y ago
Kanban means constrained capacity. You decide on an upper bound on how many things are allowed to be in progress at any one time and if you need to start work on something new you finish things that are in flight to provide headroom to do that. The board is just a device to ensure good communication so everyone in the team has shared state.
przemo_li 3y ago
I think you where sold on "scrum is all you need"lie. Kanban isn't there to dictate process, but as a tool to correctly and truthfully inspect your process. E.g. we recently used length of UAT column to prove that we need more business people doing testing in next few weeks as we close to feature release and more tests take form of exploratory testing. Scrum isn't blind to benefits of such inspections either! So doing simplified Kanban board is frequent.

TobyTheDog123 3y ago

I also don't fully understand what "doing Kanban" means - like you, I see Kanban as a type of board rather than a method of going through said board (maybe because of a lack of understanding of process & an over-indulgence in Trello's marketing). That being said, I would say that having a Kanban board without any sprint structure (or any attached micromeetings) would skyrocket my productivity. The two-week sprint thing is meaningless to me - in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint, it's an utterly meaningless distinction.

baby 3y ago
Kanban is about organizing the work to be done and periodically revisiting the board to understand the work done and what’s next (which involves reprioritizing, pivoting, etc.) Some people might debate on how active a kanban board should be.
- beoberha 3y ago
  This goes back to my original post. Is this “doing Kanban” or is this just another process using a Kanban board?
- IshKebab 3y ago
  That sounds identical to how companies I've worked for "do agile". A kanban board. Every two weeks you revisit the board, see what got done, prioritise what to do next (usually by dragging it from the "backlog" to "todo" column).
  - baby 3y ago
    Could be much worse in practice. You could have retrospects every two weeks, daily standups, messages every day from your nontechnical manager asking you for estimate markers on each of the tasks, breaking down tasks further, renaming tasks they don’t understand but other engineers do, etc.
beoberha 3y ago
I’ve fortunately never had to do Scrum other than an internship where I had no idea what was actually going on. We do almost exactly what you describe. We just take tasks off the board and we don’t have sprints.
OJFord 3y ago
This is exactly how I feel. Then we talk about 'complexity points', explicitly not time, but then say only X of them fit into a two week fixed time window. So then overflow them (or pull new work in) as required as you say anyway, it's pointless? Whatever the management benefit supposedly is, seems like it could be achieved with declaring current (not 'sprint'^) goals, and a filter for tickets done/progressed in a given date range? (^Even the language is depressing: sprint, ticket, points, standup, sit down, keep moving, ...)
theshrike79 3y ago
> in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint That's not Scrum then. You don't add stuff mid-sprint, that's the whole point. Unless the world is literally on fire, you don't touch the sprint content. What's your scrum master doing when you get stuff added? It's their job to prevent it. And if work overflows, you need to spend time grooming the tasks to manageable chunks and adjust the team velocity. You can always pick up more tasks if you run out of stuff to do.
- ResearchCode 3y ago
  Why do you need a "scrum master" to prevent that? Linux kernel seems to be doing just fine without them. The real solution is of course not to have any "sprints" at all. A manageable chunk of work is a 3 to 6 month project. Non-tech enterprise treat software engineers as children and create bad software. FAANG and adjacent companies treat software engineers more as professionals and create better software.
  - theshrike79 3y ago
    Linux kernel is more like Kanban than an Agile project, you can't really compare it to a project with an actual client who pays money to receive features in a timeframe. Stuff gets done when it's done and the BFDLs decide when the feature gets into the actual kernel. Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing requirements or not what the customer wanted because there is no way to change course after the project specification was locked. ...or you spend so much time doing an exact specification that the Agile team has already delivered 3 incremental versions.
    - ResearchCode 3y ago
      I don't see what use a "scrum master" is. That sounds like a small task for the software engineer or their real manager. There is nothing showing that heavy agile actually leads to features being developed earlier. In my experience it's the opposite as you build up heavy tech debt by micro-managing and optimizing for a 2 week return instead of the long term. Waterfall were 1 to 2 year projects with heavy up-front administration. 3 to 6 months is well-balanced and that's what the "elite" companies and research groups tend to use. Two weeks is the current fad at non-tech enterprise.
liveoneggs 3y ago
That's the whole trick with "doing Kanban". You don't need special magic methods to do your work- just pick up a ticket and do the work, repeat forever.

dgdosen 3y ago

They're prioritized tasks. They're pulled through. Simplicity is the structure.

beoberha 3y ago
I get that, that’s what I do with my team, but I’ve never heard that referred to as “doing Kanban”. Maybe I’m just being pedantic, but writing an article to say “you don’t need Scrum, just pull tasks off the board” completely misses the point of why teams use Scrum.
- dgdosen 3y ago
  They're also visualized (on a kanban board) - are you doing that? Make work visible.
  - beoberha 3y ago
    For us, visibility isn’t an issue. I would say estimations are by far the biggest struggle we have in “doing Kanban”. Luckily, they’re not super important for us and I usually bubble up a very rough estimate in monthly reports to management, but in an org where they matter more, I can absolutely see why Scrum gets adopted the way it does.
    - dgdosen 3y ago
      Why do you estimate when using a kanban? You might look at an item and break it down for simplicity. You also might go in with a goal of 'one card per member per day' or something similar. But nothing should be fixed to an estimate. If something is delayed, it should show up stuck in a lane. Respond as needed.
      - JakeAl 3y ago
        Because work is deadline driven by whoever is paying the teams' salaries. If you can't accurately estimate when you can get it done, you break it down until you can you get replaced by someone who can.

brezelgoring 3y ago

If you're doing reactive work, an oversimplified explanation of Kanban is to just put pending jobs on the board sorted by priority and that's about it. Doing proactive work means you can choose what goes on the board and that's where the nuance could happen. In my previous job we used it and I liked it, but I haven't used Scrum before so I can't comment as to how effective it could be.

rgoulter 3y ago

"kanban" is all about maximizing flow of completed tasks, and minimizing/limiting work in progress. Someone is either working on a task, or idle. A task is either being worked on (making progress), or it's not being worked on. -- A task will get completed quicker if you can minimize the amount of time it's "in progress" but not being worked on. If you have 5 workers and 15 tasks in progress, 10 of those tasks won't be making progress. Often, a task may be blocked by requiring some action from someone else. (e.g. PR review, or more resources, or blocked on some other task). The 'kanban board' is about visualizing work in progress. -- By visualising the work in progress, it's easier to identify bottlenecks & inefficiencies.

woolion 3y ago
So if I follow well, the interest is in having all different types of 'blocking stages' in the pipeline so that you can identify the points that slow down your process. With the right tool, and provided the tasks are accurately tracked, you get good statistics pointing to where you should optimize the workflow. However, it's not so simple to read. In some cases tasks were blocked because of a superficial or nonexistent analysis, which required to get more information. Which is a clear break of the flow, since it has to be paused for the time before the meeting can happen. But sometimes, the analysis can be fairly bad and very time-consuming on the other department, making the broken flow more efficient than the flowy one if you account for the whole team and not only developer time. Which seems to me that it's a good idea to optimize for flow only after you have enough consistency in the process, but still a powerful tool.

seanhunter 3y ago

Kanban means constrained capacity. You decide on an upper bound on how many things are allowed to be in progress at any one time and if you need to start work on something new you finish things that are in flight to provide headroom to do that. The board is just a device to ensure good communication so everyone in the team has shared state.

przemo_li 3y ago

I think you where sold on "scrum is all you need"lie. Kanban isn't there to dictate process, but as a tool to correctly and truthfully inspect your process. E.g. we recently used length of UAT column to prove that we need more business people doing testing in next few weeks as we close to feature release and more tests take form of exploratory testing. Scrum isn't blind to benefits of such inspections either! So doing simplified Kanban board is frequent.