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

Re: [agile-usability] Orthodox View of Agile

Expand Messages
  • Ron Jeffries
    Hello, jonathan. On Tuesday, September 8, 2009, at 9:57:14 AM, ... It /is/ work. It is not /software/. One of the most pernicious problems in teams adopting
    Message 1 of 134 , Sep 8, 2009
      Hello, jonathan. On Tuesday, September 8, 2009, at 9:57:14 AM,
      you wrote:

      > 1) The importance of good UX is often undervalued and poorly
      > understood by the client. By not treating UX like real work which is
      > tracked and pointed, its not hard to see where they get that
      > impression from.

      It /is/ work. It is not /software/. One of the most pernicious
      problems in teams adopting agile is not to focus on done software.
      Accordingly, it is good to insist that the only stories on a
      software project represent software.

      UX is not software. I'm sure you bust your ass at it and all that
      but it doesn't bear fruit until it is in the code. Similarly,
      exploratory testing, architecture, and a host of other important
      activities are not software. They all have to be done, and done
      well, and in agile software development they all need to be folded
      into the software in order to be considered done.

      > 2) A great part of agile's appeal (for me at least) lies in embracing
      > a system that I don't have to think about that tracks effort and
      > progress and answers the question "what should I do next?" "You are
      > here all iteration. Tracked." is a little too coarse-grained to be
      > useful. Why can't designers have awesome velocity-tracking too?

      You can. My advice is that you add columns to the left (and right if
      you need them) of the actual software development columns, and put
      your cards there. Just recognize that there is a very different kind
      of "done" represented there and that all the wireframes in the world
      aren't the same as having running tested code.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      I know we always like to say it'll be easier to do it now than it
      will be to do it later. Not likely. I plan to be smarter later than
      I am now, so I think it'll be just as easy later, maybe even easier.
      Why pay now when we can pay later?
    • 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.

        http://www.uie.com/articles/five_design_decision_styles/

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

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