4 ms·

There is always a list of things to be done and it's usually prioritized and often the highest priority item is what you do next. This isn't unique to software

There is always a list of things to be done and it's usually prioritized and often the highest priority item is what you do next. This isn't unique to software. It isn't even unique to white-collar jobs. Why does that even need a name?

ehvatum 7y ago
I gotta put something on my resume, thank you.
ramraj07 7y ago
Kanban was literally coined in Toyota so it's not a software specific thing
allannienhuis 7y ago
the main innovation of Kanban is to limit the number of items being worked on (in a specific category) at one time. For example - You can't pick up new work if testing is behind - go help the testers (somehow) instead.
- AstralStorm 7y ago
  You think that it is how it's supposed to work, but that's not really how it works. When a bottleneck presents itself everyone gets to work around it as it is not fixable by them! (Or the fixes are deemed either or of scope out to time consuming, so you're directly even prevented trying at it.) Generally you cannot fix things you do not have control over. Kanban is meant to have a process person fix the bad bottlenecks - not the developers, not the managers - and said person is supposed to have the clout to pull it off. I've never seen Kanban implemented properly. As for the example - if testers are not keeping up, either you hire more or enhance testing methodology. Throwing developers at it slows down development moving the bottleneck. (Of course, throwing some developers to provide better testing methodology, testable components or automation would be a proper fix.)
  - allannienhuis 7y ago
    well, any type of process will fail in a dysfunctional organization :). And you can't (well, shouldn't) arbitrarily implement a specific process without thinking through the fit for your organization. Just buying a license to a Kanban tool isn't enough :). The example you gave is a good one - devs spend their time making improvements to to code or the test automation to make the testing more effective, if testing is the bottleneck to delivering finished features. Throwing more code/features over the wall when that code isn't actually being tested isn't real progress. In principle, the manager/lead would tweak guidance until the most expensive resource (dev engineers) are the actual bottleneck. I guess of course teams/companies that care less about quality might just tell the testers to test less thoroughly in order to get their work items through the system faster, but at least it's a conscious decision. I've worked for teams where they literally close every testing ticket once the code is pushed to production regardless whether the testing has been done. 'tested in production' - that's one way to keep up I guess...
    - AstralStorm 7y ago
      It's a great way to have an unfixable mountain of tech debt. See, Kanban only works when the focus is on quality. It's the main secondary premise of the original Toyota approach of Lean which spawned Kanban. Note that it starts with minimizing waste (in programming, tree breakage or waiting on tests) and secondly minimizing overloads. The philosophy is kaizen, continuous improvement. Sacrificing quality is not an improvement, Toyota itself started by breaking process into quality assured steps to fight waste due to rework. Otherwise anyone can push undone paper tickets over the wall and that's not the point.
sixstringtheory 7y ago
It came from Toyota manufacturing, so right off the bat software is a borrower of the idea. I love Kanban, it's all about minimizing work in flight, to allow you to focus on the task at hand until it's Done instead of hurrying to meet the sprint deadline.
haolez 7y ago
Kanban goes a little further in my own experience. Here are some things I’ve seen in the wild: - make sure that developers have some slack time, so that they can cater to their tools and study new things - never move back an item to a previous column. If something more important came up, you “cancel” the current task and start the new one. This helps to identify bottlenecks
- ChristianBundy 7y ago
  > never move back an item to a previous column. If something more important came up, you “cancel” the current task and start the new one. This helps to identify bottlenecks Could you explain this a bit further? I'm imagining three columns, todo / doing / done, and I'm working on a widget when I'm asked to put out a fire. I'd imagine that the fire is moved from todo to doing and that the widget work is moved from doing to todo, but it sounds like you're advocating for something different. Could you explain more about it or link to resources that might help me understand? Thanks!
  - haolez 7y ago
    You need a mechanism to keep track of your unpredicted interruptions, so that you can improve your process continuously (which is what Kanban is about). Moving items back makes this harder (although possible). What I saw some teams doing was to mark such items as cancelled, explaining in the tickets why they got cancelled, so that a manager can then see which columns (i.e. steps of a process) are interrupted more often. This could point to a bottleneck in this process. In the near future, the "rest" of the cancelled ticket would make it back into the backlog as a new ticket entirely. This has the added benefit of keeping your backlog cleaner.
    - nefitty 7y ago
      I will try this today with my own personal kanban board. I do find myself with cards moving back and forth a lot. The way I've dealt with "Cancellations" is I have a list called "Waiting" where I stick tasks that are blocked. Sort of like pending review but it could also involve waiting for a resource, a response, etc. I think if I implement cancellations with details it could help me figure out what processes are broken that caused fires(i.e. this report is suddenly due, overriding everything else. Did I miss a memo? Do we have a solid process for anticipating these sorts of reports in the future? etc.) I could then go back during some planning time to view what needs some brain time. Thanks for suggesting this!
naravara 7y ago
>This isn't unique to software. It isn't even unique to white-collar jobs. Why does that even need a name? Kanban originates in Toyota's factory line. The key thing isn't the existence of the list, it's in making people responsible for maintaining and tracking the list rather than consolidating the authority in foremen who direct minions on what to do next. This makes it possible for teams to set priorities collaboratively and move between roles fluidly. It also establishes a clear order in which things need to be done and an agreed upon subdivision of tasks that make it possible to track the status of work.
TheAdamAndChe 7y ago
Giving it a name allows for the process to be codified and differentiates it from other processes.
ratww 7y ago
IMO the two main points of Kanban (and Agile in general) is limit the size of activities and make the backlog visible. The goal is to empower the team to quickly change priorities. Of course, It's possible to do that without Kanban, but it requires a lot of management skill, and workers hate changing priorities mid-work. And Kanban/Agile also doesn't assure that it will happen.

ehvatum 7y ago

I gotta put something on my resume, thank you.

ramraj07 7y ago

Kanban was literally coined in Toyota so it's not a software specific thing

allannienhuis 7y ago

the main innovation of Kanban is to limit the number of items being worked on (in a specific category) at one time. For example - You can't pick up new work if testing is behind - go help the testers (somehow) instead.

AstralStorm 7y ago
You think that it is how it's supposed to work, but that's not really how it works. When a bottleneck presents itself everyone gets to work around it as it is not fixable by them! (Or the fixes are deemed either or of scope out to time consuming, so you're directly even prevented trying at it.) Generally you cannot fix things you do not have control over. Kanban is meant to have a process person fix the bad bottlenecks - not the developers, not the managers - and said person is supposed to have the clout to pull it off. I've never seen Kanban implemented properly. As for the example - if testers are not keeping up, either you hire more or enhance testing methodology. Throwing developers at it slows down development moving the bottleneck. (Of course, throwing some developers to provide better testing methodology, testable components or automation would be a proper fix.)
- allannienhuis 7y ago
  well, any type of process will fail in a dysfunctional organization :). And you can't (well, shouldn't) arbitrarily implement a specific process without thinking through the fit for your organization. Just buying a license to a Kanban tool isn't enough :). The example you gave is a good one - devs spend their time making improvements to to code or the test automation to make the testing more effective, if testing is the bottleneck to delivering finished features. Throwing more code/features over the wall when that code isn't actually being tested isn't real progress. In principle, the manager/lead would tweak guidance until the most expensive resource (dev engineers) are the actual bottleneck. I guess of course teams/companies that care less about quality might just tell the testers to test less thoroughly in order to get their work items through the system faster, but at least it's a conscious decision. I've worked for teams where they literally close every testing ticket once the code is pushed to production regardless whether the testing has been done. 'tested in production' - that's one way to keep up I guess...
  - AstralStorm 7y ago
    It's a great way to have an unfixable mountain of tech debt. See, Kanban only works when the focus is on quality. It's the main secondary premise of the original Toyota approach of Lean which spawned Kanban. Note that it starts with minimizing waste (in programming, tree breakage or waiting on tests) and secondly minimizing overloads. The philosophy is kaizen, continuous improvement. Sacrificing quality is not an improvement, Toyota itself started by breaking process into quality assured steps to fight waste due to rework. Otherwise anyone can push undone paper tickets over the wall and that's not the point.

sixstringtheory 7y ago

It came from Toyota manufacturing, so right off the bat software is a borrower of the idea. I love Kanban, it's all about minimizing work in flight, to allow you to focus on the task at hand until it's Done instead of hurrying to meet the sprint deadline.

haolez 7y ago

Kanban goes a little further in my own experience. Here are some things I’ve seen in the wild: - make sure that developers have some slack time, so that they can cater to their tools and study new things - never move back an item to a previous column. If something more important came up, you “cancel” the current task and start the new one. This helps to identify bottlenecks

ChristianBundy 7y ago
> never move back an item to a previous column. If something more important came up, you “cancel” the current task and start the new one. This helps to identify bottlenecks Could you explain this a bit further? I'm imagining three columns, todo / doing / done, and I'm working on a widget when I'm asked to put out a fire. I'd imagine that the fire is moved from todo to doing and that the widget work is moved from doing to todo, but it sounds like you're advocating for something different. Could you explain more about it or link to resources that might help me understand? Thanks!
- haolez 7y ago
  You need a mechanism to keep track of your unpredicted interruptions, so that you can improve your process continuously (which is what Kanban is about). Moving items back makes this harder (although possible). What I saw some teams doing was to mark such items as cancelled, explaining in the tickets why they got cancelled, so that a manager can then see which columns (i.e. steps of a process) are interrupted more often. This could point to a bottleneck in this process. In the near future, the "rest" of the cancelled ticket would make it back into the backlog as a new ticket entirely. This has the added benefit of keeping your backlog cleaner.
  - nefitty 7y ago
    I will try this today with my own personal kanban board. I do find myself with cards moving back and forth a lot. The way I've dealt with "Cancellations" is I have a list called "Waiting" where I stick tasks that are blocked. Sort of like pending review but it could also involve waiting for a resource, a response, etc. I think if I implement cancellations with details it could help me figure out what processes are broken that caused fires(i.e. this report is suddenly due, overriding everything else. Did I miss a memo? Do we have a solid process for anticipating these sorts of reports in the future? etc.) I could then go back during some planning time to view what needs some brain time. Thanks for suggesting this!

naravara 7y ago

>This isn't unique to software. It isn't even unique to white-collar jobs. Why does that even need a name? Kanban originates in Toyota's factory line. The key thing isn't the existence of the list, it's in making people responsible for maintaining and tracking the list rather than consolidating the authority in foremen who direct minions on what to do next. This makes it possible for teams to set priorities collaboratively and move between roles fluidly. It also establishes a clear order in which things need to be done and an agreed upon subdivision of tasks that make it possible to track the status of work.

TheAdamAndChe 7y ago

Giving it a name allows for the process to be codified and differentiates it from other processes.

ratww 7y ago

IMO the two main points of Kanban (and Agile in general) is limit the size of activities and make the backlog visible. The goal is to empower the team to quickly change priorities. Of course, It's possible to do that without Kanban, but it requires a lot of management skill, and workers hate changing priorities mid-work. And Kanban/Agile also doesn't assure that it will happen.