Comments in line...
--- Jeff Sutherland <jeff.sutherland@...
> In my paper on the Future of Scrum or Scrum II at
> the Agile 2005 conference
> last week, I mentioned the importance of the Product
> Owner and the need to
> prepare Product Backlog items properly before they
> are turned into Sprint
> Backlog. That preparation requires defining the user
> experience and UI
> design is a key component.
I'm glad to see that you place a high emphasis on good
UI design - I see little of that regardless of the
process being used.
> UI design is a Product Owner responsibility and the
> Product Owner is best
> assisted by a professional UI designer to create the
> design. This design
> flows as a product specification into a Sprint where
> the Product Owner and
> UI designer work with the team during the Sprint to
> make sure it is
> implemented properly.
Tightly coupling the product owner and interaction
designer makes sense and sounds like it works for you.
I must say that in my current environment, at least,
the *right* thing to do would probably be to have the
designer have the final say, because the product
owners are so rooted in their old ways that they
would overrule the designer when the designer pushed
for greater usability. I know this sounds
contradicatory, but this group of users is so
accustomed to poorly structured UIs that they think
its the norm. I quote from one of the developers who
helped promote this thinking: "By the time they lose
their data a couple of times, they won't hit that
button any more".
> As a caveat to this approach, the ivory tower UI
> design approach is a bad
> idea. They must work with the Scrum teams. At my
> current company, the UI
> design function reports to the Director of
> Engineering who makes sure this
> happens. At the same time, we have a strongly
> product marketing driven shop
> which makes sure that the Product Owner is joined at
> the hip to the UI
> designer. These checks and balances are critical to
> avoid isolated power
> centers that force suboptimization of product
> delivery and undercut sales,
> marketing, and uptake of product (a problem that is
> often generated by
> traditional UI design teams and documentation
I agree. I was completely with Cooper until I got to
the portion of the book where he insists that the
design is completed up front and then handed over
(although he seemed to soften this a bit in his
conversation with Beck).
> I view this as a key best business practice in an
> Agile environment.
Interesting, because many agile processes (XP as a
primary example) seem to promote the idea that
developers should work from absolute minimal
specifications, and that anyone should be able to work
on the UI that feels like it (I'm certain someone will
correct me if I am wrong on this :-)). That would seem
to preclude the up-front interaction design work that
would be required. As I've mentioned in other posts, I
have never found it to be the case that any team
member is qualified to design a user interface (I'm
not talking about the mechanics of design, of course,
but the interaction model).
> last iteration of this at PatientKeeper it has led
> to a new webtop design
> that is getting rave reviews and establishing
> industry leadership, yet
> another proof point.
> Jeff Sutherland
> Certified ScrumMaster Training
> On 8/1/05, Keith Lancaster
> <klancaster1957@...> wrote:
> > All,
> > Customer / product owner interaction with
> > is central to most agile methods. When it comes to
> > user interfaces, however, I have not seen this
> > work well...in fact, the instances I can think of
> > been a disaster from a usability standpoint. I am
> > working on a large scale project, using RUP as the
> > process, but incorporating some agile practices.
> > particular, the UI is designed in work sessions
> > the (effectively) product owner, the business
> > and the a UI developer. After reviewing their
> work, it
> > was obvious that they had automated a process that
> > steps that were only there because the process had
> > been paper based. The result was a UI /
> > model that was non-sensical and needlessly
> complex. I
> > have seen blurbs here and there about people
> > attempting to combine agile techniques with
> > goal driven design principles. Has anyone on this
> > group attempted this in the context of Scrum? In
> > particular, it seems that it might be possible to
> > Cooper's interaction designer in the role of
> > owner, essentially acting as an intermediary.
> > Thoughts?
> > Keith Lancaster
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around