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

121021Re: [XP] Re: Value Stream mapping (was: Estimate vs Actual vs Velocity)

Expand Messages
  • yahoogroups@jhrothjr.com
    Jul 1, 2006
      From: "Daniel Poon" <mr.d.poon.at.gmail.com@...>
      To: "extremeprogramming@yahoogroups.com"
      Sent: Friday, June 30, 2006 10:31 PM
      Subject: [XP] Re: Value Stream mapping (was: Estimate vs Actual vs Velocity)

      > Kent,
      > This has got me thinking: would Toyota differentiate between supplies
      > who provide parts that end up in the end product, and suppliers who
      > provide tools that are used to do the work?
      > Certainly their approach with working on things consumed in the value
      > chain is well known and widely commented on in our community. Their
      > approach to working with a non-lean supplier in the value chain is I
      > believe to set up a buffer between themselves and the supplier.
      > Their approach to tooling is also documented in literature: citing cases
      > where 'obsolete' equipment is used in favor of the latest most
      > 'productive' models, and spending their own engineers time to modify the
      > tools in order to minimize setup times.
      > I speculate that their approach of shunning the latest equipment and
      > going with the 'old model' is an analogous to putting a buffer between
      > themselves and the tool vendors, who are perhaps producing features that
      > Toyota don't actually want.
      > I wonder perhaps if there is anything we can learn from this in our
      > industry, but I'm not sure I should stretch this speculation any further.

      I look at it a bit differently. Consider a kitchen. If you walk
      into a kitchen such as I might have, you'd find a small number
      of general purpose tools. If you walk into a kitchen of someone
      who regularly makes gourmet meals from a many recepies,
      you'll find a wide variety of tools, each specialized for a
      specific purpose.

      Each of these tools is much more productive for their intended
      purpose, but would be the wrong tool for anything else.

      Most claims of "more productive" in the industry, or any industry
      for that matter, have an unwritten subtext of "more productive
      when used with the process we had in mind when we designed

      Toyota does not use "more productive" tooling because most
      of it is designed to be "more productive" when used with large
      production runs of identical parts. They don't do that; and the
      tool that is ideal for that purpose would work for them about
      as well as combat boots on a ballerina trying to dance Swan

      Similarly, trying to convince me that I should invest
      in the "latest and greatest" development tool because it has
      a vastly improved debugger is futile. I haven't used a debugger
      enough to be come fluent since TSO Test on MVT releases
      19 and 20. The vendor may be addressing someone's need,
      but they aren't addressing mine, and while they're spending
      time doing it, they aren't addressing what _I'd_ like to see for
      the next release.

      The tool has to fit the process, or you get the tool dictating
      the process. There are undoubtedly a lot of tools that would
      help agile processes in general, and XP in particular. Some of
      them exist, some of them are undoubtedly things we haven't
      even imagined.

      Take another example: code repositories. To use a technical
      term, the ones we're mostly familiar with suck at effectively
      storing anything other than single plain text files. Try storing
      Word or OO.org files and you promptly discover that all
      of their neat diff and merge capabilities are totally useless.
      And that's if you don't corrupt the file by forgetting the
      magic incantation that tells it that it's not a plain text file.
      There are workarounds for much of it, but why? Today's
      teams typically store everything in repositories; focusing on
      code is so 20th century.

      Or another. Many of them proudly advertise advanced
      branching and merging capabilities. I don't want to get
      into a long discussion of whether branching is needed at
      all, but extremely capable branching and merging simply
      isn't the way XP is described, nor is it the way most of
      us practice it.

      I could go on, but the point here is that "more productive"
      is a meaningless term unless it's put into the context of
      "more productive for who" and "more productive in the
      context of what process model."

      John Roth

      > Regards
      > Daniel
      > Kent Beck wrote:
      >> Daniel,
      >> I don't think (in the JUnit case) that it is my responsibility to "make"
      >> Eclipse.org, JetBrains, or Sun "more extreme". If I want to deliver more
      >> value with JUnit, however, I will find ways to work more closely with
      >> them.
      >> The JUnit team is doing this in various ways--contribution, direct
      >> contact
      >> with developers, mailing lists.
      >> This is different than the Toyota case, where they have the leverage to
      >> demand continuous improvement from their suppliers. Even Toyota is
      >> careful
      >> to use their leverage in mutually beneficial ways, however.
      >> Cheers,
      >> Kent Beck
      >> Three Rivers Institute
      >> _____
      >> From: extremeprogramming@yahoogroups.com
      >> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Daniel Poon
      >> Sent: Friday, June 30, 2006 12:43 AM
      >> To: extremeprogramming@yahoogroups.com
      >> Subject: [XP] Re: Value Stream mapping (was: Estimate vs Actual vs
      >> Velocity)
      >> Kent Beck wrote:
      >>> it is. The biggest potential improvement by this metric is to arrange
      >>> with
      >>> the IDE vendors to roll new versions of JUnit to their customers more
      >>> quickly.
      >> Does this indicate that part of an extreme team's responsibility is to
      >> work with it's suppliers to make them more extreme?
      >> Regards
      >> Daniel
      >> [Non-text portions of this message have been removed]
      >> To Post a message, send it to: extremeprogramming@...
      >> To Unsubscribe, send a blank message to:
      >> extremeprogramming-unsubscribe@...
      >> ad-free courtesy of objectmentor.com
    • Show all 15 messages in this topic