Having problems with message search?
I really think we can't prescribe absolute system improvement indications. But we can have some really good indications by using these numbers and observing the system as whole. Not enough to define the 5th practice, but an important assumption if we are going to try it.
Alisson
On Fri, Jul 3, 2009 at 12:36 PM, rob_hathaway74 <rob.hathaway@...> wrote:
I think my concern with the 5th practice is that it assumes all things remaining constant in a system and so rarely that is the case.
There are instances where reducing kanban tokens may not be the right thing to do. If people are just reading the 5th practice they won't see or understand this.
I don't think the aim should be to reduce kanban tokens...maybe reduce cycle time or maximise value delivery but they might not be any more helpful?> 2009/7/2 Akshay Dhavale <akshay.dhavle@...>
--- In kanbandev@yahoogroups.com, Karl Scotland <kjscotland@...> wrote:
>
> A very quick response before my battery runs out...
> If you are increasing the lanes from 1 to 4 you are increasing the capacity
> of the system, so I would expect kanban tokens to increase. I am assuming a
> stable system.
>
> Karl
>> > 2009/7/2 chrismatts1968 <chrismatts1968@...>
>
> >
> > Bringing back my road traffic analogy.
> >
> > "Let's take example of a road for flow. Cars (MMF/Story) travel through a
> > particular distance(A to B) and carry a certain number of passengers
> > (value). Some cars may take 2 passengers, some may take 8.(size of MMF). The
> > goal is to maximize number of passengers transported from A to B in a given
> > time frame. From a pure scale perspective, a four lane road is always going
> > to have a higher throughput than a single lane road. However, fast a single
> > car can go."
> >
> > What if that team of 20 is so highly multi skilled that they were able to
> > swarm on a single MMF (using the term just to wind you up ;-) and get it
> > done immediately. Wouldn't that be a good thing?
> >
> >
> > So you are saying that we put a team together that can make the car with 4
> > passengers travel from A to B in 2secs vs the 30secs that it took before. I
> > agree this is great improvement.
> > But at this point wouldn't you put 4 such teams together and move 4 cars
> > delivering 16 passengers every 2 secs?
> >
> > Basically if a team reaches a particular optimum level of productivity,
> > it's time to scale, fail, adjust and repeat. The moment you scale, you
> > increase WIP for the team which is now bigger. So effectively you are not
> > after reducing WIP you are after increasing throughput. And that's all that
> > matters... right?
> >
> > Akshay Dhavle
> >
> >
> >
> > On Jul 2, 2009, at 12:21 PM, Karl Scotland wrote:
> >
> >
> >
> > I don't think I posted this blog entry to the group, so here's the link:
> >
> > http://availagility.wordpress.com/2009/06/30/the-fifth-primary-practice-of-kanban/
> >
> >
> >>
> >> Had lunch with a naughhty little munchkin who directed me to your blog
> >> post on "The Fifth Primary Practice of Kanban - Reduce the Kanban Tokens"
> >
> >
> > No names needed - how much beer did "he" buy you to send this ;-)
> >
> > Why is this a good thing?
> >
> >
> > Because it means we have less WIP, which means we can improve cycle time.
> >
> >
> >> I'm assuming you are only reducing the number of tokens to the optimal
> >> number. ( One token for a team of 20 does not seem the best. )
> >
> >
> > What if that team of 20 is so highly multi skilled that they were able to
> > swarm on a single MMF (using the term just to wind you up ;-) and get it
> > done immediately. Wouldn't that be a good thing?
> >
> >
> >> What happens when you are below the optimal number?
> >
> >
> > Is the optimal number now, the most optimal for the future? Can't we
> > improve?
> >
> >
> >> How do you determine the optimal number?
> >>
> >
> > Inspect and Adapt. Measuring cycle-time and throughput would be one good
> > way.
> > I have considered renaming the practice "Optimise the Kanban Tokens", but I
> > still feel that that misses the point. My gut feel tells me that a more
> > capable, more productive team should need less kanban tokens. Given that we
> > want our teams to become more capable and more productive, then why wouldn't
> > "Reduce the kanban tokens" be a good practice? Like any practice it
> > shouldn't be followed blindly. If you are adding capacity to a team, then it
> > may make sense to add kanban tokens. An availability constrained resource
> > might require adding kanban tokens. But on the whole I would always look to
> > reduce them.
> >
> > Karl
> >
> > --
> > Karl Scotland
> > Agile Coach
> > http://availagility.wordpress.com/
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Karl Scotland
> Agile Coach
> http://availagility.wordpress.com/
>
Offline 
Send Email