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

Re: [agile-usability] Orthodox View of Agile

Expand Messages
  • Scott Preece
    Hi, Ron, ... Well, you d typically be doing them with end users and doing multiple iterations, so in the PS s office probably doesn t work, but it s probably
    Message 1 of 134 , Sep 8, 2009
      Hi, Ron,

      >From: Ron Jeffries <ronjeffries@...>

      >Hello, jasarask8. On Tuesday, September 8, 2009, at 8:54:27 AM,
      >>you wrote:
      >>I recommend having all UX tasks done in-Sprint. Failing that, I
      >>recommend considering them to be overhead work done in the
      >>product owner's office.

      Well, you'd typically be doing them with end users and doing multiple iterations, so "in the PS's office" probably doesn't work, but it's probably fair to consider them as overhead in the same sense that work replaced as a result of negative customer feedback is overhead. I do tend to think of at least some of this as on the PS side rather than the development side.

      >>> --allows us to get one or two sprints ahead of the team.
      >>Work ahead of the team is what Lean calls "Work In Process". Work In
      >>Process is uniformly considered waste and one tries to eliminate it.

      I don't think it's "work in process" in the usual sense, and I think "waste" has a pejorative connotation that is misleading, but I agree it's not value-add. I think the point is that doing UX iterations is reducing the total waste in the project by avoiding wasted code development effort. Any agile iterative process is going to have waste; waste is how you learn what you need to deliver. The point to UX methods is that they're cheaper to iterate on than code.

      >>If UX is two sprints ahead of the team, then the proper accounting
      >>for stories is that the fastest possible story is three sprints
      >>long. That's a long damn time, and this waste is solely caused by
      >>trying to get ahead.

      Yes, but if you assume there is some average number of iterations required to get things right, the expected time per story is always going to be longer than one sprint and, in an area like UX, where getting it right often takes several iterations, it's probably going to be longer than two stories, anyway. Doing the lead work as UX iterations typically involves fewer people than will be involved in the coding.

      >>> --allows us to be looked at as part of the team. Being a part of
      >>> the team helps developers understand and accept our recommendations.
      >>Being with the team and working with them in real time, instead of
      >>"one or two sprints ahead" would be a better way to become part of
      >>the team in my opinion.

      I do think UX people should be part of the team during development, but for products there's often a holistic aspect to the UX that doesn't thrive if you start from the bottom up - you want the UX to be consistent across different parts of the product.

      I don't think there's any surprise here - this all comes under the notion of "enough" up-front modeling. If you're doing customer-facing UX, and especially if you're doing a consumer product whose development has to be sold to business management and downstream channels, "enough" may be substantial.

      >>> --provides a way to plan for future UX recommendations by
      >>> creating 2-3 day development stories for unknown UX issues.
      >>Like at least one other poster, I do not understand this idea at

      I also don't know exactly what the OP meant by this. My guess is it's getting at reminding the client that things will be discovered late and will involve development time, which suggests a more formal planning process than agile recommends.

    • Adrian Howard
      Hi William, A somewhat belated reply :-) ... Jared Spool has an interesting breakdown of design approaches that you might find of interest.
      Message 134 of 134 , Sep 29, 2009
        Hi William,

        A somewhat belated reply :-)

        On 17 Sep 2009, at 01:48, William Pietri wrote:

        > Adrian Howard wrote:
        >>> Given that, it's not shocking to me that there's still a gap. A
        >>> lot of
        >>> designers don't yet see the value in feedback-driven approaches,
        >>> and a
        >>> lot of agile developers are frustrated with their experiences with
        >>> designers. But I have full faith that we'll work this out
        >>> eventually.
        >> I can't think of any "design" group or individual who's vaguely
        >> competent - agile or not - that doesn't have a whole bunch of
        >> feedback/ iteration in their process. Maybe not feedback with end
        >> users. Often not feedback via code. But certainly feedback from
        >> clients, peers, comparison with alternate designs, etc.
        >> The problem, in my experience, is a wall between the pre-story
        >> iterations/feedback-loops done by the "designers" and the post-
        >> story iterations/feedback-loops done by the "developers".
        > Sorry I wasn't clear here. When I said "feedback-driven" I'm
        > thinking of things that close the outer feedback loops. I think (and
        > I imagine you do as well) the other feedback you describe is only
        > useful to the extent it serves as a lower-cost proxy for the the
        > real thing. Since even sketching things out in a room alone is
        > feedback-driven, clearly I need a better term for what I mean.

        Jared Spool has an interesting breakdown of design approaches that you
        might find of interest.


        by his categories I think you'd be talking about people doing "self
        design" and "genius design".

      Your message has been successfully submitted and would be delivered to recipients shortly.