There should be NO 8-week sprint 0! - The first sprint really is no different to all the other sprints. It should follow the same rules as of the other sprints as well. If anything it should be SHORTER (shorter sprint is good to form teams, team goals and rules, finding impediments, and doing that faster).
But wait, I think there is confusion here. The project don't have to and probably should not start out with the developers crunching code. You still have to create the backlog, you still have to develop a vision of what you actually want to achieve with the system. You still have to understand the user, find out about the goals and the environment. If it sounds like interaction design work, it's because it is. But what about doing that work in sprints, starting out with a backlog of what has to be done in interaction design, business analysis, work process. Planning and performing studies in sprints, decide what gives most business value before each sprint planning. When the developer backlog starts to form, bring in a few developer that helps out with some concepts - you will start to learn from each other what is technically possible and what you are trying archive . As the backlog items will get more stories focused on what should really go into the final product, get some more developer and start churning out the final application. But this does not have to be sprint 0 or 1 this might very well be sprint 4 or 5. I really think there are two sides to interaction design, the analysis work for the backlog and the detailed interaction work with the team. And also, I think the interaction designer will still be the link between the user and the developer, helping out in the communication. --- Håkan Reis Dotway AB +46(768)510033 My blog || http://blog.reis.se My company || http://dotway.se Our conference || http://oredev.org - See you in 2009 On Sun, Nov 9, 2008 at 21:34, Elizabeth Whitworth < [EMAIL PROTECTED]> wrote: > 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 > ________________________________________________________________ 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
