Hello, John. On Saturday, June 20, 2009, at 8:51:39 PM, you wrote:

> Sorry about recent miscommunication. Either I'm not doing a good job of
> communicating, or you are taking devil's advocate to the point that I'm
> calling it miscommuncation.

It has to be you. We all know that the written word communicates
perfectly unless the reader screws up.

> Lead times *ARE* your estimates. We still estimate using a kanban
> approach. Our estimates place work into Classes of Service - very similar
> in concept to the point system that I've grown to love over the years with
> XP. The effort is very similar, perhaps a bit less than XP points. It's
> all estimates at the end of the day.

Yes ...

> Lead time in a pure pull system is the equivalent of velocity in XP.

Yes. I recommend using real velocity for estimates even in
iteration-oriented situations.

It seems to me that iteration velocity, N stories per K weeks, is
just exactly the sum of the kanban velocity over the same K weeks.

I would also expect that a kanban team will do best if it already
understands and can execute practices like continuous integration
and automated testing. If not, then of course, the need will show up
as a bottleneck at those stations ... if the work is broken down so
as to make those stations, at least.

And, of course, an iteration team of similar sophistication to the
kanban team will also notice the same bottleneck. Especially since
practically every team I visit these days is using a kanban-style
task or story board.

> Kanban and XP point estimating are nearly similar except for the explicit
> limiting work in progress that kanban prescribes. When practicing XP/Scrum,
> we limited work in progress to a team decision ("are we ready to pull in
> another story?").

One thing that I don't see is why it'd make a big difference. All
the decently-functioning teams I see already work on one story at a
time (per pair or whatever a good breakout is). None of them work on
more stories than they can swarm effectively. They work on the
stories in the iteration plan in priority order, pulling them into
"in process" only when ready. If they run out of stories they ask
for more. If they don't get done with some, they are the lowest
priority ones.

So, just based on what I've seen, observed, and reasoned about, I'd
expect the WIP limits to perhaps highlight bottlenecks more readily
but it isn't as if everyone doesn't already know they are blocked on
GUI or Test or whatever it is.

One thing that kanban clearly does focus on, as does Lean, is
extending the line up and down stream, so that more and more of the
value stream is visible.

But in the end, it seems to me, it's exactly the same Petri Net
either way.

Doesn't mean I wouldn't do it or recommend it: I would. But the
arguments that it is somehow substantially different from Agile done
well are not convincing as yet. The comparisons to date sound to me
as if they are comparing kanban done well with agile done poorly.
Apples to apples, I'm not seeing that the math is really that
different.

Mind you, I do see that it may be easier to detect bottlenecks, and
I'm open to the possibility (but not convinced) that it is harder
for management to apply undue pressure. The reason I'm not convinced
is that it apparently requires management to agree to play by the
kanban rules. If they will agree to that, then iteration proponents
should be allowed to assume that they'll agree to yesterday's
weather.

Mind you, I have not as yet worked with a team doing pure kanban,
especially by the changing definition of today. I've worked with two
teams who pulled stories whenever they needed one, and one of them
liked it and one did not.

From a theoretical angle and I would like to think a rather
thoughtful one, I'd expect iterative with a prioritized iteration
plan to work like a digitization of kanban as seen from the outside
... and to work very similarly as seen from inside.

As yet, I've been unable to read through the rhetoric and
proselytizing to get a theoretical sense. As for the practical side,
one success or a few tells us nothing. I am totally sure that a team
I coached, who did as I coached and as they figured out with that
coaching, would perform well whether kanbanning or iterating. I
believe that performance is about the team and their working
together far more than it is about the details of their process.

I could, of course, be wrong. It's just not the way to bet. :)

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
The fact that we know more today, and are more capable today,
is good news about today, not bad news about yesterday.