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

Re: [scrumdevelopment] Interaction designers and Scrum

Expand Messages
  • Keith Lancaster
    Comments in line... ... Jeff, 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. ...
    Message 1 of 5 , Aug 1, 2005
    • 0 Attachment
      Comments in line...

      --- Jeff Sutherland <jeff.sutherland@...>
      wrote:

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

      Jeff,
      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
      > professionals).
      >

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



      In my
      > 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
      > developers
      > > is central to most agile methods. When it comes to
      > > user interfaces, however, I have not seen this
      > method
      > > work well...in fact, the instances I can think of
      > have
      > > 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.
      > In
      > > particular, the UI is designed in work sessions
      > with
      > > the (effectively) product owner, the business
      > analyst,
      > > and the a UI developer. After reviewing their
      > work, it
      > > was obvious that they had automated a process that
      > had
      > > steps that were only there because the process had
      > > been paper based. The result was a UI /
      > interaction
      > > model that was non-sensical and needlessly
      > complex. I
      > > have seen blurbs here and there about people
      > > attempting to combine agile techniques with
      > Cooper's
      > > 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
      > put
      > > Cooper's interaction designer in the role of
      > product
      > > owner, essentially acting as an intermediary.
      > > Thoughts?
      > >
      > > Keith Lancaster
      > >
      > >
      >


      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com
    Your message has been successfully submitted and would be delivered to recipients shortly.