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

Re: [agile-usability] Re: Orthodox View of Agile

Expand Messages
  • Austin Govella
    ... Sure. Something we want to done but have not done is done debt . Why does non-code automatically accrue *additional* debt? Also, why does done-ness
    Message 1 of 134 , Sep 17, 2009
    • 0 Attachment
      On Thu, Sep 17, 2009 at 1:45 PM, Anders Ramsay <andersr@...> wrote:
      > I think the operative terms are 'running' and 'tested' - i.e. unless
      > the code is debugged/passes all tests and delivers a feature/flow the
      > Team/PO considers Done, it remains in the Debt column.

      Sure. Something we want to "done" but have not "done" is "done debt".

      Why does non-code automatically accrue *additional* debt?

      Also, why does done-ness have a binary result (done/not done) instead
      of a range of values (not done, functional but not usable, usable, a
      good experience, an awesome experience).

      (In all my experience done/not done has always really meant some
      *degree* of done-ness the team has agreed will suffice.)





      --
      Austin Govella
      User Experience

      Work: http://www.grafofini.com
      Blog: http://www.thinkingandmaking.com
      Book: http://www.blueprintsfortheweb.com

      austin@...
      215-240-1265
    • 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
      • 0 Attachment
        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.