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

47781Re: [scrumdevelopment] UX role in Scrum teams

Expand Messages
  • Robin Paterson
    Jul 28 12:33 PM
    • 0 Attachment
      Hi George,

      On 28/07/2010 15:56, George Dinwiddie wrote:
       

      Robin,

      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.

          Indeed.  I just find it interesting (but, alas, understandable) that these things aren't adopted with great fervour until there's a crisis.  I've certainly worked in places before where there's been a "lean drive" or "six sigma drive" or an "agile drive", and nobody at the coal face really cares, no matter how great they think the techniques are, because they know it's just a management  fad that will soon be forgotten until the next big thing.  The commitment just isn't there.  Unless (some) people are forced to change, they'll always find a reason why not to.


      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.

         
          I see exactly what you mean here, and I completely agree, but I still can't see the valid auto analogy.
          If we were designing a car, then we could do it as designers and create a car with all the features that we wanted.  We could be as detailed as we wanted.  However, once manufacturing gets invlolved, we'd doubtless be informed that "this aspect can't be done", or "this design means a huge tooling change", or "this car will need this, this and this to be legal in the state of California", or "if that's what you want, then it'll take 48 months to set up production, and none of our other ranges will be able to share parts".  If we've already shown the prototype to our customer base, then someone's in for a disappointment.
          However, if we design our car as a team, with a manufacturing rep/specialist with us, then we can avoid most of the issues above, right at the design stage.
          I strongly disagree that once a prototype is built that everything revolves around it.  Engineering is a compromise.

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

          I'm with you here 100%!


      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
      design.

          OK, now JIT is something that was drummed into me at Uni - and this is going back quite a few years now, which is why I'm still in disagreement with the autos analogy.  The auto industry has had decades to refine its manufacturing techniques - some better than others - and I'm still of the opinion that an auto prototype may not look like the finished article once manufacturing realities are factored in.  Many prototypes don't incorporate basic features - AC, ICE, crash protection, all the global regulations on particular parts - and so it's inevitable that compromises will be made along the line.  I still think that this is a bad analogy (although, ultimately, all analogies break down eventually).
          Again, I completely agree with everything else you've said here.
          Having a UX team work on high fid screens no longer makes them prototypes - it's a finished article that the "other" team then has to implement.  The cross functional aspect is lost, customer expectation is already set, and the ability of scrum to react dynamically is lost (to a greater or lesser extent).

          We seem to be in complete agreement about the Sploosh side of this, but disagree about the analogy.  Interesting  :-)

      - George


      -R.

    • Show all 14 messages in this topic