[Sigia-l] IA and Agile Processes

[FelcanSmith, Mark]

I received a return email message for this...sorry if it's getting
posted twice (somehow...)

> -----Original Message-----
> From: FelcanSmith, Mark 
> Sent: Friday, June 10, 2005 9:05 AM
> To: 'Jeff Lash'; SIGIA
> Subject: RE: [Sigia-l] IA and Agile Processes
> 
> 
> 
> Some additional research you may find interesting is listed 
> first, then my responses to your specifics below that.
> 
> 
> Have you checked out the agile-usability yahoo group? I 
> attended the UPA (usability professionals association) 
> conference last year, which had a great deal of focus on 
> agile. I met up w/ Jeff Patton who taught an 
> agile-interaction design workshop...subsequently Jeff started 
> the agile-usability yahoo group and it gets a good amount of 
> traffic from a fairly diverse crowd.
> http://groups.yahoo.com/group/agile-usability/
> 
> Many of the items you mentioned below are discussed there 
> too. Please don't think of usability as merely the testing 
> portion...as usability grows (like user experience) it 
> broadens its scope and influence.
> 
> I also have had a similar discussion on the interaction 
> designers group list, check out the archive for discussion on 
> several of your points.
> You can do a search on [ID Discuss] Agile User-Centered 
> Design in the March 2004 archive
> http://listserver.dreamhost.com/pipermail/discuss-interactiond
> esigners.com/
> or go right to my initial post here:
> http://lists.interactiondesigners.com/htdig.cgi/discuss-intera
> ctiondesigners.com/2004-March/001083.html
> 
> my responses below, prefix [mfs]...
> 
> > - How do you work with iteration timelines -- are you always 
> > one iteration
> > ahead? 
> [mfs] Try to be. In the agile sense this is your opportunity 
> and time to do the next set of *up-front* design work.
> > - How much initial up-front IA work is necessary to get the 
> > foundation? Or
> > is that not needed?
> [mfs] as much upfront as is needed - not the answer you might 
> be looking for. Don't get too hung up on having it *all* 
> figured out ahead of time - that's the essence of agile - 
> learning by doing. I do recommend though having a road 
> map/structure in place for the IA/UI - granted it can change 
> (it's agile after all) but having this in place before you 
> start helps everyone (both dev and customer) get a sense of 
> place, scope, structure, strategy,...
> > - How do you document your work? Do you produce the same 
> deliverables?
> [mfs] upfront user research / IA get documented in the same 
> fashion - however be prepared to have an organic document 
> (you could say its an agile IA document in that it can change 
> based on dev team iterations and business feedback/input) 
> I've heard of many teams leveraging Wiki's in their work, I 
> haven't as of yet, but sounds like it could very useful: 
> requirements, communications, style guide, spec drafting, etc...
> > - How do you deal with different interpretations of the 
> > "customer" (internal
> > customer, external customer, end user)?
> [mfs] This is where UCD says end user is customer; my 
> experience w/ my agile team was that there was a delta 
> between the agile dev team's understanding of 
> customer=business, and UCD understanding of customer. This is 
> somewhat political, but can also be mitigated by good 
> diplomacy on your part and project mgmt support.
> > - IA would seem to bounce back between the "customer" and the 
> > "developer"
> > side, depending on the phase... is this true? Is this an issue?
> [mfs] could you define your scope of IA? If it's a broader 
> sense of defining navigation structure, wireframes, 
> interaction/behavior specs, flow models...then yes I see IA 
> riding the fence between customer and developer - and that's 
> a good thing because the majority of developers don't have a 
> UCD background and are not looking out for the customer in 
> their dev efforts. (honestly - there are some yes, but most are not)
> > - Are you involved in writing front-end code with the 
> > developers, or only
> > producing wireframes/specs that they code off of?
> [mfs] my team worked the paired approach...that is developers 
> paired w/ developers and system and business analysts paired 
> w/ UCD analysts. The bleed over is that all analysts had to 
> sign off on stories from dev before they were considered 
> ready for QA. SO I didn't necessarily *code* on the front 
> end, although we drove CSS, interaction specs, style guide, 
> visual treatments, etc...
> > - How important IS colocation, really? Is it needed 100% of 
> the time?
> [mfs] same question as Donna...can you give us some insight here?
> > - How and how often do you usability test? Do you test off 
> > iterations or off
> > prototypes that you develop?
> [mfs] both...the beauty of paper prototypes is that we can 
> leverage them at any point. The beauty of iterative 
> design/development is that we have consistent access to 
> interactive/clickable prototypes. My take, from the business 
> and customer perspective, was they all really liked the agile 
> approach. They drove their requirements, and at all times had 
> the opportunity to horse-trade features. As one was being 
> developed and was going to consume more time and resources, 
> they had the option to have us go after that, or move on and 
> tackle something else they felt was a higher priority.
> 
> I will say it is a struggle to accept not knowing the big 
> picture up front. Or even knowing a big enough picture up 
> front. My dev managers kept telling me to get comfortable w/ 
> what I don't know - that's hard to swallow as an IA, UX designer!
> 
> Hope this helps,
> Mark
> 
> > 
>