Russell,

The biggest misunderstanding about Kanban is that you change your process. You
don't! You model what you do now. If you currently don't have a separate
"analysis" function/state then under NO circumstances should you create one when
adapting to Kanban. Kanban is about putting WIP limits on what you do now and
instituting a pull system.

You are in an interesting position that you have a highly collaborative, highly
iterative approach to information discovery in software design. That's cool! The
challenge for you is that you can't copy someone other documented Kanban design.
You'll need to work out the value streams and WIP limits from first principles.

From what you've described I would have a separate Kanban value-stream/board for
the interaction/UI designers than for the developers. This will solve your
"granularity" problem. With a 2 board design, the output from design becomes a
required input to development, an entry criteria which will preclude a story
from being pulled if it isn't present.

Some coordination will of course be necessary between the two board and teams,
but I imagine you are doing this coordination already.

David
http://www.channelkanban.com/

--- In kanbandev@yahoogroups.com, "Russell Healy" <russell.healy@...> wrote:
>
> 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
>