Open Stack

> Multidisciplinary training rules! As an architect with field experience
> building roads, sidewalks, roofs, city planning (and training in lean
> manufacturing and services) I think I can have a say ;)
> 
> > You're not really introducing a successful Kanban here, you're just
> > clarifying that there should be a set number of workstations.
> 
> Right, and to clarify I'm really thinking kanban here, expanding on the
> few lines Mikal used to explain the 'slots' concept.
> 
> > Our current system is like a gigantic open space with hundreds of
> > half-finished pieces, and a dozen workers keep on going from one to
> > another with no strong pattern. The proposed system is to limit the
> > number of half-finished pieces fighting for the workers attention at any
> > given time, by setting a clear number of workstations.
> 
> Correct, and I think we should add a limit to the amount of WIP, too. So
> we have a visible limit to people, workstations and Work In Progress.
> This way we can *immediately*, at any given time, identify problems.

If there's a trend in the replies from folks with experience
of running manufacturing or construction pipelines out in the
wild, it seems to be:

  extend the reach of the back-pressure further up the funnel 

This makes logical sense, but IMO simply doesn't apply in our
case, given the lack of direct command & control over the stuff
that contributors actually want to work on.

If we try to limit the number of WIP slots, then surely aspiring
contributors will simply work around that restriction by preparing
the code they're interested in on their own private branches, or
in their github forks?

OK, some pragmatic contributors will adjust their priorities to
align with the available slots. And some companies employing
large numbers of contributors will enforce policies to align
their developers' effort with the gatekeepers' priorities.

But I suspect we'd also have a good number who would take the
risk that their code never lands and work on it anyway. Given
that such efforts would really be flying beneath the radar and
may never see the light of day, that would seem like true waste
to me.

I don't have a good solution, just wanted to point out that
aspect.

Cheers,
Eoghan

> > A true Kanban would be an interface between developers and reviewers,
> > where reviewers define what type of change they have to review to
> > complete production objectives, *and* developers would strive to produce
> > enough to keep the kanban above the red line, but not too much (which
> > would be piling up waste).
> 
> Exactly where I am aiming at: reducing waste, which we already have but
> nobody (few, at different times) sees. By switching to a pull 'Just In
> Time' mode we'd see waste accumulate much earlier than as we do now.
> 
> > Without that discipline, Kanbans are useless. Unless the developers
> > adapt what they work on based on release objectives, you don't really
> > reduce waste/inventory at all, it just piles up waiting for available
> > "runway slots". As I said in my original email, the main issue here is
> > the imbalance between too many people proposing changes and not enough
> > people caring about the project itself enough to be trusted with core
> > reviewers rights.
> 
> I agree with you. Right now we're accumulating waste in the form of code
> proposals (raw pieces that need to be processed) but reviewers and core
> reviewers' attention span is limited (the number of 'workstations' is
> finite but we don't have such limit exposed) and nobody sees the
> accumulation of backlog until it's very late, at the end of the release
> cycle.
> 
> A lot of the complaints I hear and worsening time to merge patches seems
> to indicate that we're over capacity and we didn't notice.
> 
> > The only way to be truly pull-based is
> > to define a set of production objectives and have those objectives
> > trickle up to the developers so that they don't work on something else.
> 
> Yeah, don't we try to do that with blueprints/specs and priority? But we
> don't set a limit, it's almost a 'free for all' send your patches in and
> someone will evaluate them. Except there is a limit to what we can produce.
> 
> I think fundamentally we need to admit that there are 24 hours in a day
> and that core reviewers have to sleep, sometimes. There is a finite
> amount of patches that can be processed in a given time interval.
> 
> It's about finding a way to keep producing OpenStack at the highest
> speed possible, keeping quality, listening to 'downstream' first.
> 
> > The solution is about setting release cycle goals and strongly
> > communicating that everything out of those goals is clearly priority 2.
> 
> I don't think there is any 'proposal' just yet, only a half-baked idea
> thrown out there by the nova team during a meeting and fluffed up by me
> on the list. Still only a half-baked idea.
> 
> I realized this is a digression from the original thread though. I'll
> talk to Russell and Nikola off-list (since they sent interesting
> comments, too) and John and Dan to see if they're still interested in
> formulating a comprehensive proposal.
> 
> /stef