So the methodology (I actually mentioned it on a previous post on this list) we use within Adobe Consulting, is all about harmonizing the perceived tensions that exist between user-centered design and agile methods (we use SCRUM/XP) so that "build the right thing" and "build things right", so that design-thinking leads and technology and platforms follow.
Our "3D" (Discover, Define, Deliver) approach can be summarized as: Discover - "build the right thing" Huge focus in discovery on UCD exercises, ethnography, user interviews, experience audits, and all manner of UX insights being gathered. This is in addition to insight gathering around business goals (success criteria, stakeholder identification, ROI objectives, business context, etc) and technology landscape. There's nothing "Agile" happening yet; we're setting ourselves up for future agile delivery success. Define - "build the right thing and build things right" In define, we'll undertake the planning activities of agile - writing user-stories (using personas from discovery as the actors for user-stories is helpful) and estimation of user-stories. However, during define we will do the big-thinking about the UX; we'll focus on information architecture for the overall application, we'll create wireframes and visual language and visual design, we'll create our choreography specs (for Rich Internet Applications, we design with time and motion also; there's a z-axis as well as an x- and y-axis to think about). What we find is that "design informs requirements, and requirements inform design", so it's critical that before we complete story writing, we're doing the innovative big-thinking, informed by our "Discover insights" around UX and business goals, and creating and advocating the user-experience. That will in turn inform our requirements gathering process. Agile often advocates "epics, themes and stories", and we find that design work can often be undertaken at the theme-level; the UX team have broad-requirements understanding and deep user-insight, to be able to propose innovative user-experiences without yet being at the story level of detail (ie the username will be an email address and password will be between 6 and 8 characters; that's perhaps a technical/business requirement, but it's more detail than necessarily needed for innovative design). It's only as we move into iterations/sprints that we need to really lock on the pixel-level detail in the UX. So we close out define with all of our stories for a release, with high-level IA and UX for the entire release, and with more detailed user-experience for the initial iterations/sprints of development, at the high-fidelity pixel-level design and with the choreography and motion design nailed (indeed pixel-level comps and choreography deeply impact the estimates/points assigned to a story during iteration and release or sprint planning/backlog prioritization). Deliver - "build things right" Deliver is agile development. Stories are planned into 2-3 week iterations/sprints. A story is not available for development unless: * It is estimated * User-experience design at pixel- and choreography-level is in place for the story * Customer/Acceptance tests are in place for the story An anti-pattern that we've found, is that if UX is being undertaken in parallel to development, our velocity tails off (our ability to realize business value over time) dramatically. That's why it's so critical that the UX team are ahead of the development team by several iterations; and the more UX work that can be undertaken during define, during elaboration of stories, the more likely we are to sustain implementation pace (velocity) because estimates include the complexity of implementing the UX. I also find "Sprint 0" or "Iteration 0" to be an anti-pattern; the aim of an iteration or sprint is to allow a customer to prioritise features according to business value, and to measure the pace (velocity, burn down) that we deliver that business value at, as a measure for the future pace of how we'll continue to deliver business value. If we undertake a Sprint 0 where the activities are not software delivery activities (ie doing UX work, or doing installation of software/environment/etc) then we're not measuring anything of worth, with which to project our velocity for future iterations. It's a pedantic point, but if we're sprinting, then we should be able to measure our speed over a distance as a gauge of how much further we might run over the same time. I think for this list, the experience I'd most share is that in our methodology described above: Discover is where the magic happens; that's where we are unlikely to unlock and discover the insights that will lead to the "soul" or the "spark" of the user-experience. Define is where the most effective products are designed; but if and only if we have a highly-collaborative technology and user-experience team, where we don't have a "design" process and an "engineering" process, but instead have a collaborative process where we are collectively responsible for delivering unambiguous requirements, estimated relatively according to the implementation complexity, with a corresponding user-experience design at the pixel- and motion-level. Design and development, UX and Agile, is a handshake not a handover. Steven Steven Webster Director of Technology and User Experience Adobe Consulting m: +44 7917 428 947 Registered Office: 151 St Vincent Street, Glasgow G2 5NJ. Company No. SC101089 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Hoekman Jr Sent: Tuesday, November 04, 2008 9:24 PM To: Bryan Minihan Cc: [EMAIL PROTECTED] Subject: Re: [IxDA Discuss] Agile & UX > > My experience is very similar to Elizabeth's, except we spent about 8 > weeks on "sprint 0" when we built the groundwork for our core > product. ________________________________________________________________ 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
