Hacker News new | past | comments | ask | show | jobs | submit login
Is Kanban the New Scrum? (infoq.com)
38 points by aespinoza on July 5, 2012 | hide | past | favorite | 35 comments

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.

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

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

#1 - designer needs to put a box that does 'x' on your web app (login, show shiny stars, number of commits, whatever). He writes the HTML and calls on devs to help him implement whatever he needs to make that box happen. Devs implement a template tag, then the function calls that are needed to support it, maybe extend the database models or interfaces they need to make that happen, etc. HTML -> code -> database.

How is that not Kanban/pull? This pattern appears in a lot of places once you start looking for it, from SICP and their 'pretend the function already exists' onwards.

#2 - Testing is part of the feature, not bolted on. If a feature isn't tested, by both QA and your customer, it's not done, is it? Not in traditional Scrum, anyway. If your definition of done includes "ship it, untested, to the customer at the last minute", by all means document that with a poster on your wall ;)

And if the PHBs are defining both the length of the sprint and what goes into it, then it's not really scrum either. The whole point of the timeboxing is not to have a death march, but to avoid a death march, and a whole bunch of features glommed on, untested, at the last minute.

#1 - Use cases can be chunked. The first iteration. There after it's all fit, wiggle, finish, adjustment. We have daily back and froths about "the other 90%" of effort. The PHBs want stickies for all the inevitable ancillary tasks that spawn from top level tasks. To me, it's just make work, the "process tax" that Yegge refers to.

#2 - I'd agree with you about "by sprint end" for unit tests and any other harnesses that devs can write. But real QA/test work? I just don't see it. When I've been in charge, the three areas (reqs, dev, test) are interleaved. Makes for nice feedback loops. If dev and test had their own sprints, with test trailing by a week or so, I could almost see that working.

#2b - I've never seen sprints finish nicely, where unfinished work (points) didn't carry over to the next sprint. Total fiction that anything gets "done".

With proper project management, imho, the scope of work is predetermined and things get dropped to meet a hard deadline, or the deadline is pushed. And the final acceptance testing (e.g. go/no-go process), without fail, takes two weeks. That's tacked on to the tail of when everyone has jointly decided that everything's "done". I've yet to see that kind of quality, rigor, professionalism using scrum.

1. Definitely not. If the story needs fit, wiggle, adjustment, then it's either not really done, or you raise the changes as another story for the next sprint.

2. Done is done - it's a binary yes/no thing. Done but not tested is not done. Done but needs documentation is not done. This varies from place to place, but code-done is not done, and coding is usually only 30-odd % of the work.

2b. If that's the case, then you're overcommitted. Next sprint, drop back to what you managed to get done this sprint. The idea is to get things repeatable and features turning out in a maintainable steady fashion.

In practice, it works - if there's some discipline from both the devs and the business. If stuff gets shoehorned in, or devs are pulled off to work on critical stuff, then it works about as well as you'd expect (ie. not very).

#1 - I've never seen UI work that simple. Ever. Maybe my problem is that I'm working on interesting projects.

#2 - Tom Lasseter (Pixar) supposedly said "We release snapshots of our movies, they're never done."

Apparently your problem is having PHBs and a dysfunctional org, not scrum.

> the scope of work is predetermined

That's bullshit/impossible for most software, and the exact opposite of being agile and catering to real needs, not imagined ones. That's the whole point of agile methodologies, embrace change.

Scrum and Kanban don't speak to testing; they are meta-procsses. There are, however, plenty of implementations to "agile" testing (for lack of a better term) that "plug in" to scrum and kanban. My stuff, which is all over the intarwebs, ain't terrible, and there are plenty of others who have written in this space - I am Matthew Heusser.

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.

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.

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

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.

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.

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.

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?

We use Pivotal Tracker, Github, Campfire, Google Docs, Dropbox. That's about it!

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.

Kanban and scrum are the revenge of the untalented and the humanities majors who would like to have technology jobs without having to learn anything about, you know, technology.

Why not just learn about methodology instead?

One of my least favorite aspects of the whole thing is having someone with little to no actual cs/math/ee/programming background tell me that since he/she/it used it for some trivial web programming, clearly my group doing r&d in machine learning were a bunch of morons who just didn't _get_ it because we thought it was incompatible with the kind of work we did.

Not all software work is cookie cutter.

  *I don't know of any other profession that has such elaborate...*
Education (the profession) comes close. But probably does more damage long term.

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.

Er, that's pretty much Scrum in a nutshell :)

Not in my experience, no. In fact, it's pretty nearly the farthest thing from the getting shit done thing I've actually dealt with.

Just getting shit done doesn't mean bullshit arbitrary time-slices, half-day postmortems at the end of said timeslices, insertion of "project managers" who know little to nothing of either the actual business problem being address or the technical means used to address it, people working on a parallel svd implementation having to explain their work daily to web designers, blah blah blah.

The whole thing is a money making cult for the people who invented it, and a means of empowering a class of employees (project managers) who should exist only in very small numbers, if at all.

The claim seems to be that if you don't use scrum, you will just end up doing some horrible waterfall. This is a false dichotomy.

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

Thanks - I think...

That's the end goal, unfortunately there are plenty of cargo cultists that don't really understand it and think the process is the important part.

I've worked on scrum teams before, it can be done well if no one takes it too seriously IMO. Once you start guilting the team over the artifacts of scrum, it's fallen apart and become a detriment to your goal of Getting Shit Done.

This is the no-true scotsman argument. I have yet to see scrum implemented in a way that wasn't taken too seriously, that didn't make the team's life harder, etc, etc. It's just too easy to say they're all doing it wrong, if it's almost always done wrong.

Maybe the reality is that it only works for some kinds of programming, when not taken too seriously. But then why bother at all?

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/

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

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.

No. Kanban is Kanban. Scrum is Scrum.

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.

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

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

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact