Thanks all for the input, and Adrian and Liz for the links. I have been reading through some (not yet all) of the agile threads on this list, and a number of people seem to be saying 'yes we do start just one sprint ahead of development, but it is usually very painful'...especially if there is no pre-existing style guide or ux infrastructure set up.
This is what I'm struggling with. A lot of agilists talk about big design up front as if it is anathema to successful product development. But what about spending time doing user research up front? Is time spent on user research bduf or is it an essential clarification of the problem before design starts? I get the feeling that existing agile methods rely heavily on supporting structures in an organization - for example, on good up front strategy and leg-work done by a product manager before a project starts. Jeff Patton states in his article ( http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html) "if you're a user experience professional, you will need to adapt your current practice to work within an Agile value system and lifecycle." I agree with this statement but I'm not sure this should be a one-way street. If there is a UX team or person working in the group, then the team should evaluate their process and work in a way that is optimally efficient, not just ask the uxers to adapt to fit into agile processes (which were 'created by developers for developers'). In my example, my company has a number of factors working against a quick up front design. 1. we are working on complex logistics software with a huge range of uers/usage patterns, and 2. I am a relatively junior ux designer and the only ux practitioner in the company, and 3. we have no product manager or business analyst working on the product. In our case, starting design just a 2 week sprint before development was a disaster, and I'm happy that my boss realized that it would to step backwards and spend the time on research and strategic/conceptual design. It also helped that our devs had a lot of complex technical stories to work on while the designwork was going forward; so there was actually no delay in starting with development, but instead a delay in starting the development of the UI. Sooo...I guess the what I'm trying to say in my rather long-winded mail is that I appreciate that my company took a more flexible appraoch to agile methods to accomodate our particular circumstances. I feel that blind adherence to agile practices and rules such as "Sprint 0 should be no longer than a regular sprint" can nullify a lot of the value that good ux work can bring, as well as place undue stress of the ux practitioner/team. Up front UX work is aimed at reducing the risk of developing the wrong product - exactly the same reason why agile methods suggest that teams avoid bduf and start development asap. I think that both tactics are methods that can be used to optimize development and bring value in a project. Our director of IT, for example, was really impressed with paper prototyping efforts done during our 8 week design phase, and noted that we saved a lot of development time doing these design activities up front. Feel free to argue - perhaps I am just going through the agile denial phase that Jeff talks about in his article ;-). Cheers, - liz -- Elizabeth Whitworth User experience specialist TRANSPOREON GmbH Ulm, Germany ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
