Re: [agile-usability] Orthodox View of Agile
- Hello, jonathan. On Tuesday, September 8, 2009, at 9:57:14 AM,
> 1) The importance of good UX is often undervalued and poorlyIt /is/ work. It is not /software/. One of the most pernicious
> 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.
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 embracingYou can. My advice is that you add columns to the left (and right if
> 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 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.
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?
- 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
>> 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".