47770Re: [scrumdevelopment] UX role in Scrum teams
- Jul 28, 2010George,
I like discussion... :-)
On 28/07/2010 00:43, George Dinwiddie wrote:
Totally agree with your scum comments :-)
On 7/27/10 6:44 PM, Demetrius Nunes wrote:
> Hi there,
> Our customer is used to discuss, validate and accept user story
> definitions based on high fidelity screens and prototypes, which demands
> the UX people to work ahead of the developers, showing these prototypes
> to the customer. Only after that, the Product Owner feels comfortable to
> commit the story to the backlog.
> Is it acceptable for UX people to work ahead of the developers to
> prepare and design the user interfaces and interactions of user stories
> before the actual sprint where these stories will be built, or, ideally,
> UX should always be working together with the developers on the same
> stories in the same sprint?
It's normal for UX to work ahead to help define the stories, but I think
that developing high fidelity mockups and prototypes is wasted effort.
Figuring out every last detail is not necessary before starting the
story, and doing so often results in fragile implementations trying to
hit "pixel perfect" rendition rather than something that will behave
reasonably as browsers change.
> The Product Owner feels comfortable working this way, as long as the
> developers participate thru the whole process and the UX people support
> the developers during the sprints, but I fear this might be a
> sub-optimization of the process, although is hard to see it being done
> any other way, specially because our customer is very attached to the UX
> quality of the user interfaces.
In what way do the UX people support the developers? Do they modify the
designs as they're developed?
Don't follow you here at all.
> 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
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.
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.]
- << Previous post in topic Next post in topic >>