
Is Kanban the New Scrum? - aespinoza
http://www.infoq.com/news/2012/07/is-kanban-the-new-scrum
======
specialist
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
> 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
#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).

~~~
anthonyb
#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.

~~~
specialist
#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.

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

~~~
specialist
#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."

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

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

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

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

------
MattRogish
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
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
We use Pivotal Tracker, Github, Campfire, Google Docs, Dropbox. That's about
it!

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

~~~
zbuc
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
Er, that's pretty much Scrum in a nutshell :)

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

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

~~~
vladvlad
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?

------
splicer
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/>

------
jph
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...](http://steve-
yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html)

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

------
kyle_martin1
No. Kanban is Kanban. Scrum is Scrum.

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

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

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

