I tuned out of this thread and several others because I saw a number
of people really failing to articulate what they know. This is
understandable because it's hard to articulate this stuff. Meanwhile,
there were a number folks misinterpreting those poor articulations and
jumping on them. I didn't have much energy to help but I'm going to
jump in now.

First off the term "waterfall" actually implies that the batch
transfer between "phases" is 100% of the WIP. When someone says
something like we have mini-waterfall for each feature, they are
implying that there is individual flow through a series of states of
information arrival for a given feature. This is not waterfall.

I hear some folks expressing concern that this linear transition
through states is sub-optimal because there isn't a feedback loop and
hence it isn't iterative. I think this is partly the failure of
articulation and doesn't actually reflect reality.

One aspect of kanban that has been discussed several times on this
list is, "how do we handle iterative flow?" The consensus converged on
the notion that mature teams "stop the line" resulting in not flowing
the item to be iterated back to a previous step/state but leave it
where it is while they rework it. So for example, if an item is in
testing and it needs rework, it is not sent back to the development
step/state but stays in the test area. For less mature teams, they
would send the item backwards, effectively revealing the iterative
flow but with some (potential) increase in WIP and some cycle time
delay introduced. This is more efficient but is considered sub-optimal
and less effective. [I'm not going to re-discuss the entire train of
thought on this. Those interested can read the archive or the blog
posts from me, or Corey or Karl on the topic.]

I'm also hearing some folks resist Karl's MMF notion and reject the
way kanban is typically being taught in the United Kingdom. The
objection relates to the size of an MMF. Once again, this topic has
been discussed at length before and the conclusion was that MMF's can
actually range from very small to very large and it depends a lot on
context and the stage of the application's life in the market.

The term "feature" is actually very loose and could mean almost
anything unless it's given in the context of the Coad Method/FDD where
it has a specific and very fine-grained meaning and relates to a
single sequence diagram in the code typically involving 1 to 15
methods across a handful of classes, and represents on average about
1.2 person days of effort to design, code and test.

I'm also seeing a number of people object to the idea that a
sequential flow is somehow in opposition to TDD/TFD or fails to permit
concurrency. Again, this has been discussed in the community at some
length and is always a topic for kanban workshops. How to cope with
concurrency has been documented in various places - probably best by
Corey on his blog. I have a whole section on it in my book. For anyone
concerned with strategies to model concurrency on a board or workflow
they might want to attend the conference in May,
http://www.leankanbanconference.com .

To provide the quick and short answer for those who can't attend the
conference or wait for the book, there are two main choices: you
choose to hide the concurrency on the board by having a single step
where multiple things are happening e.g. tests and coding; or you
choose to split the area of the board into sections to explicitly show
the concurrency. As a rule of thumb, I would leave the concurrency
hidden if the work is conducted by individuals in a TDD fashion, and I
would expose the concurrency if the work is done by different people
e.g. a separate developer and tester writing code and tests
independent of each other.

I've also heard some folks object to the idea that independent testing
is a bad thing. That the use of professional testers is bad. Or that
having a test activity after coding is bad. While the more extreme
agile folks may believe that no test team is ideal, it simply isn't
practical in many large scale situations. Some industries require
independent verification for regulatory reasons. At scale some
software systems are built in sections by various teams working
independently often in various locations spread around the world. The
integration of these elements invokes a series of integration tests.
Testing after development and the use of independent testers is both
inevitable and desirable in many cases.

While the agile community likes to promote the notion of continuous
integration and automated regression testing this simply isn't viable
on very large scale activities. For example, the system testing of a
cell phone with the network while both the cell phone platform code
and the network platform code are in development simultaneously.

The folks who are raising objections to this seem to be upset that
perhaps kanban is capable of gracefully coping with this issue without
and special adjustment. At the same time, they seem to fail to
understand that kanban is equally good at dealing with a craft style
of software development without handoffs. Kanban around XP is exactly
what Arlo Belshee called Naked Planning.

Strangely we've seen folks on this list say that Naked Planning is OK
while Kanban isn't. What this really implies is that the advocates of
Naked Planning really likes Extreme Programming and rejects other
development processes as somehow old, inappropriate, not agile or
otherwise. While these individuals are welcome to their opinion and
its fine that these other approaches are not for them, the reality is
that there are lots of different approaches in use in our industry.
Kanban is agnostic to the engineering practices and is inappropriately
the focus of the objection. Kanban simply provides a pull system for
these other processes.

Finally, I hear several people on this list object to case studies
that have been presented in the community. Often these objections are
based around the notion that the presented approach is "not agile."
Meaning, the team in the study was not using Extreme Programming or
Scrum. It's rather a pity that this comes up because it is the
objector who is missing the point. The entire point is that kanban
enabled teams who were not using Extreme Programming or Scrum to make
significant progress. By adding kanban discipline to their world,
these teams "uncover[ed] better ways of developing software."

It's therefore very sad, in my opinion, that the people raising these
objections, some of whom would claim to be strong advocates of Agile
development and thought leaders in the agile community, have lost
sight of the original goal behind Agile and are unable to recognize
new and additional "better ways of developing software" when they come
along.

Regards,
David
http://www.agilemanagement.net


--- In kanbandev@yahoogroups.com, "Keith Braithwaite" <keith@...> wrote:
>
> --- In kanbandev@yahoogroups.com, Steven Harman <steveharman@> wrote:
> >
> > I agree, it still sounds _like_ waterfall, except we're using a
bunch of
> > little tiny waterfalls, a little tiny waterfall-per-feature to be
exact.
> OK. So, that's quite worrying. Lots of little waterfalls is known to
be an approach that looks good
> from a distance but misses the point and the benefit of actual
iterative development.
>
> I also am of the opinion that anything defined at the granularity of
a whole feature is not "tiny" in
> the context of building software as I understand it.
>
> > With Kanban systems we have other mechanics in place, like WIP limits,
> > back-to-back queues, we're tracking cycle times, visual flow & control
> > signals, etc....
>
> All of which is great stuff, but I don't understand how it addresses
the principal failure mode of
> waterfall (large or small, few or many) which is the arrival of
unknown amounts of unplanned
> rework when the post-hoc tests fail.
>
> There are a very few kinds of development work where the waterfall
is effective, maybe you are
> doing those. But I doubt it. If you are successful (I'm assuming you
are) then I'll bet you a pound
> that upon closer inspection your engineering practices turn out to
be iterative.
>
> Keith
>