Hi all

I have a couple of practical questions regarding the use of Kanban.

1. Some kinds of work, such as usability/interaction design are
suggested to be performed best on a larger set of features, rather than
on individual features. Scrum teams often do this kind of work in Sprint
n-1. The risk of focusing exclusively on one-piece flow, is a disjointed
design and/or user experience. Is this a problem, and if so, how have
people addressed it? I imagine it could be addressed by adding an early
"Usability" state, and giving it a relatively high limit, such that a
larger set of functionality can be considered together - but this would
obviously impact cycle time. The need for high-level system design is
similar.

2. Often our customers don't really know what they want until they see
it in action. Since we are using tools that allow us to change our minds
easily (Rails), the cost of making design mistakes is lower than the
cost of detailed analysis. Therefore, we find that it is often best to
start with a fairly vague idea of what the customer wants, write
something, and iterate in collaboration with the co-located customer.
The Pragmatic Programmers call this "Tracer Bullets" (p 48 in their
original book). My question is, given this situation, do people still
find value in splitting out an "Analysis" state? Bear in mind that
development includes TDD and automated acceptance testing.

My second question seems to contradict my first. In past projects we
have not done any usability work up front, and we have been bitten for
it.

My short story, and a few thoughts:

When my team first started doing agile development (about 18 months
ago), we didn't know anything about Kanban or Scrum. We found it natural
to work without iterations, and to pull features from TODO, to In
Progress, to Done, generally limiting ourselves (though no strictly) to
one or two items in 'In Progress'. It was only after attending a CSM
course that I 'saw the light' and implemented iterations, along with the
rest of Scrum. We liked the ability to report on progress and
extrapolate for future planning. However my reading quickly turned to
Lean, and I had a niggling feeling about the artificial constraint of a
time-box, and started to think about applying flow more faithfully. I
first came across the Kanban movement when David Anderson's presentation
was published on InfoQ, and was thrilled to find that others had already
blazed the trail. My sphere of influence has since grown to cover
several development teams, and over the next few weeks and months I will
be working to move them from Scrum to Kanban.

Reading Corey Ladas' book has been fantastic - I love the clarity of his
thinking and explanation, especially in exposing the assumptions we can
so easily make, or accept when so many people are espousing them. My
only grumble is the title of the book. I have heard of several mutations
of agile methodologies, including "ScRUP" and when I first read the
title "Scrumban" I assumed it was another misguided twisting of Scrum.
On reading it I was pleased to find otherwise :)

One thing that lean authors constantly remind us is that lean is more
than a set of tools, and that many would-be adopters of lean (eg: GM)
understood and implemented the techniques, but missed the real
differences that set Toyota apart. Some of these are "respect for
people" (ie: empowering and challenging people to use their full
capability) developing a "culture of continuous improvement" and
developing the ability to capture and benefit from tacit knowledge. I
think it's great that Kanban is being applied so successfully. Let's
make sure we also learn and develop the finer characteristics of a lean
organisation.

One final question. Does anyone maintain a collection/listing of Kanban
resources available on the web, particularly references to video
presentations? If not I might need to start one :)

Cheers

Russell Healy
Wellington, New Zealand