7 ms·

Is Kanban the New Scrum?

38 points by aespinoza 14y ago

wsc981 14y ago
I know I'm gonna sound short-sighted, but personally I don't 'enjoy' SCRUM in any way. For me it feels like handing over freedom and the sprints actually create a sort of pressure for me. I guess I tend to overcommit and perhaps Kanban is trying to solve this. Still, the feeling of being limited in freedom is the greatest annoyance to me and perhaps the fact that there's little room inside sprints for emergencies (at least this was how SCRUM was implemented in the last company I worked at). I really appreciate flexibility in ordering and the execution of tasks and SCRUM didn't grant me this ability. I wonder if people around here feel the same ...
- willvarfar 14y ago
  I feel that way too http://williamedwardscoder.tumblr.com/post/20054342100/agile-is-a-sham http://williamedwardscoder.tumblr.com/post/20054342100/agile...
- MrEnigma 14y ago
  I don't enjoy it either, to me even though some principles are quite different, it seems like a series of mini waterfalls. The other thing is that it seemed to remove any creativity of control from the developers. In some cases this is a good thing because developers get stuck in ruts and heads way in the sand. But small tweaks improvements that only show themselves to be available when you get into the code, can't' be done. They'll be put in the backlog, and generally never lifted to the top. And if you put them in, then it 'adds risk to the sprint'. Ultimately it feels like it removes a lot of fun from the role of developing. Granted a lot of the above stem from the company and not necessarily the process.
benhoskins 14y ago
Fluff piece; is extreme programming the new extreme programming? Who cares! What problem is trying to be solved?
K2h 14y ago
In this context, it seems kanban is being used in place of a more appropriate word, 'que'. In a physical sense, a kanban usually has the same thing going into it.. here the author was clear to say that different jobs have different scopes (time requirements) and I fail to see how this fits from a kanban. Items going into different bins, using a signaling mechanism on when to create more of 'what goes in the bin' doesn't work for me when these 'items' in the kanban bin are 'product features'.
jph 14y ago
Kanban is essentially a priority queue, and Steve Yegge wrote a great blog post about this issue some years ago. Worth reading. http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...
moocow01 14y ago
I guess Im too seasoned but Ive come to really resent all these project management 'techniques'. I don't know of any other profession that has such elaborate and cultish ideologies for getting stuff done. The funny thing is that none of this stuff is all that impactful in reality - you either have a good team, a bad team or more likely something somewhere in between. Unfortunately there is an army of project managers that keep on pushing the new magical pill as if its progress.
- specialist 14y ago
  *I don't know of any other profession that has such elaborate...* Education (the profession) comes close. But probably does more damage long term.
- zbuc 14y ago
  I prefer the "getting shit done" methodology. Find the least amount of process necessary to get your work done and make sure everyone knows what's going on and has reasonable expectations. It's honestly not hard to do this, and you don't need a crazy methodology to do it.
  - anthonyb 14y ago
    Er, that's pretty much Scrum in a nutshell :)
    - ricardobeat 14y ago
      As naive as this comment seems, it's mostly true. Scrum is just a packaged set of practices intended to ease adoption of the agile philosophy. The end goal is to minimize process and maximize communication, which is exactly the same as "get shit done".
      - anthonyb 14y ago
        Thanks - I think...
      - 14y ago
MartinCron 14y ago
If you mean, "well-intentioned, trendy, over-promoted, and misapplied by people who have a shallow understanding of it", then yes, of course it's the new Scrum.
specialist 14y ago
Here I thought Scrum was ridiculous. Then along comes kanban. I'm an enthusiastic student of methodologies, consider Deming and Drucker are patron saints, and look for "one way flow" and "eliminate waste" (muda) opportunities everywhere. I've now been on 4 scrum teams. I've been thru "master scrum training" three times. I have no idea what they're talking about. As far as I can tell, the Scrum methodology means talking about what "scrum" means. (Another possibility is that "scrum" is easier to say than "we have no idea what we're doing".) See, I'm a GANTT chart, critical path, front load as much as possible, and iterate madly kinda guy. Worked great all the times I was in charge. My current team is doing kanban. We have post-it notes that we move around. I have no idea what they represent. Chunking work like this is unnatural. There's really no way to infer the whole (work in the large, get a birds eye view) from the kanban project management artifacts. I don't see how scrum or kanban relate to QA and testing. I've asked. (I used to be a QA manager, not very good, but I understood the work.) There's just arm waving "magic goes here" between the incompatible acceptable testing ("when are you done?") and the artificial sprint deadlines. We also duplicate the kanban items in a bug tracking system. Ignoring the failings of Jira for a moment, I fail to see how how any mediated process can be "agile". I could go on and on.
- anthonyb 14y ago
  > My current team is doing kanban. We have post-it notes that we move around. I have no idea what they represent. Since the whole point of Kanban, Scrum and similar systems is to manage your work, I'd say that's the place to start figuring it out. If you don't understand what work's being done, you can't have any input, and can't improve things (one of the other points of Kanban). Also, Kanban is a pull system, not push, so it works very differently to most methodologies. You can see it in some of the modern web companies like 37Signals, with their "develop the HTML first" mantra, as well as XP and TDD. Kanban doesn't relate to testing at all as far as I know, but Scrum has their "definition of done", in that everything should be ready to ship when it's done. Normally that includes being code complete, having automated tests, customer signoff, etc.
  - specialist 14y ago
    #1 - I understand kanban in the physical (mfg) world perfectly well. It might even have value in some knowledge/creative industries, where there's a solid, predetermined, well defined workflow. Publishing, for instance. What I'm saying is that the kanban strategy does not apply to software development. Full stop. Does not map. Not applicable. Completely unrelated. Irrelevant. Moot. Nonsensical. Like measuring feline happiness in banana units. If my employer could effectively chunk my work into itty bitty little stickies, they wouldn't need me. #2 - When have you seen a scrum iteration planned around the QA/test cycle? Never? The sprints are defined by PHBs, devs grudgingly play along, QA/test can just suck it. A real QA/test org would say a product is done when its done. I've not seen that happen on any scrum project. Rather, products are done when they've run out of time or juice (eg Yourdon's death march).
programminggeek 14y ago
You know what the great irony in all of the "agile methologies" is? Lean manufacturing is almost always about process improvement. Going back and looking at your process and finding ways you can make it better, faster, cheaper, more reliable, etc. Kanban IS the new Scrum insomuch as it's the latest buzzword, but any agile process should be in itself "agile". As in, it's about shipping using the best possible process for your situation. Maybe that's scrum, or kanban, or waterfall, or something in between. If you are using any of them you should ask what problem you have with your current process and what you are solving by doing scrum, xp, kanban, etc. Dit it work? Can it be done better? What needs to be fixed? Iterate enough on your process and you'll be running like a well oiled machine regardless of what method you use. People get good at stuff with practice. Where it goes wrong I think is when you worry more about scrum vs. kanban vs. xp vs. flavor of the week because the rules don't matter, doing your work better for whatever definition of better you're optimizing for is what truly matters.
- anthonyb 14y ago
  The thing that I really like about scrum is that reviewing your work habits is built into the process, where it's more resistant to management interference. Review is a major part of doing any sort of good work, but most people seem to overlook it when talking about scrum - "I did scrum and it locked us into doing stupid blablabla" means that you're not doing scrum.
kyle_martin1 14y ago
No. Kanban is Kanban. Scrum is Scrum.
MattRogish 14y ago
Like everyone, we have our own version of Agile. Here's what SCRUM, KANBAN, and LEAN mean to me (and thus, my company): 1. Self-organizing team. No one tells you what to do. 2. Fix bugs first. No one likes a backlog full of 132,423 bugs. Fix 'em as you find em. 3. Priority queue is decided by the whole team (with input from management) but is MACRO and has value goals associated with it (e.g. redesign signup - increase conversions 30%). Team figures out what that means, and measures it. 4. Features that don't "move the needle" (or moves it negatively) get yanked. Code has weight and tends to rust. If it doesn't meet the business goals but is showing positive reception (e.g. increased conversions at all) bias towards rework. 5. Only work on one thing at a time. This is super important. Don't have four or five stories "in process". Too much WIP = nothing gets done. If you are blocked on something, pull the andon cord and we can figure out what we need to do to fix it. Go read a book. Go for a walk. Do something other than starting another task. 6. Velocity helps us figure out what "reasonable pace" means. That's it. It's not used for long-range planning, just "are we working at a sustainable pace?" 7. Frequent retrospectives (every two weeks) help us nudge the ship in the right direction. We evaluate our process and see what needs fixin', and make sure that promises made are not abandoned due to externalities (management interference, or other non-technical reasons). 8. Iteration planning is short and is only used to keep the team informed. 9. Use passive information radiators to communicate status and progress instead of meetings etc.
- walexander 14y ago
  I like the informal agile model versus the heavily formal Agile. It's too bad I've never really experienced anything except the latter in practice. Might I ask what tools you guys are using to manage this?
  - MattRogish 14y ago
    We use Pivotal Tracker, Github, Campfire, Google Docs, Dropbox. That's about it!
teamonkey 14y ago
I studied Kanban, as it applies to manufacturing, some time ago. I have no idea how it could apply to software development. It seems a poor fit for it. Kanban is not a queueing system, it is a system for identifying bottlenecks in a supply chain and at all times minimising the amount of components that need to be manufactured. One of the key revolutionary features was that the supply chain extends to each component so different departments become suppliers to others. What typically happens is that there are a certain number of kanban cards for each component. Each card represents one component. When a client takes a completed component from the stock, the associated kanban card goes to the start of the queue. Someone picks up the card and starts work on the component and the card follows the manufacturing process until the component has been completed. The card stays with the completed component until a client takes the component and the cycle begins again. The purpose is that by counting the number of cards at the start (number of items requested by clients) and at the end (number of items constructed but not yet claimed by a client) it becomes trivial to identify bottlenecks. Apart from this then-revolutionary pull-based process, Toyota's process had two other key findings. 1) the same worker should stay with each component until completion. One kanban card = 1 worker. If someone is assembling a car door, they don't half-complete a door and pass it on to someone else, they follow it from the time they pick up all the components to the time that it is completed. They found that this was the most productive way of working. 2) You do not deliver a faulty component to a client. That is, each component must be tested before going on to the next stage.
bdunbar 14y ago
Is kanban the new ... that just reads _odd_. Kanban has been around since the early 1950s. It's not new anything. Works great for manufacturing. Where it seems to fall down - in my limited experience - is when you try to apply it to IT. JIT / lean just doesn't work well when you get into the IT ghetto. It's still very much a craft discipline. Industrial processes don't work so well there.
splicer 14y ago
It's all bullshit IMO. My team's morning scrums have devolved into 15 minute meetings with each member of the team basically saying "I'm doing the same thing I was yesterday; piss off". I prefer Zed Shaw's methodology: http://programming-motherfucker.com/ http://programming-motherfucker.com/

38 points by aespinoza 14y ago

I know I'm gonna sound short-sighted, but personally I don't 'enjoy' SCRUM in any way. For me it feels like handing over freedom and the sprints actually create a sort of pressure for me. I guess I tend to overcommit and perhaps Kanban is trying to solve this. Still, the feeling of being limited in freedom is the greatest annoyance to me and perhaps the fact that there's little room inside sprints for emergencies (at least this was how SCRUM was implemented in the last company I worked at). I really appreciate flexibility in ordering and the execution of tasks and SCRUM didn't grant me this ability. I wonder if people around here feel the same ...

willvarfar 14y ago
I feel that way too http://williamedwardscoder.tumblr.com/post/20054342100/agile-is-a-sham http://williamedwardscoder.tumblr.com/post/20054342100/agile...
MrEnigma 14y ago
I don't enjoy it either, to me even though some principles are quite different, it seems like a series of mini waterfalls. The other thing is that it seemed to remove any creativity of control from the developers. In some cases this is a good thing because developers get stuck in ruts and heads way in the sand. But small tweaks improvements that only show themselves to be available when you get into the code, can't' be done. They'll be put in the backlog, and generally never lifted to the top. And if you put them in, then it 'adds risk to the sprint'. Ultimately it feels like it removes a lot of fun from the role of developing. Granted a lot of the above stem from the company and not necessarily the process.

benhoskins 14y ago

Fluff piece; is extreme programming the new extreme programming? Who cares! What problem is trying to be solved?

K2h 14y ago

In this context, it seems kanban is being used in place of a more appropriate word, 'que'. In a physical sense, a kanban usually has the same thing going into it.. here the author was clear to say that different jobs have different scopes (time requirements) and I fail to see how this fits from a kanban. Items going into different bins, using a signaling mechanism on when to create more of 'what goes in the bin' doesn't work for me when these 'items' in the kanban bin are 'product features'.

jph 14y ago

Kanban is essentially a priority queue, and Steve Yegge wrote a great blog post about this issue some years ago. Worth reading. http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...

moocow01 14y ago

I guess Im too seasoned but Ive come to really resent all these project management 'techniques'. I don't know of any other profession that has such elaborate and cultish ideologies for getting stuff done. The funny thing is that none of this stuff is all that impactful in reality - you either have a good team, a bad team or more likely something somewhere in between. Unfortunately there is an army of project managers that keep on pushing the new magical pill as if its progress.

specialist 14y ago
*I don't know of any other profession that has such elaborate...* Education (the profession) comes close. But probably does more damage long term.
zbuc 14y ago
I prefer the "getting shit done" methodology. Find the least amount of process necessary to get your work done and make sure everyone knows what's going on and has reasonable expectations. It's honestly not hard to do this, and you don't need a crazy methodology to do it.
- anthonyb 14y ago
  Er, that's pretty much Scrum in a nutshell :)
  - ricardobeat 14y ago
    As naive as this comment seems, it's mostly true. Scrum is just a packaged set of practices intended to ease adoption of the agile philosophy. The end goal is to minimize process and maximize communication, which is exactly the same as "get shit done".
    - anthonyb 14y ago
      Thanks - I think...
    - 14y ago

MartinCron 14y ago

If you mean, "well-intentioned, trendy, over-promoted, and misapplied by people who have a shallow understanding of it", then yes, of course it's the new Scrum.

specialist 14y ago

Here I thought Scrum was ridiculous. Then along comes kanban. I'm an enthusiastic student of methodologies, consider Deming and Drucker are patron saints, and look for "one way flow" and "eliminate waste" (muda) opportunities everywhere. I've now been on 4 scrum teams. I've been thru "master scrum training" three times. I have no idea what they're talking about. As far as I can tell, the Scrum methodology means talking about what "scrum" means. (Another possibility is that "scrum" is easier to say than "we have no idea what we're doing".) See, I'm a GANTT chart, critical path, front load as much as possible, and iterate madly kinda guy. Worked great all the times I was in charge. My current team is doing kanban. We have post-it notes that we move around. I have no idea what they represent. Chunking work like this is unnatural. There's really no way to infer the whole (work in the large, get a birds eye view) from the kanban project management artifacts. I don't see how scrum or kanban relate to QA and testing. I've asked. (I used to be a QA manager, not very good, but I understood the work.) There's just arm waving "magic goes here" between the incompatible acceptable testing ("when are you done?") and the artificial sprint deadlines. We also duplicate the kanban items in a bug tracking system. Ignoring the failings of Jira for a moment, I fail to see how how any mediated process can be "agile". I could go on and on.

anthonyb 14y ago
> My current team is doing kanban. We have post-it notes that we move around. I have no idea what they represent. Since the whole point of Kanban, Scrum and similar systems is to manage your work, I'd say that's the place to start figuring it out. If you don't understand what work's being done, you can't have any input, and can't improve things (one of the other points of Kanban). Also, Kanban is a pull system, not push, so it works very differently to most methodologies. You can see it in some of the modern web companies like 37Signals, with their "develop the HTML first" mantra, as well as XP and TDD. Kanban doesn't relate to testing at all as far as I know, but Scrum has their "definition of done", in that everything should be ready to ship when it's done. Normally that includes being code complete, having automated tests, customer signoff, etc.
- specialist 14y ago
  #1 - I understand kanban in the physical (mfg) world perfectly well. It might even have value in some knowledge/creative industries, where there's a solid, predetermined, well defined workflow. Publishing, for instance. What I'm saying is that the kanban strategy does not apply to software development. Full stop. Does not map. Not applicable. Completely unrelated. Irrelevant. Moot. Nonsensical. Like measuring feline happiness in banana units. If my employer could effectively chunk my work into itty bitty little stickies, they wouldn't need me. #2 - When have you seen a scrum iteration planned around the QA/test cycle? Never? The sprints are defined by PHBs, devs grudgingly play along, QA/test can just suck it. A real QA/test org would say a product is done when its done. I've not seen that happen on any scrum project. Rather, products are done when they've run out of time or juice (eg Yourdon's death march).

programminggeek 14y ago

You know what the great irony in all of the "agile methologies" is? Lean manufacturing is almost always about process improvement. Going back and looking at your process and finding ways you can make it better, faster, cheaper, more reliable, etc. Kanban IS the new Scrum insomuch as it's the latest buzzword, but any agile process should be in itself "agile". As in, it's about shipping using the best possible process for your situation. Maybe that's scrum, or kanban, or waterfall, or something in between. If you are using any of them you should ask what problem you have with your current process and what you are solving by doing scrum, xp, kanban, etc. Dit it work? Can it be done better? What needs to be fixed? Iterate enough on your process and you'll be running like a well oiled machine regardless of what method you use. People get good at stuff with practice. Where it goes wrong I think is when you worry more about scrum vs. kanban vs. xp vs. flavor of the week because the rules don't matter, doing your work better for whatever definition of better you're optimizing for is what truly matters.

anthonyb 14y ago
The thing that I really like about scrum is that reviewing your work habits is built into the process, where it's more resistant to management interference. Review is a major part of doing any sort of good work, but most people seem to overlook it when talking about scrum - "I did scrum and it locked us into doing stupid blablabla" means that you're not doing scrum.

kyle_martin1 14y ago

No. Kanban is Kanban. Scrum is Scrum.

MattRogish 14y ago

Like everyone, we have our own version of Agile. Here's what SCRUM, KANBAN, and LEAN mean to me (and thus, my company): 1. Self-organizing team. No one tells you what to do. 2. Fix bugs first. No one likes a backlog full of 132,423 bugs. Fix 'em as you find em. 3. Priority queue is decided by the whole team (with input from management) but is MACRO and has value goals associated with it (e.g. redesign signup - increase conversions 30%). Team figures out what that means, and measures it. 4. Features that don't "move the needle" (or moves it negatively) get yanked. Code has weight and tends to rust. If it doesn't meet the business goals but is showing positive reception (e.g. increased conversions at all) bias towards rework. 5. Only work on one thing at a time. This is super important. Don't have four or five stories "in process". Too much WIP = nothing gets done. If you are blocked on something, pull the andon cord and we can figure out what we need to do to fix it. Go read a book. Go for a walk. Do something other than starting another task. 6. Velocity helps us figure out what "reasonable pace" means. That's it. It's not used for long-range planning, just "are we working at a sustainable pace?" 7. Frequent retrospectives (every two weeks) help us nudge the ship in the right direction. We evaluate our process and see what needs fixin', and make sure that promises made are not abandoned due to externalities (management interference, or other non-technical reasons). 8. Iteration planning is short and is only used to keep the team informed. 9. Use passive information radiators to communicate status and progress instead of meetings etc.

walexander 14y ago
I like the informal agile model versus the heavily formal Agile. It's too bad I've never really experienced anything except the latter in practice. Might I ask what tools you guys are using to manage this?
- MattRogish 14y ago
  We use Pivotal Tracker, Github, Campfire, Google Docs, Dropbox. That's about it!

teamonkey 14y ago

I studied Kanban, as it applies to manufacturing, some time ago. I have no idea how it could apply to software development. It seems a poor fit for it. Kanban is not a queueing system, it is a system for identifying bottlenecks in a supply chain and at all times minimising the amount of components that need to be manufactured. One of the key revolutionary features was that the supply chain extends to each component so different departments become suppliers to others. What typically happens is that there are a certain number of kanban cards for each component. Each card represents one component. When a client takes a completed component from the stock, the associated kanban card goes to the start of the queue. Someone picks up the card and starts work on the component and the card follows the manufacturing process until the component has been completed. The card stays with the completed component until a client takes the component and the cycle begins again. The purpose is that by counting the number of cards at the start (number of items requested by clients) and at the end (number of items constructed but not yet claimed by a client) it becomes trivial to identify bottlenecks. Apart from this then-revolutionary pull-based process, Toyota's process had two other key findings. 1) the same worker should stay with each component until completion. One kanban card = 1 worker. If someone is assembling a car door, they don't half-complete a door and pass it on to someone else, they follow it from the time they pick up all the components to the time that it is completed. They found that this was the most productive way of working. 2) You do not deliver a faulty component to a client. That is, each component must be tested before going on to the next stage.

bdunbar 14y ago

Is kanban the new ... that just reads _odd_. Kanban has been around since the early 1950s. It's not new anything. Works great for manufacturing. Where it seems to fall down - in my limited experience - is when you try to apply it to IT. JIT / lean just doesn't work well when you get into the IT ghetto. It's still very much a craft discipline. Industrial processes don't work so well there.

splicer 14y ago

It's all bullshit IMO. My team's morning scrums have devolved into 15 minute meetings with each member of the team basically saying "I'm doing the same thing I was yesterday; piss off". I prefer Zed Shaw's methodology: http://programming-motherfucker.com/ http://programming-motherfucker.com/