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

47775Re: [scrumdevelopment] UX role in Scrum teams

Expand Messages
  • George Dinwiddie
    Jul 28, 2010

      On 7/28/10 3:58 AM, Robin Paterson wrote:
      >> > The PO likes to make an analogy with the auto industry, in the sense
      >> > that there is a product concept, design and prototyping phase of a car
      >> > (in which manufacturing engineers are also involved), before the actual
      >> > manufacturing phase, where engineers will then do most of the work
      >> > figuring out how to build the assembly line for that car. Is this a good
      >> > analogy?
      >> I think it's a great analogy. Your PO is choosing the GM strategy, of
      >> doing lots of up-front design because it takes months to change the
      >> tooling. The alternative is the Toyota strategy, of shaving tooling
      >> changes down to days, from months.
      > Don't follow you here at all.
      > Everyone does lots of up front design on new models. Everyone. It's
      > their brand. The models have to be new and exciting, yet familiar.
      > There's also the inevitable compromise in manufacture. Prototypes are
      > supposed to keep the creative juices flowing before the harsh realities
      > of market forces take hold and all the innovative features of your
      > wonderful prototype are watered down to fit the manufacturing schedules :-)
      > At the risk of sounding condescending (I'm not, I'm just looking for
      > some healthy debate), are you inadvertently clouding this topic with
      > lean ideas? Toyota have some great - and totally obvious (most great
      > ideas /are/ totally obvious when they're pointed out) - ideas on process
      > control (but that doesn't mean they're right in all circumstances). I'd
      > be surprised if GM hadn't adopted some of these ideas (or would I?
      > *!*ouch*!*). Most manufacturers invest significantly in quality control
      > and manufacturing efficiency. When I was a mechanical engineering
      > undergrad (and then post-grad) some years ago, we were taught the same
      > kinds of things, except they weren't called lean. Most large auto
      > manufacturers aren't radically different in operation to each other.
      > [As another interesting (well, I think) point, when reading the lean
      > book (as I'm sure you have), you can see parallels with scrum in that
      > many adopters only did so because they were in crisis.]

      The ideas behind Lean and the ideas behind Scrum are not so very
      different. Both depend on shortening timelines to incorporate learning
      and enable changing directions.

      I'm in flight right now, so I can't look up the story, but from
      memory... Car manufacturers have to decide how many of which cars to
      produce. GM, and "most large auto manufacturers" spend a lot of effort
      estimating this well in advance. It takes a lot of time to change the
      tooling in their plants, so they want to minimize the changes. Toyota,
      on the other hand, invested in making the tooling quicker and easier to
      change. This has allowed them to react more quickly as the market
      changes. When demand changes, they can switch to producing the vehicles
      that are selling.

      I see analogous behavior in UX designs. When the user interface is
      designed /in detail/ on paper, then often they turn out to be more
      difficult to realize (particularly for all browsers) than expected. The
      designers can't incorporate what the developers learn from trying to
      implement them, and the development costs go up as the development time
      stretches out.

      Whether you call it Scrum, Lean, Agile, or Sploosh, the point is to
      shorten cycles, compare the results with desires, learn and adjust.

      It seems to work much better when the UX design is done to the point
      that the intent and general layout is clear, and the details are done
      "just in time" with the collaboration of the designer and developer. A
      great deal of learning happens. Equivalent, but cheaper, designs are
      found. Degradation on old browsers is handled in the best possible
      manner without side-lining development in producing exact duplicates on
      browsers that don't support the whiz-bang features used to envision the

      - George

      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
    • Show all 14 messages in this topic