Primary Navigation

Re: [kanbandev] Re: A Definition of the Kanban Method

Expand Messages

Alan Dayley

I like this one!

Message 1 of 22
, Jan 3, 2010

0 Attachment

I like this one!

On Sun, Jan 3, 2010 at 5:37 PM, David Anderson <netherby_uk@...> wrote:
> Jason,
>
> Here is my third go at it. This one is a lot simpler.
>
> 1. Limit Work-in-Progress
> 2. Visualize Workflow
> 3. Make Process Policies Explicit
> 4. Pull Work only when Capacity is Available
> 5. Utilize thinking tools to recognize improvement opportunities
>
> What do you think? The list of thinking tools is explained separately as it will be an evolving list.
>
> David
>
> --- In kanbandev@yahoogroups.com, Jason Felice <jason.m.felice@...> wrote:
>>
>> What purpose is this formal definition intended to serve? The reason I ask
>> should become clear below.
>>
>> On Sat, Jan 2, 2010 at 10:54 PM, David Anderson <netherby_uk@...>wrote:
>>
>> >
>> >
>> > As I make the finishing touches to my manuscript, as my book represents the
>> > first full formal documentation, some of the reviewers have been pushing me
>> > to provide a formal definition of the Kanban approach to process
>> > improvement.
>> >
>> > So today I had to sit down and try to formulate a definition. I'd like to
>> > share it with you and solicit your feedback on it.
>> >
>> > The Kanban Method
>> > =================
>> >
>> > 1. The Kanban Method is an approach to change management
>> >
>> > 2. Kanban uses visualization of workflow
>> >
>> > 3. Kanban makes process policies explicit
>> >
>> > 4. Kanban sets a limit to work-in-progress
>> >
>> > 5. Kanban uses a virtual signaling mechanism to pull new work into the
>> > system as capacity becomes available
>> >
>> > 6. Kanban empowers team members and enables them to self-organize in
>> > a trustworthy fashion through transparency of process and visualization of
>> > work-in-progress
>> >
>> > 7. Kanban directs management focus to process definition and builds trust
>> > in the process by making policies explicit and understanding how different
>> > process elements interact
>> >
>> > 8. Kanban enables evolutionary change by exposing problems through the
>> > positive tension created by a work-in-progress limit and the transparency or
>> > process and visualization work-in-progress
>> >
>> > 9. Kanban utilizes a number of thinking tools to enable process improvement
>> > including the Theory of Constraints, an understanding of variability through
>> > the teachings of W. Edwards Deming and the concept of "muda" (waste) from
>> > the Toyota Production System
>> >
>> > 10. The number of tools used with the Kanban method is continually evolving
>> > and ideas from fields such as sociology, psychology, and risk management
>> > have been creeping into usage in recent years.
>> >
>>
>> Here is my opinion. My perspective is that of "coder grunt who happens to
>> have made process headway" rather than "someone who implements process."
>>
>> I see points 2-5 and probably 9 as being a formal definition of the
>> "operational definition" sort.
>>
>> I see point 1 as included by 2-5 and 9. It seems important, but it seems
>> more like kanban's byline than a part of the formal definition.
>>
>> I see points 6-8 not as operational definition, but as either anticipated
>> effect or marketing, depending on your perspective. Since I'm a coder grunt
>> looking for operational definition, I think the book should define 2-5 and 9
>> an make the case for 6-8 following from 2-5 and 9.
>>
>> I interpret point 10 as either a meta-statement about kanban or a cue that
>> the operational definition aspects should be rephrased to specify more
>> general characteristics of the elements for kanban (if we want that).
>> Probably the former.
>>
>> I personally would be happy with 2-5 and 9 as a formal definition, but then
>> I'm looking for an operational definition.
>>
>> And my personal nit picks: 1. Don't use "enables" as a verb when you mean
>> that it does something. 2. Strike no content phrases (e.g. "a number of" in
>> point 9) to make it more active please! E.g., a better phrasing for 9 would
>> be: "Kanban uses thinking tools like the Theory of Constraints, lean, and
>> "muda" to improve process."
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

jdn3times

Personally, I think it is about 10x times better than the original. jdn

Message 2 of 22
, Jan 3, 2010

0 Attachment

Personally, I think it is about 10x times better than the original.

jdn

--- In kanbandev@yahoogroups.com, "David Anderson" <netherby_uk@...> wrote:
>
> Jason,
>
> Here is my third go at it. This one is a lot simpler.
>
> 1. Limit Work-in-Progress
> 2. Visualize Workflow
> 3. Make Process Policies Explicit
> 4. Pull Work only when Capacity is Available
> 5. Utilize thinking tools to recognize improvement opportunities
>
> What do you think? The list of thinking tools is explained separately as it will be an evolving list.
>
> David
>
> --- In kanbandev@yahoogroups.com, Jason Felice <jason.m.felice@> wrote:
> >
> > What purpose is this formal definition intended to serve? The reason I ask
> > should become clear below.
> >
> > On Sat, Jan 2, 2010 at 10:54 PM, David Anderson <netherby_uk@>wrote:
> >
> > >
> > >
> > > As I make the finishing touches to my manuscript, as my book represents the
> > > first full formal documentation, some of the reviewers have been pushing me
> > > to provide a formal definition of the Kanban approach to process
> > > improvement.
> > >
> > > So today I had to sit down and try to formulate a definition. I'd like to
> > > share it with you and solicit your feedback on it.
> > >
> > > The Kanban Method
> > > =================
> > >
> > > 1. The Kanban Method is an approach to change management
> > >
> > > 2. Kanban uses visualization of workflow
> > >
> > > 3. Kanban makes process policies explicit
> > >
> > > 4. Kanban sets a limit to work-in-progress
> > >
> > > 5. Kanban uses a virtual signaling mechanism to pull new work into the
> > > system as capacity becomes available
> > >
> > > 6. Kanban empowers team members and enables them to self-organize in
> > > a trustworthy fashion through transparency of process and visualization of
> > > work-in-progress
> > >
> > > 7. Kanban directs management focus to process definition and builds trust
> > > in the process by making policies explicit and understanding how different
> > > process elements interact
> > >
> > > 8. Kanban enables evolutionary change by exposing problems through the
> > > positive tension created by a work-in-progress limit and the transparency or
> > > process and visualization work-in-progress
> > >
> > > 9. Kanban utilizes a number of thinking tools to enable process improvement
> > > including the Theory of Constraints, an understanding of variability through
> > > the teachings of W. Edwards Deming and the concept of "muda" (waste) from
> > > the Toyota Production System
> > >
> > > 10. The number of tools used with the Kanban method is continually evolving
> > > and ideas from fields such as sociology, psychology, and risk management
> > > have been creeping into usage in recent years.
> > >
> >
> > Here is my opinion. My perspective is that of "coder grunt who happens to
> > have made process headway" rather than "someone who implements process."
> >
> > I see points 2-5 and probably 9 as being a formal definition of the
> > "operational definition" sort.
> >
> > I see point 1 as included by 2-5 and 9. It seems important, but it seems
> > more like kanban's byline than a part of the formal definition.
> >
> > I see points 6-8 not as operational definition, but as either anticipated
> > effect or marketing, depending on your perspective. Since I'm a coder grunt
> > looking for operational definition, I think the book should define 2-5 and 9
> > an make the case for 6-8 following from 2-5 and 9.
> >
> > I interpret point 10 as either a meta-statement about kanban or a cue that
> > the operational definition aspects should be rephrased to specify more
> > general characteristics of the elements for kanban (if we want that).
> > Probably the former.
> >
> > I personally would be happy with 2-5 and 9 as a formal definition, but then
> > I'm looking for an operational definition.
> >
> > And my personal nit picks: 1. Don't use "enables" as a verb when you mean
> > that it does something. 2. Strike no content phrases (e.g. "a number of" in
> > point 9) to make it more active please! E.g., a better phrasing for 9 would
> > be: "Kanban uses thinking tools like the Theory of Constraints, lean, and
> > "muda" to improve process."
> >
>

Siraj Sirajuddin

Hi David - What i (knew all along and ) learned from our Kanban class (SFO / Nov 2009) is that It is all about policies ! I would say make #3 (below) as #1.

Message 3 of 22
, Jan 3, 2010

0 Attachment

Hi David -

What i (knew all along and ) learned from our Kanban class (SFO / Nov 2009) is that "It is all about policies"! I would say make #3 (below) as #1.

The more I work with teams, the more this lesson is becoming clearer and clearer.

What do you think? The list of thinking tools is explained separately as it will be an evolving list.

David

--- In kanbandev@yahoogrou ps.com, Jason Felice <jason.m.felice@ ...> wrote:
>
> What purpose is this formal definition intended to serve? The reason I ask
> should become clear below.
>
> On Sat, Jan 2, 2010 at 10:54 PM, David Anderson <netherby_uk@ ...>wrote:
>
> >
> >
> > As I make the finishing touches to my manuscript, as my book represents the
> > first full formal documentation, some of the reviewers have been pushing me
> > to provide a formal definition of the Kanban approach to process
> > improvement.
> >
> > So today I had to sit down and try to formulate a definition. I'd like to
> > share it with you and solicit your feedback on it.
> >
> > The Kanban Method
> > ============ =====
> >
> > 1. The Kanban Method is an approach to change management
> >
> > 2. Kanban uses visualization of workflow
> >
> > 3. Kanban makes process policies explicit
> >
> > 4. Kanban sets a limit to work-in-progress
> >
> > 5. Kanban uses a virtual signaling mechanism to pull new work into the
> > system as capacity becomes available
> >
> > 6. Kanban empowers team members and enables them to self-organize in
> > a trustworthy fashion through transparency of process and visualization of
> > work-in-progress
> >
> > 7. Kanban directs management focus to process definition and builds trust
> > in the process by making policies explicit and understanding how different
> > process elements interact
> >
> > 8. Kanban enables evolutionary change by exposing problems through the
> > positive tension created by a work-in-progress limit and the transparency or
> > process and visualization work-in-progress
> >
> > 9. Kanban utilizes a number of thinking tools to enable process improvement
> > including the Theory of Constraints, an understanding of variability through
> > the teachings of W. Edwards Deming and the concept of "muda" (waste) from
> > the Toyota Production System
> >
> > 10. The number of tools used with the Kanban method is continually evolving
> > and ideas from fields such as sociology, psychology, and risk management
> > have been creeping into usage in recent years.
> >
>
> Here is my opinion. My perspective is that of "coder grunt who happens to
> have made process headway" rather than "someone who implements process."
>
> I see points 2-5 and probably 9 as being a formal definition of the
> "operational definition" sort.
>
> I see point 1 as included by 2-5 and 9. It seems important, but it seems
> more like kanban's byline than a part of the formal definition.
>
> I see points 6-8 not as operational definition, but as either anticipated
> effect or marketing, depending on your perspective. Since I'm a coder grunt
> looking for operational definition, I think the book should define 2-5 and 9
> an make the case for 6-8 following from 2-5 and 9.
>
> I interpret point 10 as either a meta-statement about kanban or a cue that
> the operational definition aspects should be rephrased to specify more
> general characteristics of the elements for kanban (if we want that).
> Probably the former.
>
> I personally would be happy with 2-5 and 9 as a formal definition, but then
> I'm looking for an operational definition.
>
> And my personal nit picks: 1. Don't use "enables" as a verb when you mean
> that it does something. 2. Strike no content phrases (e.g. "a number of" in
> point 9) to make it more active please! E.g., a better phrasing for 9 would
> be: "Kanban uses thinking tools like the Theory of Constraints, lean, and
> "muda" to improve process."
>

What do you think? The list of thinking tools is explained separately as it will be an evolving list.

Works for me!

David Anderson

Here is my latest take on it including some additional themes. Pull has also been removed following feedback on a private email thread suggesting it was a

Message 5 of 22
, Jan 3, 2010

0 Attachment

Here is my latest take on it including some additional themes. Pull has also been removed following feedback on a private email thread suggesting it was a side-effect of limiting WIP and the nuance of pull versus limited WIP didn't need to be exposed at the top level.

As for ordering I could go either way on it. Any of the top 5 could be implemented first. All 5 could be implemented together.

The community web site is limitedwipsociety.org and it seems to me that the core essence is limiting WIP and it is this that differentiates Kanban from ideas that came before it. So I am sticking with Limit WIP as #1.

This list of 8 now sounds a bit too _Mary Poppendieck_ to me - maybe that can't be helped. ;-)

Re-reading the full list I do feel it captures the essence of Kanban. Is there anything else missing?

And once more... This time I am separating the definition into 5 Core Properties (of a Kanban implementation) and 5 Emergent Properties. The 5 core properties

Message 6 of 22
, Jan 3, 2010

0 Attachment

And once more... This time I am separating the definition into 5 Core Properties (of a Kanban implementation) and 5 Emergent Properties.

The 5 core properties were all present in the original XIT implementation in 2004. The 5 Emergent Properties all appeared at Corbis during 2007. Together all 10 represent the content of the forthcoming book.

*Common models in use with Kanban include the Theory of Constraints, Systems Thinking, an understanding of variability through the teachings of W. Edwards Deming and the concept of "muda" (waste) from the Toyota Production System. The models used with Kanban are continually evolving and ideas from other such as sociology, psychology, and risk management have been used already with some implementations.

This new definition is also word-for-word compatible with the 3 point definition that Henrik Kniberg & Mattias Skarin published in their "Scrum and Kanban" book.

--- In kanbandev@yahoogroups.com, "David Anderson" <netherby_uk@...> wrote:
>
> Here is my latest take on it including some additional themes. Pull has also been removed following feedback on a private email thread suggesting it was a side-effect of limiting WIP and the nuance of pull versus limited WIP didn't need to be exposed at the top level.
>
> 1 Limit Work-in-Progress
> 2 Visualize Workflow
> 3 Make Process Policies Explicit
> 4 Prioritize Work by Cost of Delay
> 5 Spread Risk with Capacity Allocation
> 6 Use Data to Align Behavior with Economic Outcomes
> 7 Encourage a System Level Understanding
> 8 Use Models to Recognize Improvement Opportunities*
>

I'm trying to map these onto what I've been calling my 5 Primary Practices. To recap:

1. Map the Value Stream

2. Visualise the Value Stream

3. Limit WIP

4. Establish a Cadence

5. Reduce the Kanban Tokens

My 3 is your 1, and my 2 is your 2, so we agree there :) I think my 4 is type of policy, so maps onto your 4, which I like. Would you agree? That leaves my 1, which seems to relate to your 3 in terms of understanding the overall flow, and my 5, which I think relates to your 5 in terms of improvement,

What I'm not sure about with your list of core practices is what you see the difference is between your 3 and 5 - measuring and optimizing flow, and managing quantitatively. So I'm wondering whether 3 and 5 need some tweaking?

And once more... This time I am separating the definition into 5 Core Properties (of a Kanban implementation) and 5 Emergent Properties.

The 5 core properties were all present in the original XIT implementation in 2004. The 5 Emergent Properties all appeared at Corbis during 2007. Together all 10 represent the content of the forthcoming book.

*Common models in use with Kanban include the Theory of Constraints, Systems Thinking, an understanding of variability through the teachings of W. Edwards Deming and the concept of "muda" (waste) from the Toyota Production System. The models used with Kanban are continually evolving and ideas from other such as sociology, psychology, and risk management have been used already with some implementations.

This new definition is also word-for-word compatible with the 3 point definition that Henrik Kniberg & Mattias Skarin published in their "Scrum and Kanban" book.

> Here is my latest take on it including some additional themes. Pull has also been removed following feedback on a private email thread suggesting it was a side-effect of limiting WIP and the nuance of pull versus limited WIP didn't need to be exposed at the top level.>
> 1 Limit Work-in-Progress
> 2 Visualize Workflow
> 3 Make Process Policies Explicit
> 4 Prioritize Work by Cost of Delay
> 5 Spread Risk with Capacity Allocation
> 6 Use Data to Align Behavior with Economic Outcomes
> 7 Encourage a System Level Understanding
> 8 Use Models to Recognize Improvement Opportunities*
>

David, Great stuff. Thank you for putting this together. One thing I did want to inquire about and have noticed in this groups discussions in general is a

Message 8 of 22
, Jan 4, 2010

0 Attachment

David,

Great stuff. Thank you for putting this together. One thing I did want to inquire about and have noticed in this groups discussions in general is a distancing from the language and lean principle of eliminating waste or "Muda." The list you have includes "optimizing flow" and "optimizing value" and "improvement opportunities." To optimize and improve to me are done by eliminating waste. Either by changing the way we do work or stopping doing something that is creating an inefficiency. But "eliminating waste" is visceral and you know you're only done when there is no more waste. This being the lean idea of "Perfection." To me, these are Muda is a stronger word that people more easily understand. Is this language shift intentional/conscious? And if so, what's driving it?

Thanks,

-greg

--- In kanbandev@yahoogroups.com, "David Anderson" <netherby_uk@...> wrote:
>
> And once more... This time I am separating the definition into 5 Core Properties (of a Kanban implementation) and 5 Emergent Properties.
>
> The 5 core properties were all present in the original XIT implementation in 2004. The 5 Emergent Properties all appeared at Corbis during 2007. Together all 10 represent the content of the forthcoming book.
>
> Kanban
>
> There are 5 core properties to a Kanban implementation
>
> 1. Limit Work-in-Progress
> 2. Visualize Workflow
> 3. Measure & Optimize Flow
> 4. Make Process Policies Explicit
> 5. Manage Quantitatively
>
> There at least 5 emergent properties we might expect in a Kanban implementation
>
> 1. Prioritize Work by Cost of Delay
> 2. Optimize Value with Classes of Service
> 3. Spread Risk with Capacity Allocation
> 4. Encourage Process Innovation
> 5. Use Models* to Recognize Improvement Opportunities
>
> *Common models in use with Kanban include the Theory of Constraints, Systems Thinking, an understanding of variability through the teachings of W. Edwards Deming and the concept of "muda" (waste) from the Toyota Production System. The models used with Kanban are continually evolving and ideas from other such as sociology, psychology, and risk management have been used already with some implementations.
>
> This new definition is also word-for-word compatible with the 3 point definition that Henrik Kniberg & Mattias Skarin published in their "Scrum and Kanban" book.
>
> David
> http://www.channelkanban.com/
>
>
> --- In kanbandev@yahoogroups.com, "David Anderson" <netherby_uk@> wrote:
> >
> > Here is my latest take on it including some additional themes. Pull has also been removed following feedback on a private email thread suggesting it was a side-effect of limiting WIP and the nuance of pull versus limited WIP didn't need to be exposed at the top level.
> >
> > 1 Limit Work-in-Progress
> > 2 Visualize Workflow
> > 3 Make Process Policies Explicit
> > 4 Prioritize Work by Cost of Delay
> > 5 Spread Risk with Capacity Allocation
> > 6 Use Data to Align Behavior with Economic Outcomes
> > 7 Encourage a System Level Understanding
> > 8 Use Models to Recognize Improvement Opportunities*
> >
>

David Anderson

Greg, Yes, I have been deliberately distancing my work from the use of Japanese terms, specific references to Toyota (or TPS) and a focus on muda waste.

Message 9 of 22
, Jan 4, 2010

0 Attachment

Greg,

Yes, I have been deliberately distancing my work from the use of Japanese terms, specific references to Toyota (or TPS) and a focus on "muda" waste. This has been discussed at some length here in the past so I don't want to bore people with repetition.

Firstly, the Japanese terms. I've been pursuing a path of using plain language or language that is less domain specific and in more general usage such as the language of economics. I am doing this to broaden the appeal of the techniques and to reduce the tendency towards tribalism and dogma that goes with arcane language. I am trying to demystify this field. There may be many reading this who will not like this trend. They like to show off how many TPS or Lean books they have read and how many Japanese terms they can throw into a conversation. They want to be a big fish swimming in a small echo chamber ;-) if you will excuse the mixed metaphor. It is common for professions to encourage use of arcane language in order to protect their source of revenue. By making something mystical, the uninitiated feel the need to pay consulting fees to delegate the task. This is common with legal profession for example who have made a good job of insuring we pay fees for common activities like home purchase and divorce that may actually be reasonably performed ourselves.

I happen to feel this strategy of protecting the profession with arcane language is a barrier to wider adoption. I am therefore eliminating.

In addition, I feel the overly heavy borrowing from TPS language and its Japanese terms has proven a hindrance to adoption of Lean software engineering solutions. We get too hung up on analogous mapping to manufacturing practices and we lose sight of the principles and forget to apply the principles in context.

Additionally, it is evident from posts on this list and from people attending Kanban training classes that about half of the audience have trouble classifying non-value-added activities as "waste."

So I have adopted the language of "economic costs" and find that this is working much better.

I am concluding the authoring of a 76,000 word book on the Kanban Method. Apart from use of "kanban" which is explained literally early in the text and used more like a brand throughout the remainder, and "kaizen" which is referred to from time to time as it is shorter than "continuous improvement," there are really no uses of Japanese terms and no attempt to map to any of the manufacturing literature.

The Japanese didn't invent the principles behind TPS/Lean (JIT and Profound Knowledge) though they did apply their "kanban" approach of using physical cards to control a capacity to the principles and what popped out was TPS as we now know it.

Software development is a different domain. We need to get past trying to copy the Japanese. The Japanese themselves have made little progress in adapting TPS to software development. There is nothing to copy. We need to work from first principles and derive our own sets of common practices and our own language to describe these.

I want that language to be as simple to understand as possible and it to result in the widest adoption imaginable.

--- In kanbandev@yahoogroups.com, "gregc" <greg@...> wrote:
>
> David,
>
> Great stuff. Thank you for putting this together. One thing I did want to inquire about and have noticed in this groups discussions in general is a distancing from the language and lean principle of eliminating waste or "Muda." The list you have includes "optimizing flow" and "optimizing value" and "improvement opportunities." To optimize and improve to me are done by eliminating waste. Either by changing the way we do work or stopping doing something that is creating an inefficiency. But "eliminating waste" is visceral and you know you're only done when there is no more waste. This being the lean idea of "Perfection." To me, these are Muda is a stronger word that people more easily understand. Is this language shift intentional/conscious? And if so, what's driving it?
>
> Thanks,
>
> -greg
>
>

David Anderson

Karl, You are making me recognize that Manage & Optimize Flow needs adjustment. I used it because Henrik published it and it seemed correct. However, Value

Message 10 of 22
, Jan 4, 2010

0 Attachment

Karl,

You are making me recognize that "Manage & Optimize Flow" needs adjustment. I used it because Henrik published it and it seemed correct. However, Value trumps Flow, and Flow trumps Waste Elimination. So we don't optimize flow in all circumstances. We optimize the economic outcome balanced against risk. However, this is an advanced topic. There will be plenty of kanban systems in use where the economic outcome is not being optimized nor is risk being addressed adequately.

I now prefer "Manage Flow".

"Manage Quantitatively" refers to using objective data to make decisions, to get beyond mere anecdote and subjectivity.

Your "Cadence" line is interesting. Cadence is actually optional. Cadence is a coordination strategy that also has a psychological and sociological benefit. However, the need for cadence is contextual. It could be considered an Emergent Property and I need to give it further thought as to whether it is required in the second list. I do agree that cadence is a process policy.

And once more... This time I am separating the definition into 5 Core Properties (of a Kanban implementation) and 5 Emergent Properties.

The 5 core properties were all present in the original XIT implementation in 2004. The 5 Emergent Properties all appeared at Corbis during 2007. Together all 10 represent the content of the forthcoming book.

*Common models in use with Kanban include the Theory of Constraints, Systems Thinking, an understanding of variability through the teachings of W. Edwards Deming and the concept of "muda" (waste) from the Toyota Production System. The models used with Kanban are continually evolving and ideas from other such as sociology, psychology, and risk management have been used already with some implementations.

This new definition is also word-for-word compatible with the 3 point definition that Henrik Kniberg & Mattias Skarin published in their "Scrum and Kanban" book.

...

Karl Scotland

2010/1/5 David Anderson ... That s better, but how is Manage Flow different from visualising the Value Stream and setting WIP

You are making me recognize that "Manage & Optimize Flow" needs adjustment. I used it because Henrik published it and it seemed correct. However, Value trumps Flow, and Flow trumps Waste Elimination. So we don't optimize flow in all circumstances. We optimize the economic outcome balanced against risk. However, this is an advanced topic. There will be plenty of kanban systems in use where the economic outcome is not being optimized nor is risk being addressed adequately.

I now prefer "Manage Flow".

That's better, but how is "Manage Flow" different from visualising the Value Stream and setting WIP limits? Are they not ways of managing flow? How about "Recognise" or "Pay Attention To"?

"Manage Quantitatively" refers to using objective data to make decisions, to get beyond mere anecdote and subjectivity.

Your "Cadence" line is interesting. Cadence is actually optional. Cadence is a coordination strategy that also has a psychological and sociological benefit. However, the need for cadence is contextual. It could be considered an Emergent Property and I need to give it further thought as to whether it is required in the second list. I do agree that cadence is a process policy.

I'd agree cadence is optional, in the sense that establishing a cadence could mean establishing a lack of cadence! I find that talking about cadence eases concerns about losing time-boxes.

And once more... This time I am separating the definition into 5 Core Properties (of a Kanban implementation) and 5 Emergent Properties.

The 5 core properties were all present in the original XIT implementation in 2004. The 5 Emergent Properties all appeared at Corbis during 2007. Together all 10 represent the content of the forthcoming book.

*Common models in use with Kanban include the Theory of Constraints, Systems Thinking, an understanding of variability through the teachings of W. Edwards Deming and the concept of "muda" (waste) from the Toyota Production System. The models used with Kanban are continually evolving and ideas from other such as sociology, psychology, and risk management have been used already with some implementations.

This new definition is also word-for-word compatible with the 3 point definition that Henrik Kniberg & Mattias Skarin published in their "Scrum and Kanban" book.

And once more... This time I am separating the definition into 5 Core Properties (of a Kanban implementation) and 5 Emergent Properties.

The 5 core properties were all present in the original XIT implementation in 2004. The 5 Emergent Properties all appeared at Corbis during 2007. Together all 10 represent the content of the forthcoming book.

*Common models in use with Kanban include the Theory of Constraints, Systems Thinking, an understanding of variability through the teachings of W. Edwards Deming and the concept of "muda" (waste) from the Toyota Production System. The models used with Kanban are continually evolving and ideas from other such as sociology, psychology, and risk management have been used already with some implementations.

This new definition is also word-for-word compatible with the 3 point definition that Henrik Kniberg & Mattias Skarin published in their "Scrum and Kanban" book.

...

Christophe Louvion

When explaining new employees how we make decisions in my company, I tell them we make data driven decisions (rather than responding to anecdotes).

Message 15 of 22
, Jan 5, 2010

0 Attachment

When explaining new employees how we make decisions in my company, I
tell them we make "data driven decisions" (rather than responding to
anecdotes).

>
> In addition, I feel the overly heavy borrowing from TPS language and its Japanese terms has proven a hindrance to adoption of Lean software engineering solutions. We get too hung up on analogous mapping to manufacturing practices and we lose sight of the principles and forget to apply the principles in context.
>
> Additionally, it is evident from posts on this list and from people attending Kanban training classes that about half of the audience have trouble classifying non-value-added activities as "waste."
>
> So I have adopted the language of "economic costs" and find that this is working much better.

wouldn't it be helpful to explicitly state the emergent property "Strive to Reduce Batch Size", I belive this often is a highly visible effect in the community and the implementations I've seen and heard about.

Because it basically supports all other objectives by reducing queues, variability and risk.

You are making me recognize that "Manage & Optimize Flow" needs adjustment. I used it because Henrik published it and it seemed correct. However, Value trumps Flow, and Flow trumps Waste Elimination. So we don't optimize flow in all circumstances. We optimize the economic outcome balanced against risk. However, this is an advanced topic. There will be plenty of kanban systems in use where the economic outcome is not being optimized nor is risk being addressed adequately.

I now prefer "Manage Flow".

That's better, but how is "Manage Flow" different from visualising the Value Stream and setting WIP limits? Are they not ways of managing flow? How about "Recognise" or "Pay Attention To"?

"Manage Quantitatively" refers to using objective data to make decisions, to get beyond mere anecdote and subjectivity.

Your "Cadence" line is interesting. Cadence is actually optional. Cadence is a coordination strategy that also has a psychological and sociological benefit. However, the need for cadence is contextual. It could be considered an Emergent Property and I need to give it further thought as to whether it is required in the second list. I do agree that cadence is a process policy.

I'd agree cadence is optional, in the sense that establishing a cadence could mean establishing a lack of cadence! I find that talking about cadence eases concerns about losing time-boxes.