5 ms·

We moved to Kanban a few years ago and I think it's been much nicer than the "sprints" we used to do. There is a board. The board has a prioritized list of thi

We moved to Kanban a few years ago and I think it's been much nicer than the "sprints" we used to do. There is a board. The board has a prioritized list of things to do. You work on your thing until it is done. Then you pick your next task based on where the priorities currently sit. It's really not far off from the "sprint" idea. The main difference is it is a constant re-balancing rather than an every X weeks affair.

wvenable 7y ago
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.
swiley 7y ago
I feel like “constantly” is a nice way to say “never.” But I’ve personally never done kanban so maybe it doesn’t actually work that way.
- xmprt 7y ago
  At the end of the day all of this is just a tool to help track project progress. If you don't do it then you're only hurting your productivity.
  - swiley 7y ago
    Absolutely, and all I’m saying is unless I specifically set aside time to perform some task it’s probably not going to get done.
- war1025 7y ago
  Sometimes we go a very long time without doing any explicit planning. Things can tend to get a bit stale if we wait too long. What I meant by "constantly" was probably more "at any time". The truth is that we cannot commit to a list of priorities for two weeks. There will always be something that comes up and pulls someone off track. The different between Kanban and 2 week sprints is that, rather than viewing that as a failure, that is seen as responding to business priorities, which is a good thing.
ratww 7y ago
One of the advantages of moving to Kanban in my previous job was that people was that the code quality improved a lot because they were rushing at the end of sprints. Quality of life increased a lot, too.
mindcrime 7y ago
So here's the thing... "Sprints" are not specifically part of "Agile" at all! Look at the Agile Manifesto and see if the word "sprint" appears at all. (Hint: it does not). So anybody complaining about "sprints" isn't complaining about "Agile", they're complaining about one specific attempt to implement the principles of Agile. Likely that's Scrum, since "sprints" are mainly a Scrum notion. But Scrum is not the only way to do Agile, and it certainly may not be the best. And even within the world of Scrum, there's a lot of variance in terms of exactly how it's implemented.
human20190310 7y ago
Sprints to me seem completely contrived. In reality, there are only things that people are working on, and things that no one is working on. There's no need for a third category of "things that are in the sprint" as long as someone (anyone!) keeps the task queue sorted in priority order.
- pflenker 7y ago
  Sprints are less about categorizing the incoming work, but partitioning the outgoing work, to establish a quick feedback loop. This should in theory ensure that risks are tackled early.
  - human20190310 7y ago
    The outgoing product is nevertheless fully determined by the incoming work being done. It would make more sense to group a set of tasks into a deliverable than a time period. You have to do that anyway to deliver anything coherent.
    - pflenker 7y ago
      There are two arguments against grouping as a deliverable: 1) sprints are (supposed to be) predictable. So you know when to expect something and can plan other activities around that date. 2) (the more important reason IMHO) a sprint enforces early delivery, where features are rough and not very comfortable to use, but it’s already visible how it will look like. That means feedback can be collected and fueled into the next planning. The assumption is that it’s easier for people to talk about hidden assumptions when they interact with the software, than when they write specs
- all_usernames 7y ago
  Sprints are meant to be a tool to measure a team's velocity, defined as average amount of work throughput in X weeks. You don't know the average until a sprint team has worked together for several sprints on similar work. Sprints can work very well if you need to: A) Estimate the time it will take to complete a large project B) Compare productivity of different teams so you can shift or add people C) Get continual feedback on the work quality and the workflow process Over time, I've seen sprint teams become very accurate at estimating their work throughput ahead of time. This can be extremely valuable to the business delivering on its goals on time and committing to the right amount of deliverables.
all_usernames 7y ago
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.)
- war1025 7y ago
  > Who prioritizes? The same people that did before. > Kanban seems very chaotic 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.
  - ptx 7y ago
    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.
    - war1025 7y ago
      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"
harimau777 7y ago
Wow, I honestly didn't even know that had a name. I worked at a place that did this but I just thought of it as "the only time I've seen Agile actually work".
decoyworker 7y ago
Kanban seems pretty similar to a method I used in college to track tasks, not even software tasks. This leads me to believe that it is intuitive since it more or less naturally made sense to me before ever knowing Kanban was a thing. Going to look for this or something like it when job searching.

wvenable 7y ago

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.

swiley 7y ago

I feel like “constantly” is a nice way to say “never.” But I’ve personally never done kanban so maybe it doesn’t actually work that way.

xmprt 7y ago
At the end of the day all of this is just a tool to help track project progress. If you don't do it then you're only hurting your productivity.
- swiley 7y ago
  Absolutely, and all I’m saying is unless I specifically set aside time to perform some task it’s probably not going to get done.
war1025 7y ago
Sometimes we go a very long time without doing any explicit planning. Things can tend to get a bit stale if we wait too long. What I meant by "constantly" was probably more "at any time". The truth is that we cannot commit to a list of priorities for two weeks. There will always be something that comes up and pulls someone off track. The different between Kanban and 2 week sprints is that, rather than viewing that as a failure, that is seen as responding to business priorities, which is a good thing.

ratww 7y ago

One of the advantages of moving to Kanban in my previous job was that people was that the code quality improved a lot because they were rushing at the end of sprints. Quality of life increased a lot, too.

mindcrime 7y ago

So here's the thing... "Sprints" are not specifically part of "Agile" at all! Look at the Agile Manifesto and see if the word "sprint" appears at all. (Hint: it does not). So anybody complaining about "sprints" isn't complaining about "Agile", they're complaining about one specific attempt to implement the principles of Agile. Likely that's Scrum, since "sprints" are mainly a Scrum notion. But Scrum is not the only way to do Agile, and it certainly may not be the best. And even within the world of Scrum, there's a lot of variance in terms of exactly how it's implemented.

human20190310 7y ago

Sprints to me seem completely contrived. In reality, there are only things that people are working on, and things that no one is working on. There's no need for a third category of "things that are in the sprint" as long as someone (anyone!) keeps the task queue sorted in priority order.

pflenker 7y ago
Sprints are less about categorizing the incoming work, but partitioning the outgoing work, to establish a quick feedback loop. This should in theory ensure that risks are tackled early.
- human20190310 7y ago
  The outgoing product is nevertheless fully determined by the incoming work being done. It would make more sense to group a set of tasks into a deliverable than a time period. You have to do that anyway to deliver anything coherent.
  - pflenker 7y ago
    There are two arguments against grouping as a deliverable: 1) sprints are (supposed to be) predictable. So you know when to expect something and can plan other activities around that date. 2) (the more important reason IMHO) a sprint enforces early delivery, where features are rough and not very comfortable to use, but it’s already visible how it will look like. That means feedback can be collected and fueled into the next planning. The assumption is that it’s easier for people to talk about hidden assumptions when they interact with the software, than when they write specs
all_usernames 7y ago
Sprints are meant to be a tool to measure a team's velocity, defined as average amount of work throughput in X weeks. You don't know the average until a sprint team has worked together for several sprints on similar work. Sprints can work very well if you need to: A) Estimate the time it will take to complete a large project B) Compare productivity of different teams so you can shift or add people C) Get continual feedback on the work quality and the workflow process Over time, I've seen sprint teams become very accurate at estimating their work throughput ahead of time. This can be extremely valuable to the business delivering on its goals on time and committing to the right amount of deliverables.

all_usernames 7y ago

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.)

war1025 7y ago
> Who prioritizes? The same people that did before. > Kanban seems very chaotic 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.
- ptx 7y ago
  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.
  - war1025 7y ago
    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"

harimau777 7y ago

Wow, I honestly didn't even know that had a name. I worked at a place that did this but I just thought of it as "the only time I've seen Agile actually work".

decoyworker 7y ago

Kanban seems pretty similar to a method I used in college to track tasks, not even software tasks. This leads me to believe that it is intuitive since it more or less naturally made sense to me before ever knowing Kanban was a thing. Going to look for this or something like it when job searching.