Hi Brian, While I'm not at a very large company, I'm going through the same thing you are - trying to adapt a user-centered approach to an agile development methodology. We're currently revisiting our process because our initial attempt at agile resulted in a number of process breakdowns. Here are a few tips I can offer that might get you started.
A quick caveat: My company has combined project management and design into one position (which I think is a great idea, but perhaps the subject of a different thread). A lot of my suggestions may require some heavy partnership work, depending on your PMs, to (1) be recognized as a stakeholder (since your work is on behalf of the users), and (2) play a proactive role in the upfront, envisioning process. 1. Bring structure to the visioning process. Agile has the notion of an up-front vision, but what it is and how it relates to the process is vague at best in the literature (Schwaber devotes a single paragraph to it in "Agile Project Management with Scrum"). As designers, it's up to us to define some structure around it. A couple tips: 1a. Work one sprint ahead. You'll always be playing catch up if you try to start with what your developers are developing today. Look at the next sprint in the backlog and conduct some vision activities around it. Cut your losses on the current sprint. 1b. Create an experience tree on top of the features in the backlog. This is a simple exercise that links marketing and senior leadership to the feature-centric world that your developers live in. This is equivalent to the "Define the Site" stage in Goto and Cotler's book, only your scope isn't quite so broad. Start at a high level. What are some themes that make up what your product is striving to attain? Your marketing department is a great resource for these. Now move to the experience level. What experiences are needed to give meat to each theme statement? If you sell a product saying it can do X, what will users be doing every day to achieve X? Once you have your experiences, start tying them to features in the backlog. In all but the most forward looking companies that I've witnessed and worked with, an understanding of the bigger picture rarely, if ever, enters in to feature prioritization. You can bring that to the table. 2. Work on the experience level. What you choose to do here depends on your skills and strengths, where the product is, and what makes sense for the next sprint. If navigation is on board for the next sprint, then Goto and Cotler's step of defining the site structure is highly appropriate. Otherwise, picking relevant experiences for the next sprint and doing design around them (even on the wireframe level) will help developers to have a clearer understanding of what they'll be building. 3. Hook in to the Sprint Review meeting The literature suggests that this is a 1/2 day timeboxed meeting. I'm not sure what your company does. But this is where the developers show what happened was accomplished during the sprint for everyone's review. If you aren't participating in these meetings yet, you should be. This is where you watch for any red flags that need to be taken out for some usability testing or other analysis. 4. Buy some of the Agile Project Management literature The best way for you to figure out where the holes are in a process is to know it inside and out. I hate to be a pessimist, but agile is a developer-centric method. If your company is bought into agile from top to bottom, then they're main concern is keeping their developers working, and that runs contrary to a lot of user-centered design processes that recommend a full understanding before you develop anything. Well, hopefully one or two of those ideas has some applications for you. I've just scratched the surface of what I'm rolling out at my company, so if you need more ideas, feel free to hit me up offline. Cheers, -Sam -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Hoffman Sent: Monday, February 11, 2008 1:41 PM To: [EMAIL PROTECTED] Subject: [IxDA Discuss] Overall Web Development Process All, I'm glad to hear the IxDA conference went well. Hopefully I can attend next year and meet a few of you. For those of you involved with website creation and assuming you are part of a larger team that includes graphics artists, developers, etc., what overall process does your team or company use and are you happy with it? I've done a fair amount of research into this topic and eventually settled on the process presented in the book by Kelly Goto and Emily Cotler, "Web Redesign: Workflow that Works." However, I'm working at a new company and the developers have started to utilize Agile development methodologies and I don't believe Goto and Cotler's process takes that style of development into consideration. (Does it need to?) So, does anyone have an overarching website development process they can recommend that would fit well with the Agile development process? Thanks, Brian ________________________________________________________________ *Come to IxDA Interaction08 | Savannah* February 8-10, 2008 in Savannah, GA, USA Register today: http://interaction08.ixda.org/ ________________________________________________________________ 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
