47781Re: [scrumdevelopment] UX role in Scrum teams
- Jul 28, 2010Hi George,
On 28/07/2010 15:56, George Dinwiddie wrote:
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.
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
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.
I'm with you here 100%!
Whether you call it Scrum, Lean, Agile, or Sploosh, the point is to
shorten cycles, compare the results with desires, learn and adjust.
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).
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
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 :-)
- << Previous post in topic Next post in topic >>