Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Alan Dayley
    I like this one!
    Message 1 of 22 , Jan 3, 2010
    View Source
    • 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
      View Source
      • 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
        View Source
        • 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. 

          Best wishes and see you soon
          Siraj 








          On Jan 3, 2010, at 7:37 PM, David Anderson 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@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."
          >


        • Jason Felice
          ... Works for me!
          Message 4 of 22 , Jan 3, 2010
          View Source
          • 0 Attachment
            On Sun, Jan 3, 2010 at 7: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.

            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
            View Source
            • 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.

              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*

              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?

              David


              --- In kanbandev@yahoogroups.com, "jdn3times" <jdn3times@...> wrote:
              >
              > 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."
              > > >
              > >
              >
            • David Anderson
              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
              View Source
              • 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.

                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*
                >
              • Karl Scotland
                Hi David, 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
                Message 7 of 22 , Jan 4, 2010
                View Source
                • 0 Attachment
                  Hi David,

                  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?

                  I like the general split between core and emergent properties though.

                  Karl

                  2010/1/4 David Anderson <netherby_uk@...>
                  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.
                  --- 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*
                  >




                  ------------------------------------

                  Yahoo! Groups Links

                  <*> To visit your group on the web, go to:
                     http://groups.yahoo.com/group/kanbandev/

                  <*> Your email settings:
                     Individual Email | Traditional

                  <*> To change settings online go to:
                     http://groups.yahoo.com/group/kanbandev/join
                     (Yahoo! ID required)

                  <*> To change settings via email:
                     kanbandev-digest@yahoogroups.com
                     kanbandev-fullfeatured@yahoogroups.com

                  <*> To unsubscribe from this group, send an email to:
                     kanbandev-unsubscribe@yahoogroups.com

                  <*> Your use of Yahoo! Groups is subject to:
                     http://docs.yahoo.com/info/terms/




                  --
                  Karl Scotland
                  Lean & Agile Coach
                  http://www.availagility.co.uk/
                • gregc
                  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
                  View Source
                  • 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
                    View Source
                    • 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.

                      Regards,
                      David
                      http://www.channelkanban.com/

                      --- 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
                      View Source
                      • 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.

                        Did this help?

                        David

                        --- In kanbandev@yahoogroups.com, Karl Scotland <kjscotland@...> wrote:
                        >
                        > Hi David,
                        >
                        > 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?
                        >
                        > I like the general split between core and emergent properties though.
                        >
                        > Karl
                        >
                        > 2010/1/4 David Anderson <netherby_uk@...>
                        >
                        > > 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*
                        > > >
                        > >
                        > >
                        > >
                        > >
                        > > ------------------------------------
                        > >
                        > > Yahoo! Groups Links
                        > >
                        > >
                        > >
                        > >
                        >
                        >
                        > --
                        > Karl Scotland
                        > Lean & Agile Coach
                        > http://www.availagility.co.uk/
                        >
                      • Norbert Winklareth
                        +1 and looking forward to the handling of Flow trumps waste mods. -- Regards Norbert ... Norbert Winklareth Agile Renaissance
                        Message 11 of 22 , Jan 5, 2010
                        View Source
                        • 0 Attachment
                          +1 and looking forward to the handling of Flow trumps waste mods.

                          -- 
                          Regards
                          Norbert
                          -----
                          Norbert Winklareth
                          Agile Renaissance

                          On Mon, Jan 4, 2010 at 1:42 AM, 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.
                          ...

                        • Karl Scotland
                          2010/1/5 David Anderson ... That s better, but how is Manage Flow different from visualising the Value Stream and setting WIP
                          Message 12 of 22 , Jan 5, 2010
                          View Source
                          • 0 Attachment
                            2010/1/5 David Anderson <netherby_uk@...>

                            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.

                            I'm unsure whether quantitative management is a core practice. Its certainly something Kanban places more emphasis on, but core? 
                             
                            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.
                             
                            Did this help?

                            More importantly, does it help you ;-) 

                            Karl

                            --
                            Karl Scotland
                            Lean & Agile Coach
                            http://www.availagility.co.uk/
                          • John Goodsen
                            Manage Quantitatively still seems a little vague - could it be re-phrased as something a little more concrete? -- John Goodsen RADSoft /
                            Message 13 of 22 , Jan 5, 2010
                            View Source
                            • 0 Attachment
                              "Manage Quantitatively" still seems a little vague - could it be re-phrased as something a little more concrete?

                              --
                              John Goodsen                 RADSoft / Better Software Faster
                              jgoodsen@...            Lean/Agile/XP/Scrum Coaching and Training
                              http://www.radsoft.com          Ruby on Rails and Java Solutions

                              On Tue, Jan 5, 2010 at 9:47 AM, Norbert Winklareth <borkofnick@...> wrote:


                              +1 and looking forward to the handling of Flow trumps waste mods.

                              -- 
                              Regards
                              Norbert
                              -----
                              Norbert Winklareth
                              Agile Renaissance

                              On Mon, Jan 4, 2010 at 1:42 AM, 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.
                              ...




                            • Mike Burrows
                              Manage (reduce) the cost of delay? Mike mjb@asplake.co.uk http://positiveincline.com http://twitter.com/asplake 2010/1/5 John Goodsen
                              Message 14 of 22 , Jan 5, 2010
                              View Source
                              • 0 Attachment
                                Manage (reduce) the cost of delay?

                                Mike
                                mjb@...
                                http://positiveincline.com
                                http://twitter.com/asplake


                                2010/1/5 John Goodsen <jgoodsen@...>
                                 

                                "Manage Quantitatively" still seems a little vague - could it be re-phrased as something a little more concrete?

                                --
                                John Goodsen                 RADSoft / Better Software Faster
                                jgoodsen@...            Lean/Agile/XP/Scrum Coaching and Training
                                http://www.radsoft.com          Ruby on Rails and Java Solutions



                                On Tue, Jan 5, 2010 at 9:47 AM, Norbert Winklareth <borkofnick@...> wrote:


                                +1 and looking forward to the handling of Flow trumps waste mods.

                                -- 
                                Regards
                                Norbert
                                -----
                                Norbert Winklareth
                                Agile Renaissance

                                On Mon, Jan 4, 2010 at 1:42 AM, 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.
                                ...





                              • 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
                                View Source
                                • 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).



                                  John Goodsen wrote:
                                  >
                                  > "Manage Quantitatively" still seems a little vague - could it be
                                  > re-phrased as something a little more concrete?
                                  >
                                  > --
                                  > John Goodsen RADSoft / Better Software Faster
                                  > jgoodsen@... <mailto:jgoodsen@...> Lean/Agile/XP/Scrum
                                  > Coaching and Training
                                  > http://www.radsoft.com <http://www.radsoft.com> Ruby on Rails and Java
                                  > Solutions
                                  >
                                  > On Tue, Jan 5, 2010 at 9:47 AM, Norbert Winklareth
                                  > <borkofnick@... <mailto:borkofnick@...>> wrote:
                                  >
                                  >
                                  >
                                  > +1 and looking forward to the handling of Flow trumps waste mods.
                                  >
                                  > --
                                  > Regards
                                  > Norbert
                                  > -----
                                  > Norbert Winklareth
                                  > Agile Renaissance
                                  >
                                  > On Mon, Jan 4, 2010 at 1:42 AM, David Anderson
                                  > <netherby_uk@... <mailto: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.
                                  > ...
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                • jdn3times
                                  ... ... +500 jdn
                                  Message 16 of 22 , Jan 5, 2010
                                  View Source
                                  • 0 Attachment
                                    --- In kanbandev@yahoogroups.com, "David Anderson" <netherby_uk@...> wrote:
                                    >
                                    > Greg,
                                    >
                                    <snip>
                                    >
                                    > 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.

                                    +500

                                    jdn
                                  • Torbjörn Gyllebring
                                    I might be missing something obvious here, so bear with me :) Given: 1: Limit WIP 3: Manage (& Optmize) Flow and Value over Flow, Flow over Waste Reduction
                                    Message 17 of 22 , Jan 5, 2010
                                    View Source
                                    • 0 Attachment
                                      I might be missing something obvious here, so bear with me :)

                                      Given:

                                      1: Limit WIP
                                      3: Manage (& Optmize) Flow
                                      and Value over Flow, Flow over Waste Reduction 

                                      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.

                                      - Torbjörn


                                      On Tue, Jan 5, 2010 at 5:21 PM, Karl Scotland <kjscotland@...> wrote:

                                      2010/1/5 David Anderson <netherby_uk@...>


                                      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.

                                      I'm unsure whether quantitative management is a core practice. Its certainly something Kanban places more emphasis on, but core? 
                                       
                                      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.
                                       
                                      Did this help?

                                      More importantly, does it help you ;-) 

                                      Karl

                                      --
                                      Karl Scotland
                                      Lean & Agile Coach
                                      http://www.availagility.co.uk/


                                    Your message has been successfully submitted and would be delivered to recipients shortly.