On May 8, 2008, at 12:30 PM, Jared M. Spool wrote:
> I guess I'm wondering what the role of a 'vision' for the project
> is in the Agile world.
> As we study the differences between those organizations that
> produced great user experiences from the ones that are struggling
> to do so, we see that one key differentiator between the two groups
> is whether they have a clear vision.
> Members of successful teams can quickly elaborate what the
> experience of using the design will be like years in the future.
> And everyone on the team gives basically the same story. So, it's
> clear they know what the ideal is. (Keep in mind, this is a vision
> of the experience, not of the technical solution that will drive
> that experience.)....
> So, where in an Agile world, does vision come in to play?
At CIM, we're using an agile process to develop Fancast. UX work fell
into two camps:
1. Discrete, tactical, reactive sprint support helped design and dev
push out the next feature.
2. Strategic, visioning support communicated the *existing* product
vision to everyone on the team.
There's tension. Agilistas claim you don't need vision: you'll figure
it out when you get there. And, sure, you can, but without a vision
you have no consistent benchmark, so your day-to-day decisions are
measured with whatever current meme or trend sweeps your organization.
In reality, the agilistas don't care if you communicate the vision.
They're fighting to win more of your time for tactical work.
Two points need more focus:
First, every project has a vision, regardless of whether it's been
communicated or shared by everyone on the team. But, as Jared said,
teams with a shared vision create better products. (This should be no
surprise. Shared vision is a key factor to any organization's success.)
In my view, helping teams articulate and share their vision is one of
design's (IA, UX) chief responsibilities.
Second, agile processes manage *workflow*. They are not a way to
*design*. The two have *nothing* to do with one another. The friction
we feel comes from people (designers and developers) not
communicating priorities and status. It's a communication problem.
It's not a process problem.
Just this week, I posted six strategies for working better with agile
teams. I'd appreciate any feedback, changes, recommendations, or
comments any of you might have:
Thinking & Making - http://www.thinkingandmaking.com
Thinking Links - http://thinkingandmaking.com/links