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

Lean Thinking

Expand Messages
  • yahoogroups@jhrothjr.com
    ... From: Ken Boucher To: extremeprogramming@yahoogroups.com
    Message 1 of 8 , Oct 15, 2003
    • 0 Attachment
      ----- Original Message -----
      From: "Ken Boucher" <yahoo.at.nozen.com@...>
      To: "extremeprogramming@yahoogroups.com"
      <extremeprogramming.at.yahoogroups.com@...>
      Sent: Tuesday, October 14, 2003 10:38 PM
      Subject: [XP] Re: Fwd: New at Hacknot: The Folly Of Emergent Design


      > > I haven't heard of a failure yet where:
      > >
      > > 1. There was a supportive environment
      > > 2. All the developers were on board
      > > 3. All the practices were being done
      > >
      > > I think the only thing that can be done is wait.
      >
      > Knowing what needs to change in the enviroment helps us change the
      > enviroment. Knowing why practices aren't being done helps us change
      > that as well. We can do something better than waiting. We can measure
      > and gain knowledge and then act on it. But in order to do that we
      > really need to listen to the root causes of the failures. And I feel
      > the three things you listed are really symptoms, not root causes.

      They're symptoms of people not wanting to change the way they
      do things until their back is to the wall. If we had any kind of
      solution to that problem, we'd have gotten rid of war two
      millenia ago, nobody would go hungry....

      Lean thinking didn't take over manufacturing because everyone saw
      it and said: "oh, wow!" It took over maufacturing because when
      Toyota started importing significant numbers of cars to the US,
      it started eating Detroit for lunch and asking for seconds.

      With that kind of example, the early adopters tried it and found
      that it solved a lot of endemic problems. In the last two decades
      it's become the 'heads up' thing to do in manufacturing, but only
      now is the effect on inventory turns becoming aparent in the US
      national statistics.

      And that is without full participation from the industrial establishment.
      If manufacturing was fully Lean, you wouldn't see jobs going
      overseas. It's impossible to operate a pull environment when
      one of your processing steps takes a month to transport goods
      by ship. That's old Henry Ford / Frederik Taylor thinking.

      Expecting XP to take over the world in the five years it's
      been out there is a bit naive, I think.


      > > Also read "Lean Software Development" by Mary and Tom Poppendieck.
      >
      > I'm halfway through. After that is Domain Driven Design.

      I didn't start to see the difficulties with what the Poppendieck's had
      done before I read "Lean Thinking" by Womak and Jones.

      > > Maybe we can find something better, but I'm not betting on it, at
      > > least in the sense of something radically different that we could
      > > be doing today if we were simply smart enough to see it.
      >
      > XP isn't really radically different from what came before it. As was
      > recently noted, many of the practices were documented over a decade
      > ago.

      Au contrare. XP turns the fundamental process motif of plan driven
      development on its head. Plan driven development tries to take a
      work unit and run it through several processing stages: Requirements,
      Design, Coding, Testing, Deployment. XP runs smaller work units
      through a single developer who is responsible for taking it from
      requirements through a fully integrated, production quality deployable.

      Everything else, and by that I mean *everything* else, in XP is a
      supporting practice to that one fundamental difference. The fact that most
      of those supporting practices have been in the environment for
      decades was simply luck: Kent didn't have to invent them.


      > > I see XP as being a starting place for applying Lean principles to
      > > software development. I don't see it as being the end point, but I
      > > also don't see any really obvious directions to go.
      >
      > That's why I want to listen so much to the people who are looking for
      > the flaws. The answer to their questions may well be the direction
      > we're looking for.

      The trouble is that the 'flaws' will only show up with people that
      are doing it successfully. When the process collapses, all you really
      know is that it didn't work: there are usually so many flaws that you
      can't isolate any one and say it was critical.

      One of the things that a sensai from Toyota's Lean Institute (and I
      know I've got the names wrong) will do is reorganize a production
      process. He'll do it right away. Pull the workers off, rearrange the
      machines on the floor and get the process restarted in a new organization.
      Then, and only then, do you start working on optimizing the process.
      The fundamental shift has to come first before you can start to see
      the 'flaws' that need to be addressed to make that particular instance of
      the process work smoothly, repeatably and with high quality.

      In manufacturing, sooner or later you've got to take the plunge of
      making a fundamental reorganization of the factory floor. In software
      development, you've got to take that same fundamental plunge of
      reorganizing your development process. The Poppendiecks put it
      quite well: "in manufacturing, inventory control is the starting place
      that always works. In software development, the short, fixed length
      iteration is the starting place that always works."

      Once you make the fundamental committment that you are going
      to take some part of the system you are building from requirements
      to fully integrated, production quality deployable in two weeks (or
      one week or one month,) all your other practices have to change.
      You cannot have handoffs and approvals for requirements analysis,
      nor can you have a separate, end of the line QA department. You
      can't have a godlike Data Base Administration department that
      takes months to optimize your data model either.

      John Roth
    • Ron Jeffries
      ... John, please say a bit more about the difficulties you see with what the P s have done, and how Womack and Jones angle things. Thanks, Ron Jeffries
      Message 2 of 8 , Oct 15, 2003
      • 0 Attachment
        On Wednesday, October 15, 2003, at 7:17:45 AM, yahoogroups@... wrote:

        >> I'm halfway through. After that is Domain Driven Design.

        > I didn't start to see the difficulties with what the Poppendieck's had
        > done before I read "Lean Thinking" by Womak and Jones.

        John, please say a bit more about the difficulties you see with what the
        P's have done, and how Womack and Jones angle things.

        Thanks,

        Ron Jeffries
        www.XProgramming.com
        Hold on to your dream. --ELO
      • yahoogroups@jhrothjr.com
        ... From: Ron Jeffries To: extremeprogramming@yahoogroups.com
        Message 3 of 8 , Oct 15, 2003
        • 0 Attachment
          ----- Original Message -----
          From: "Ron Jeffries"
          <ronjeffries.at.XProgramming.com@...>
          To: "extremeprogramming@yahoogroups.com"
          <extremeprogramming.at.yahoogroups.com@...>
          Sent: Wednesday, October 15, 2003 8:55 AM
          Subject: Re: [XP] Lean Thinking


          > On Wednesday, October 15, 2003, at 7:17:45 AM, yahoogroups@...
          wrote:
          >
          > >> I'm halfway through. After that is Domain Driven Design.
          >
          > > I didn't start to see the difficulties with what the Poppendieck's had
          > > done before I read "Lean Thinking" by Womak and Jones.
          >
          > John, please say a bit more about the difficulties you see with what the
          > P's have done, and how Womack and Jones angle things.

          Well, Womak and Jones make the rather fundamental observation
          that Lean processes that work *always* combine flow and pull.
          Flow (eliminating of all bottlenecks, queue points and handoffs)
          not only doesn't do much if you're manufacturing to inventory
          rather than to order, in fact it's probably less efficient than large batch.
          At the same time, pull (manufacture to order) can't be done if your
          process still has batch and queue type bottlenecks.

          The whole notion of Velocity relates directly to flow. Relating back
          to traditional thinking, I can say things like: "this development team can
          do 10 (or 50 or whatever) function points a week, and have that be
          a meaningful measurement. It takes the project orientation and turns
          it on its head: instead of putting a project team together for one project,
          I put a development team together and tune its operation so it can
          turn out software.

          One place where I think they fall into a rather standard tar pit is
          the distinction between development and production activities. IMO,
          software development combines both. It's a distinction that a lot
          of us make in an effort to drive out the false comparison that *all*
          of software development can be usefully compared to manufacturing
          production, but it loses the fact that, in manufacturing development,
          you can afford expensive one-off processes to build prototypes.
          In software development, you can't. Your actual process of building
          software has to be as disciplined and as efficient as the manufacturing
          process on the factory floor, and you need to be prepared to redo
          it periodically.

          That's where, to take one example, automated tests really shine.
          Automating tests is the only way to provide both repeatability
          and low cost in testing.

          While I think that there are others, I'm not prepared to say much
          about them at this point. I'm still letting things settle while I prepare
          a presentation on Lean Thinking and XP for the next Atlanta XP
          Users Group meeting.

          John Roth



          >
          > Thanks,
          >
          > Ron Jeffries
          > www.XProgramming.com
          > Hold on to your dream. --ELO
          >
        • Ron Jeffries
          ... Nice report, I ll be trying to connect these ideas in as I read the books. One thing I d challenge, just by rote, is the occurrence of the word can t :
          Message 4 of 8 , Oct 15, 2003
          • 0 Attachment
            On Wednesday, October 15, 2003, at 10:51:45 AM, yahoogroups@... wrote:

            > One place where I think they fall into a rather standard tar pit is
            > the distinction between development and production activities. IMO,
            > software development combines both. It's a distinction that a lot
            > of us make in an effort to drive out the false comparison that *all*
            > of software development can be usefully compared to manufacturing
            > production, but it loses the fact that, in manufacturing development,
            > you can afford expensive one-off processes to build prototypes.
            > In software development, you can't. Your actual process of building
            > software has to be as disciplined and as efficient as the manufacturing
            > process on the factory floor, and you need to be prepared to redo
            > it periodically.

            Nice report, I'll be trying to connect these ideas in as I read the books.

            One thing I'd challenge, just by rote, is the occurrence of the word
            "can't":

            ... in manufacturing development, you can afford expensive one-off
            processes to build prototypes. In software development, you can't.

            I never like hearing that I can't do something. In this case it makes me
            wonder (a) why, and (b) "what would have to be true" so that I could afford
            to build prototypes.

            Thanks,

            Ron Jeffries
            www.XProgramming.com
            There is no award for "being XP". There is an award for doing the right
            combination of practices: success.
          • yahoogroups@jhrothjr.com
            ... From: Ron Jeffries To: extremeprogramming@yahoogroups.com
            Message 5 of 8 , Oct 15, 2003
            • 0 Attachment
              ----- Original Message -----
              From: "Ron Jeffries"
              <ronjeffries.at.XProgramming.com@...>
              To: "extremeprogramming@yahoogroups.com"
              <extremeprogramming.at.yahoogroups.com@...>
              Sent: Wednesday, October 15, 2003 11:28 AM
              Subject: Re: [XP] Lean Thinking


              > On Wednesday, October 15, 2003, at 10:51:45 AM, yahoogroups@...
              wrote:
              >
              > > One place where I think they fall into a rather standard tar pit is
              > > the distinction between development and production activities. IMO,
              > > software development combines both. It's a distinction that a lot
              > > of us make in an effort to drive out the false comparison that *all*
              > > of software development can be usefully compared to manufacturing
              > > production, but it loses the fact that, in manufacturing development,
              > > you can afford expensive one-off processes to build prototypes.
              > > In software development, you can't. Your actual process of building
              > > software has to be as disciplined and as efficient as the manufacturing
              > > process on the factory floor, and you need to be prepared to redo
              > > it periodically.
              >
              > Nice report, I'll be trying to connect these ideas in as I read the books.
              >
              > One thing I'd challenge, just by rote, is the occurrence of the word
              > "can't":
              >
              > ... in manufacturing development, you can afford expensive one-off
              > processes to build prototypes. In software development, you can't.
              >
              > I never like hearing that I can't do something. In this case it makes me
              > wonder (a) why, and (b) "what would have to be true" so that I could
              afford
              > to build prototypes.

              I didn't say you couldn't build prototypes. I said you can't afford
              expensive,
              one-off processes to build prototypes. Not the same idea at all. In fact,
              I notice that one attribute of people who like prototypes is that they like
              to build them as cheaply as possible, and the XP approach to prototypes
              seems to be to build them with the production code processes so that you
              can reuse whatever turns out to be reusable.

              John Roth
              >
              > Thanks,
              >
              > Ron Jeffries
              > www.XProgramming.com
              > There is no award for "being XP". There is an award for doing the right
              > combination of practices: success.
              >
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.com
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >
              >
            • Edmund Schweppe
              ... There are two distinct families of prototypes. Throwaway prototypes are built to explore something, then are discarded. Evolutionary prototypes are built
              Message 6 of 8 , Oct 15, 2003
              • 0 Attachment
                yahoogroups@... wrote:

                > I didn't say you couldn't build prototypes. I said you can't afford
                > expensive,
                > one-off processes to build prototypes. Not the same idea at all.

                There are two distinct families of prototypes. Throwaway prototypes are
                built to explore something, then are discarded. Evolutionary prototypes
                are built to explore something, then are evolved into something else
                (typically something of production quality).

                I've seen lots of people try to evolve a throwaway prototype, and have
                lots of pain in so doing. If they'd realized beforehand that the
                particular prototype was *supposed* to be thrown away, they'd have saved
                themselves much pain and suffering.

                > In fact,
                > I notice that one attribute of people who like prototypes is that they like
                > to build them as cheaply as possible,

                Throwaway - yep. Think "spike solution".

                > and the XP approach to prototypes
                > seems to be to build them with the production code processes so that you
                > can reuse whatever turns out to be reusable.

                Evolutionary - yep. Think the XP main codeline.

                XP has both. They're both valuable. It's important, though, to remember
                which is which.

                --
                Edmund Schweppe -- schweppe@... -- http://schweppe.home.tiac.net
                The opinions expressed herein are at best coincidentally related to
                those of any past, present or future employer.
              • Brad Appleton
                ... Actually what I see more of than the above is when a project develops a throwaway prototype with the intent of throwing it away, but then
                Message 7 of 8 , Oct 15, 2003
                • 0 Attachment
                  On Wed, Oct 15, 2003 at 12:48:44PM -0400, Edmund Schweppe wrote:
                  > I've seen lots of people try to evolve a throwaway prototype, and have
                  > lots of pain in so doing. If they'd realized beforehand that the
                  > particular prototype was *supposed* to be thrown away, they'd have saved
                  > themselves much pain and suffering.

                  Actually what I see more of than the above is when a project
                  develops a throwaway prototype with the intent of throwing it
                  away, but then customer/management pressures them into evolving
                  it instead because they aren't willing to wait for the time
                  it takes to develop the "real thing" once the see and like
                  the prototype (and don't understand why it can't/shouldn't be
                  "shipped" in its current form).

                  --
                  Brad Appleton <brad@...> www.bradapp.net
                  Software CM Patterns (www.scmpatterns.com)
                  Effective Teamwork, Practical Integration
                  "And miles to go before I sleep." -- Robert Frost
                • yahoogroups@jhrothjr.com
                  ... From: Brad Appleton To: extremeprogramming@yahoogroups.com
                  Message 8 of 8 , Oct 15, 2003
                  • 0 Attachment
                    ----- Original Message -----
                    From: "Brad Appleton" <brad.at.bradapp.net@...>
                    To: "extremeprogramming@yahoogroups.com"
                    <extremeprogramming.at.yahoogroups.com@...>
                    Sent: Wednesday, October 15, 2003 1:09 PM
                    Subject: Re: [XP] Lean Thinking


                    > On Wed, Oct 15, 2003 at 12:48:44PM -0400, Edmund Schweppe wrote:
                    > > I've seen lots of people try to evolve a throwaway prototype, and have
                    > > lots of pain in so doing. If they'd realized beforehand that the
                    > > particular prototype was *supposed* to be thrown away, they'd have saved
                    > > themselves much pain and suffering.
                    >
                    > Actually what I see more of than the above is when a project
                    > develops a throwaway prototype with the intent of throwing it
                    > away, but then customer/management pressures them into evolving
                    > it instead because they aren't willing to wait for the time
                    > it takes to develop the "real thing" once the see and like
                    > the prototype (and don't understand why it can't/shouldn't be
                    > "shipped" in its current form).

                    You *could* call that a failure to manage expectations, but there
                    are lots of environments where the people making those bonehead
                    decisions are not availible for their expectations to be managed.
                    In other words, developing a 'throwaway' prototype is always a
                    serious risk to the project, *unless* you are certain that everyone who
                    can say "ship it" is *really* on board knowing that it's not shipable.

                    John Roth

                    >
                    > --
                    > Brad Appleton <brad@...> www.bradapp.net
                    > Software CM Patterns (www.scmpatterns.com)
                    > Effective Teamwork, Practical Integration
                    > "And miles to go before I sleep." -- Robert Frost
                    >
                    > To Post a message, send it to: extremeprogramming@...
                    >
                    > To Unsubscribe, send a blank message to:
                    extremeprogramming-unsubscribe@...
                    >
                    > ad-free courtesy of objectmentor.com
                    >
                    > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                    >
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.