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

Re: [XP] Lean failure at Toyota

Expand Messages
  • Michael KENNY
    ... or Toyota is/was successful Toyota has a Lean production system Lean equals success Michael
    Message 1 of 29 , Feb 1, 2010
    • 0 Attachment
      On Sun, 31 Jan 2010 09:58:31 -0800, you wrote:

      >I'm not an expert on fallacies, but I'm sure a rhetoric professor could use
      >the press surrounding this incident and the comments from the lean
      >proponents and detractors as an exercise in rooting them out.

      >For example, non sequitur:
      >
      >Toyota is a lean manufacturer
      >Toyota allowed a defective part to reach the customer
      >Lean doesn't work
      or
      Toyota is/was successful
      Toyota has a Lean production system
      Lean equals success

      Michael
    • Michael KENNY
      The reactions here sofar find no fault with Lean; either Toyota forgot about Lean, or the whole incident and especially its handling is an example of Lean.
      Message 2 of 29 , Feb 1, 2010
      • 0 Attachment
        The reactions here sofar find no fault with Lean; either Toyota forgot
        about Lean, or the whole incident and especially its handling is an
        example of Lean.

        When agile projects fail, you often hear it wasn't really agile, or
        not agile enough.

        Is there a blindspot here, are agile and Lean always beyond doubt?

        What evidence would there need to be for a team to say Lean or agile
        doesn't work for us?

        Michael
      • Tim Ottinger
        I think the problem is that success is rare, mysterious (having no reliable recipe), and probably multicausal. Failure is not the result of wrongdoing
        Message 3 of 29 , Feb 1, 2010
        • 0 Attachment
          I think the problem is that success is rare, mysterious (having no reliable recipe), and probably multicausal. Failure is not the result of wrongdoing necessarily, but is the natural state. Most businesses fail, most fail before becoming well-known, and many fail after being fabulously successful. We forget that failure is the default, and success is the outlier that needs explaining. Indeed, all our work in any field of endeavor is not really competing against others so much as competing against the default.

          As such, it is hard to consider any process to be necessarily "the" cause for any success or any failure. Waterfall has well-known failure modes due to increasing cost of change v. increasing irrelevance of requirements & design. Agile combats that.American-style manufacturing and pre-lean Asian style manufacturing has known failure modes that are addressed by Lean. So when we use XP and/or Lean methods, we should fail differently. Nonetheless, failure unrelentingly stalks us all.

          That we have as many successes as we have is astounding, but cannot be necessarily attributed merely to lean or agile methods, nor merely to leadership, nor merely to craftsmanship.

          Tim Ottinger
          http://agileinaflash.blogspot.com/
          http://agileotter.blogspot.com/
        • Victor
          ... I would say this is not a good question. Perfection does not exist and absolutes are not conducive to good results. A better question might be: Is there
          Message 4 of 29 , Feb 1, 2010
          • 0 Attachment
            > What evidence would there need to be for a team to say Lean or agile
            > doesn't work for us?

            I would say this is not a good question. Perfection does not exist and
            absolutes are not conducive to good results.

            A better question might be: Is there a better methodology?

            Victor

            ===========================

            ----- Original Message -----
            From: "Michael KENNY" <kenny@...>
            To: <extremeprogramming@yahoogroups.com>
            Sent: Monday, February 01, 2010 8:42 AM
            Subject: Re: [XP] Lean failure at Toyota


            > The reactions here sofar find no fault with Lean; either Toyota forgot
            > about Lean, or the whole incident and especially its handling is an
            > example of Lean.
            >
            > When agile projects fail, you often hear it wasn't really agile, or
            > not agile enough.
            >
            > Is there a blindspot here, are agile and Lean always beyond doubt?
            >
            > What evidence would there need to be for a team to say Lean or agile
            > doesn't work for us?
            >
            > Michael
            >
            >
            > ------------------------------------
            >
            > To Post a message, send it to: extremeprogramming@...
            >
            > To Unsubscribe, send a blank message to:
            > extremeprogramming-unsubscribe@...
            >
            > ad-free courtesy of objectmentor.comYahoo! Groups Links
            >
            >
            >
            >
          • Ron Jeffries
            Hello, Victor. On Monday, February 1, 2010, at 9:08:31 AM, you ... When you say better methodology , what do you mean? For that matter, when you say better
            Message 5 of 29 , Feb 1, 2010
            • 0 Attachment
              Hello, Victor. On Monday, February 1, 2010, at 9:08:31 AM, you
              wrote:

              > A better question might be: Is there a better methodology?

              When you say "better methodology", what do you mean?

              For that matter, when you say "better question", what do you mean?

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              Sorry about your cow ... I didn't know she was sacred.
            • Tim Ottinger
              ... Sure. If it had a failure mode that agile methods should prevent, then it probably wasn t agile enough. If it was in a way that an agile method does not
              Message 6 of 29 , Feb 1, 2010
              • 0 Attachment
                > When agile projects fail, you often hear it wasn't really agile, or
                > not agile enough.

                Sure. If it had a failure mode that agile methods should prevent,
                then it probably wasn't agile enough. If it was in a way that an
                agile method does not address then it isn't a failure of Agile,
                but from some other cause.

                >
                > Is there a blindspot here, are agile and Lean always beyond doubt?

                There is always room for something better, if we can find something
                better. Before agile, we all tried different ways, and changed when
                agile methods came along. Expect the same for whatever is next, but
                not when people resurrect the old waterfall ways as an "improvement"
                over agile, because we've been there.

                > What evidence would there need to be for a team to say Lean or agile
                > doesn't work for us?

                That they cannot implement agile in their context after giving it a
                fair shot and using competent coaches. If you can't implement it,
                it doesn't work for you.

                Otherwise, we need to find failure modes that consistently arise
                because of the use of agile methods. Are certain failures in
                certain contexts agile-caused? We don't know that they are. So far,
                we see those that are not agile-prevented -- and failure is multi-
                causal.
              • Bill Caputo
                ... What evidence would say they do? IMO, its the wrong question. The issue for those of us who think a lot about software process and how to be successful at
                Message 7 of 29 , Feb 1, 2010
                • 0 Attachment
                  On Mon, Feb 1, 2010 at 7:42 AM, Michael KENNY <kenny@...> wrote:
                  > What evidence would there need to be for a team to say Lean or agile
                  > doesn't work for us?

                  What evidence would say they do? IMO, its the wrong question. The
                  issue for those of us who think a lot about software process and how
                  to be successful at delivering software, and so forth is more
                  fundamental. Tim's got the right idea: Success is rare. More
                  specifically, success is a number between 0 and 100 and for most
                  endeavors just being slightly above the norm will result in huge
                  gains.

                  Kent's been blogging a good bit about poker and how its shaping his
                  thinking. I've been playing poker very actively this past year as
                  well, and one thing its taught me is that binary notions of win/lose,
                  pass/fail, success/fail are fine in chess, math and other precise
                  activities (like coding) where complete information is possible (in a
                  narrow context) but most activities live in contexts that require a
                  probabilistic definition of success and so a strategy that increases
                  one's chances to a positive expectation is successful, improvement is
                  looking for ways to improve a point or two and no strategy will get
                  you to 100% or even close, the vast majority won't get to 50%.

                  We keep making the mistake that a methodology (a practice, a value, a
                  language, a book, a tool, etc) is going to provide, or be the basis
                  for, or an element of a formula that makes success a certainty, and so
                  when we see a failure it must be because the item in question was
                  misused or abandoned. Lean isn't a formula for success any more than
                  Agile was; both might help improve EV by some number of points (at
                  best) assuming the other factors in a given context don't dwarf their
                  effects (something not at all clear IMHO).

                  As to the fallacy? Its in the assumption that one can be doing
                  lean/agile/tdd perfectly and not still fail. Code and mechanical
                  engineering might be closer to Math and Physics, but software delivery
                  (and manufacturing cars) are more like Biology or Economics.

                  Best,
                  Bill
                • Ron Jeffries
                  Hello, Bill. On Monday, February 1, 2010, at 9:29:10 AM, you ... Yes. Perfection is not given to us. We cannot do anything complex perfectly (nor, probably,
                  Message 8 of 29 , Feb 1, 2010
                  • 0 Attachment
                    Hello, Bill. On Monday, February 1, 2010, at 9:29:10 AM, you
                    wrote:

                    > As to the fallacy? Its in the assumption that one can be doing
                    > lean/agile/tdd perfectly and not still fail. Code and mechanical
                    > engineering might be closer to Math and Physics, but software delivery
                    > (and manufacturing cars) are more like Biology or Economics.

                    Yes. Perfection is not given to us. We cannot do anything complex
                    perfectly (nor, probably, even anything simple). If we did by chance
                    do it perfectly, we could still fail, because the process itself
                    will always be imperfect.

                    Ron Jeffries
                    www.XProgramming.com
                    www.xprogramming.com/blog
                    I'm giving the best advice I have. You get to decide whether it's true for you.
                  • Steven Gordon
                    On Mon, Feb 1, 2010 at 7:29 AM, Bill Caputo ... This rings very true. Rate of success is not the right measure; rate of return is. For example, if we could
                    Message 9 of 29 , Feb 1, 2010
                    • 0 Attachment
                      On Mon, Feb 1, 2010 at 7:29 AM, Bill Caputo
                      <list-subscriber@...> wrote:
                      > [....]
                      >
                      > Lean isn't a formula for success any more than
                      > Agile was; both might help improve EV by some number of points (at
                      > best) assuming the other factors in a given context don't dwarf their
                      > effects (something not at all clear IMHO).

                      This rings very true. Rate of success is not the right measure; rate
                      of return is.

                      For example, if we could trade failing 20% more often with having our
                      failures cost 50% less and our successes return us 50% more value, we
                      should take that exchange. It is harder to manage and requires more
                      touchy go/no-go decisions, but we can expect our portfolio of projects
                      to become much more profitable over time.

                      Poker is a game of imperfect information, but it is finite, so we can
                      calculate percentages a priori. Unfortunately, business is too
                      dynamic to even do that. At best, we can analyse past situations and
                      infer how different strategies would have performed. Even then, we
                      can only guess at how different strategies would have affected reality
                      (what we put on the market and when we put it on the market changes
                      the market).

                      SteveG

                      >
                      > Bill
                    • Ron Jeffries
                      Hello, Steven. On Monday, February 1, 2010, at 10:09:50 AM, you ... Yes. Often, our post-hoc analyses of what we should have done assume that everything
                      Message 10 of 29 , Feb 1, 2010
                      • 0 Attachment
                        Hello, Steven. On Monday, February 1, 2010, at 10:09:50 AM, you
                        wrote:

                        > Poker is a game of imperfect information, but it is finite, so we can
                        > calculate percentages a priori. Unfortunately, business is too
                        > dynamic to even do that. At best, we can analyse past situations and
                        > infer how different strategies would have performed. Even then, we
                        > can only guess at how different strategies would have affected reality
                        > (what we put on the market and when we put it on the market changes
                        > the market).

                        Yes. Often, our post-hoc analyses of "what we should have done"
                        assume that everything would have stayed fixed except for correcting
                        the "Big Mistake", and we then assume that we can predict the
                        consequences of that change.

                        Every time-travel story in Science Fiction reminds us that even tiny
                        changes have massive and unpredictable results. Butterfly effect.

                        Ron Jeffries
                        www.XProgramming.com
                        www.xprogramming.com/blog
                        We cannot solve our problems with the same thinking we used when we created them.
                        -- Albert Einstein
                      • Ilja Preuß
                        And even if the process was perfect, and we could follow it perfectly, we still would fail. Because no process could possibly predict in advance whether a
                        Message 11 of 29 , Feb 1, 2010
                        • 0 Attachment
                          And even if the process was perfect, and we could follow it perfectly,
                          we still would fail. Because no process could possibly predict in
                          advance whether a project even has the chance of being successful. In
                          that case, the process shouldn't be assessed by whether you fail, but
                          by how you fail.

                          Cheers, Ilja

                          2010/2/1 Ron Jeffries <ronjeffries@...>:
                          > Hello, Bill.  On Monday, February 1, 2010, at 9:29:10 AM, you
                          > wrote:
                          >
                          >> As to the fallacy? Its in the assumption that one can be doing
                          >> lean/agile/tdd perfectly and not still fail. Code and mechanical
                          >> engineering might be closer to Math and Physics, but software delivery
                          >> (and manufacturing cars) are more like Biology or Economics.
                          >
                          > Yes. Perfection is not given to us. We cannot do anything complex
                          > perfectly (nor, probably, even anything simple). If we did by chance
                          > do it perfectly, we could still fail, because the process itself
                          > will always be imperfect.
                          >
                          > Ron Jeffries
                          > www.XProgramming.com
                          > www.xprogramming.com/blog
                          > I'm giving the best advice I have. You get to decide whether it's true for you.
                          >
                          >
                          >
                          > ------------------------------------
                          >
                          > To Post a message, send it to:   extremeprogramming@...
                          >
                          > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                          >
                          > ad-free courtesy of objectmentor.comYahoo! Groups Links
                          >
                          >
                          >
                          >
                        • Jay Conne
                          Ron as usual gets to the heart of the matter. For that matter, when you say better question , what do you mean? My deep interest is in epistemology at a
                          Message 12 of 29 , Feb 2, 2010
                          • 0 Attachment
                            Ron as usual gets to the heart of the matter.
                            "For that matter, when you say "better question", what do you mean?"

                            My deep interest is in epistemology at a practical level.
                            From that follows attention to what I mean by all the terms I use in
                            a serious conversation.

                            If Lean and Agile are umbrella terms for ways if thinking that also
                            include some recommended practices...
                            Then, if the way of thinking is essentially about not kidding one's
                            self about the facts of the matter...
                            And that includes honesty about what we know and don't know about the topic...
                            And knowing refers to 'out there' as well as 'in here' (our knowledge)...
                            Isn't it simply that a failure like Toyota's handling of the
                            accelerator problem id a failure of application?

                            In a subsequent post, Ron writes: "Yes. Perfection is not given to us. ..."
                            I see a red flag whenever I see or hear the words 'perfect' or 'perfection'.
                            What's the problem? It's the omniscience fallacy.
                            The very term 'omniscience' used in the general sense (AKA the
                            philosophical sense)
                            is a contradiction in terms. By getting people to buy into a
                            contradiction in terms as
                            substantiative, people get manipulated - the contexts identification
                            is left to the reader :-).
                            (If interested I can go into to detail on this - just ask yourself...
                            if you asked someone how tall there are and they answered 'all tall'
                            - what would that mean?)

                            So I see no failure of Lean nor any possibility of perfection in this
                            whole context.
                            The failure is specific failure to attend to principles and practices
                            that are well known.
                            Time to inspect and adapt.
                            The good news for Toyota is that they know the principles,
                            so they can correct more quickly than those who have yet to learn
                            those principles.

                            Jay Conne
                            www.jconne.com


                            =============================================
                            Jay Conne Consulting -- Demystification of Technology
                            Agile Project Management Leadership
                            Lean/Agile Coach, Trainer & ScrumMaster-Practicing
                            617-776-0339 http://www.jconne.com/
                            M: 617-470-5038 Jay@...
                            =============================================

                            [Non-text portions of this message have been removed]
                          Your message has been successfully submitted and would be delivered to recipients shortly.