headers
Ron Jeffries | 1 Aug 2009 02:04
Picon
Favicon
Gravatar

Re: Re: iterations, continuous flow, kanban ...

Hello, Chris.  On Thursday, July 30, 2009, at 9:30:35 PM, you
wrote:

>> You say the goal was not to eliminate iterations. Did you observe
>> any change in what might be iteration-based "pressure"? I'm guessing
>> not, given the situation, but curious.

> I'm not 100% sure what you mean by iteration pressure. I think you mean,
> "Did the team still feel a pressure to commit to a set of features and
> deliver them?" If that's the question, then I'll say no, there was no
> change- the team still had to make and meet commitments. What did change was
> the teams confidence in delivering the features that they said they would
> deliver. And they found it was easier (after a few months) to do a quick
> daily plan - they would get the status of each WIP story, load the kanban,
> and deliver.  This replaced one big weekly iteration meeting. However, the
> team still had to show that they were delivering according the release plan.

Why might going to kanban have increased their confidence?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Those who believe complexity is elegant or required don't understand
the problem. -- John Streiff
Permalink | Reply | 0 comments |
headers
Jeff Grigg | 2 Aug 2009 16:53
Favicon
Gravatar

iterations vs continuous flow, kanban ...

--- Arnaud Bailly <abailly <at> ...> wrote:
> I join the choir of appraisal to Ron Jeffries for starting
> this interesting thread.

Me too.

> [...] AFAICT ([...]), kanban is "just" a signaling technique
> to constraint the size of queues in a process. Define process
> cycle time, queues, inputs/outputs, you got a nice Markov
> process which you can solve to define the optimum number of
> kanbans, ie. the optimal number of work items transiting at
> a single point of time in all the process.

We tried kanban on a number of teams at my previous employer.  I was not impressed.

The biggest problem I had with kanban is that since it's designed to manage the size of the handoff queues
between work processes, teams will add queues (IE: handoffs) to the process in order to have something to
manage with kanban.  In other words, we create a problem because we happen to have selected a tool that
manages that problem.  "We need a separate testing phase," they say, "so that we can manage the number of
work items waiting to be tested."  And then we need an analysis phase, a design phase, and a code review phase
after the coding phase, etc.  Waterfall anyone?

I've seen kanban work well in operations groups -- those who respond to randomly arriving service requests
which can each be completed and delivered independently of each other.  But if you're going to package up
and deliver a new version of a working system every month (or every two weeks or whatever), then I don't find
it helpful to deny the actual release heartbeat in favor of an unhelpful flatline flow.
Permalink | Reply | 1 comment |
headers
Jeff Grigg | 2 Aug 2009 17:00
Favicon
Gravatar

Re: iterations vs continuous flow and kanban ...

--- "Karl Scotland" <kjscotland <at> ...> wrote:
> Don's feeling is that a limit based Kanban System is more
> flexible as we can have more control over different classes
> of work, so different types of work can flow at different
> rates. [...]

Kanban keeps reminding me of the original Ford assembly line, focused on the person at each workstation
doing the same thing over and over.  This conflicts with my conclusion that if we find ourselves doing the
same work over and over in software development, then we're doing it wrong:  If it's the same code, reuse it. 
If it's repeated work steps, then automate it.  We create the most value by utilizing our creative
potential as human beings.
Permalink | Reply | 34 comments |
headers
Jeff Grigg | 2 Aug 2009 17:20
Favicon
Gravatar

Re: iterations vs continuous flow and kanban ...

> --- Karl Scotland<kjscotland <at> ...> wrote:
>> He used the analogy of emptying a bucket of water. [...]

--- Steven Gordon <sgordonphd <at> ...> wrote:
> What if the rate of water flow fluctuated unpredictably within
> a range- as an analogy to software development and other
> knowledge work, where we really do not know what we do not
> know until we are in the middle of doing the work?   This, I
> believe, is the central issue that a work-management approach
> originally evolved in manufacturing has to overcome to be
> appropriate for software development.

Exactly!

When our requests vary from "please add a comma to this label" to "redesign the whole system; I don't like the
way it works.", then starting from an assumption that water generally flows smoothly and uniformly
unless acted upon by an outside force is remarkably misleading.

> [...], if the water always flowed at the same rate, then fixed
> bucket sizes would likely make time-boxes a non-issue.

I think it's more like the end of a glacier -- where small and large chunks calve off into the ocean, varying
with time of day, temperature, wind, tides and possibly many other factors.

Perhaps it's better to think of filling a UPS truck with boxes of random sizes -- with certain upper limits
because we just won't accept boxes of excessive size or weight.  But a truck's too big:  Perhaps instead,
we're filling a series of fixed size "release" boxes with products of varying (difficulty/cost) sizes,
for regular release to our customer community.  We could vary the box size, but this would be confusing and
inconvenient for our business customers:  Knowing when the N+1 release will happen also reduces the
pressure to cram everything into release N, as has been discussed extensively elsewhere.
(Continue reading)

Permalink | Reply | 18 comments |
headers
Bill Caputo | 2 Aug 2009 19:07
Favicon

Re: Re: iterations vs continuous flow and kanban ...

On Sun, Aug 2, 2009 at 10:20 AM, Jeff Grigg<jeffgrigg <at> charter.net> wrote:
> Perhaps it's better to think of filling a UPS truck with boxes of random sizes...
> Perhaps instead, we're filling a series of fixed size "release" boxes with products of
> varying (difficulty/cost) sizes...

Or perhaps instead: We're writing and deploying computer programs? The
focus on argument by analogy is what bothers me the most about this
whole Kanban thing - that people (not you Jeff, just ganging on to
your post) seem really keen to re-cast everything into TPS
terminology, so that "user stories" become "Agile Kanban cards" and
we're not partway through a coding task, we're "WIP" so that our done
pile becomes a "Store" that feeds another work queue...

Is there potentially something to be learned by studying other domains
(certainly, as Toyota showed by adapting supermarket processes to
building cars), but does it follow that we are best served by
recasting our entire process in that domain's image? I don't see the
benefit, other than that it provides consultants a new way to sell
their services (you're Agile? oh please that's so 5 years ago, no you
need to go Kanban, and we have the industry experts on applying it. I
can provide you 3 of them at 225 an hour starting next week...)

This whole thread reminds me of this Dijkstra EWD:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

The core problem I've always had with over-borrowing from Lean, JIT,
TPS, etc is that applying such analogies ends up blinding us to what
process improvements are possible within our own domain that would be
inconceivable in manufacturing. Just because software process got off
on the wrong foot by borrowing from traditional manufacturing doesn't
(Continue reading)

Permalink | Reply | 16 comments |
headers
Karl Scotland | 2 Aug 2009 20:06

Re: iterations vs continuous flow and kanban ...


--- In extremeprogramming <at> yahoogroups.com, "Jeff Grigg" <jeffgrigg <at> ...>
wrote:
  I think it's more like the end of a glacier -- where small and large
chunks calve off into the ocean, varying with time of day, temperature,
wind, tides and possibly many other factors.
>
> Perhaps it's better to think of filling a UPS truck with boxes of
random sizes -- with certain upper limits because we just won't accept
boxes of excessive size or weight.  But a truck's too big:  Perhaps
instead, we're filling a series of fixed size "release" boxes with
products of varying (difficulty/cost) sizes, for regular release to our
customer community.  We could vary the box size, but this would be
confusing and inconvenient for our business customers:  Knowing when the
N+1 release will happen also reduces the pressure to cram everything
into release N, as has been discussed extensively elsewhere.
>

Of we could put the boxes on a conveyor belt in priority order, with the
highest value boxes first, and let the customer take them off one by one
:-)

Karl
Permalink | Reply | 0 comments |
headers
Karl Scotland | 2 Aug 2009 20:10

Re: iterations vs continuous flow and kanban ...

Hi Jeff

--- In extremeprogramming <at> yahoogroups.com, "Jeff Grigg" <jeffgrigg <at> ...>
wrote:
>
> Kanban keeps reminding me of the original Ford assembly line, focused
on the person at each workstation doing the same thing over and over. 
This conflicts with my conclusion that if we find ourselves doing the
same work over and over in software development, then we're doing it
wrong:  If it's the same code, reuse it.  If it's repeated work steps,
then automate it.  We create the most value by utilizing our creative
potential as human beings.
>

I'm wondering where you had your experience of using a Kanban System for
Software Development. It sounds very different from mine. Did you have a
coach experienced with using Kanban Systems? The Kanban based approach I
use has very little in common with manufacturing, maps and improves an
existing value stream, and creates value through human creativity.

Karl
Permalink | Reply | 33 comments |
headers
Ron Jeffries | 2 Aug 2009 21:09
Picon
Favicon
Gravatar

Re: Re: iterations vs continuous flow and kanban ...

Hello, Karl.  On Sunday, August 2, 2009, at 2:10:51 PM, you wrote:

> I'm wondering where you had your experience of using a Kanban System for
> Software Development. It sounds very different from mine. Did you have a
> coach experienced with using Kanban Systems? The Kanban based approach I
> use has very little in common with manufacturing, maps and improves an
> existing value stream, and creates value through human creativity.

We have talked before about how many examples of kanban look like
waterfall. That might be a contributor.

And of course a good coach is always of value. But most of the world
seems to learn from books papers articles word of mouth. There's a
lesson in there, I suppose ...

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Improvement stops when we start believing that
ideas about how to improve are insulting.
Permalink | Reply | 32 comments |
headers
Karl Scotland | 2 Aug 2009 21:36

Re: iterations vs continuous flow and kanban ...

Hi Ron

--- In extremeprogramming <at> yahoogroups.com, Ron Jeffries
<ronjeffries <at> ...> wrote:
>
> We have talked before about how many examples of kanban look like
> waterfall. That might be a contributor.

Yes. And we always go on to talk about how a Kanban System visualises a
value stream, rather than defines it, and how visualising that value
stream helps the team improve it, and how improving the value stream
might reduce the number of stages and help the team to a more
collaborative, multi-skilled process.

And we have talked before about how a Kanban System for Software
Development is not simply trying to copy the manufacturing elements of
the Toyota Production System, but bears more resemblance to the Toyota
Product Development System, and is actually based on the underlying
theories and science of flow.

> And of course a good coach is always of value. But most of the world
> seems to learn from books papers articles word of mouth. There's a
> lesson in there, I suppose ...

Yes. And there is virtually no literature about Kanban Systems for
Software Development yet. Just some blogs at the moment. I'm not wanting
to create too much noise on this list by trying to explain the Kanban
approach. I hope that if people are open minded and want to learn, they
will come to the kanbandev list to find out more (despite the reputation
;-). Happy to discuss the Kanban approach in relation to XP here though.
(Continue reading)

Permalink | Reply | 31 comments |
headers
Jeff Grigg | 3 Aug 2009 01:27
Favicon
Gravatar

Re: kanban analogies and WIP waste

--- Bill Caputo <list-subscriber <at> ...> wrote:
> [...] The focus on argument by analogy is what bothers me
> the most about this whole Kanban thing - that people (not
> you Jeff, just ganging on to your post) seem really keen
> to re-cast everything into TPS terminology, so that "user
> stories" become "Agile Kanban cards" and we're not partway
> through a coding task, we're "WIP" so that our done pile
> becomes a "Store" that feeds another work queue...

I'll misquote George Box here:
  "All [analogies] are wrong, some are useful."

Arguments by analogy are weak:  People need to realize that ALL analogies break down somewhere.  Kanban's
water flow analogy is misleading because water flow tends to be even and steady unless acted on by an
outside force, while our work can only be even and steady if we work hard to make it so.  And even my box
analogies are misleading, as the space in the truck or box represents the real work, not the work of packing
the box or truck, or driving the truck.

Actually, I quite like the lean concept that Work In Progress (WIP) is waste:  The time between doing work and
delivering its value to the business users is waste.  We can reduce this waste and deliver business value
sooner by reducing cycle time -- by deploying more often.  Strong automated regression testing is
necessary to make this practical.  I think this is all true and good.

But from what I've seen, the kanban process is tuned for manufacturing, not design.  And that's why it's not
nearly as useful for software development as many people would have you think.
Permalink | Reply | 12 comments |

Gmane