Re: [agile-usability] The Role of Vision
- On May 8, 2008, at 1:50 PM, William Pietri wrote:
> Austin Govella wrote:I wasn't sure if you were asking about my sources for them claiming
>>> So, where in an Agile world, does vision come in to play?
>> Agilistas claim you don't need vision: you'll figure it out when
>> you get there.[...] In reality, the agilistas don't care if you
>> communicate the vision.
> They do? I'd love it if you could point me at your sources for that.
you don't the *need* vision, or sources that they don't care if you
*communicate* the vision.
This is based largely on my experience with agile teams, discussions
with others with experience on agile teams.
However, I've been researching this problem, and it's informed by
writing from the agile community:
Why You Won't Fix It Later:
Are we there yet:
Focus on value:
Kicking off the slow software movement (intro):
Kicking off the slow software movement:
Valuing outcomes over features:
Don't become an agile zombie:
Don't know what I want, but I know how to get it:
Is that what you were looking for? I think the clarification is that
bad agilistas poo-poo vision. They also confuse the vision with the
Thinking & Making - http://www.thinkingandmaking.com
Thinking Links - http://thinkingandmaking.com/links
- I'm a bit new to Agile but don't really see the problem with this
vision thing. I use the Cooper Goal-Directed Design Method.
We interview users to learn their goals and understand their tasks and
we do that up front, perhaps as a sprint rather than anything
We produce personas, from the interview data, and goals. And we
produce high level context scenarios, which start making basic
references to concepts that will exist in the design.
From the context scenarios we can almost underline the parts which
indicate user needs.
Then we take out a whiteboard pen and write a storyboard wireframe
(which Cooper used to call the Design Vision and now call in
Interaction Framework). We elaborate a bit on the design hinted at in
the context scenario and produce a key path scenario, which describes
in more detail how the user will interact with the design. This whole
exercise lets us outline the anatomy of the design and to understand
how to play it.
When we are happy with that Design Vision, we can jump into iterations
and do a bit of 'just in time' detailed design.
The Vision, is the Design Vision. It is justified through
understanding the users typical day and their typical needs. It
probably won't change much since it is quite high level.
I'm not sure where the problem is with a vision like this. perhaps,
the only drawback is that you have to do a bit of work in front of the
iterative cycles to get a good understanding of the users and what
they do to enable you to get this vision pinned down.
i'd be interested in comments on this.