Just a quick question Austin (and sorry if I'm being a bit thick):
You are talking about design and development working in the same sprint, yes? Rather than design working a sprint ahead (whilst also giving feedback on the current dev sprint, of course)?
--- In firstname.lastname@example.org, Austin Govella <austin.govella@...> wrote:
> On Sun, Feb 20, 2011 at 4:31 AM, Robin Dymond <robin.dymond@...> wrote:
> > I'd love to hear from those who feel they have a GREAT Agile process
> > that fully integrates UX into the sprint, and delivers working tested
> > software that users like/love every sprint.
> The best teams I've worked on had a couple of things in common:
> 1. Month-long sprints
> 2. Parallel, layered work-streams within the sprint
> 3. RITE testing
> 4. Collaborative
> 1. MONTH-LONG SPRINTS
> The sprints were a month long. You don't need a month for the
> engineering, nor design, but design (for experiences or interfaces)
> often needs some time for thinking and some time for reflection and
> review. The amount of time needed is different every time.
> With month-long sprints, the first week is heavy kickoff and
> collaboration activities and the last week is heavy QA and tweaking
> activities, so the two intervening weeks gives design time to review,
> reflect, and iterate, iterate, iterate.
> 2. PARALLEL WORK STREAMS
> Parallel work streams between engineering and design. The
> collaborative kickoff activities identify the technology layers and
> how those layers interact with each other. For example, user interacts
> format and these changes are possible. This allows the backend
> developer to expose the data in the proper format, allows the
> front-end developer to work on the interactivity, and allows visual
> design to create the visual experience. UX can drop in with any of
> these layers for heuristic reviews to allow for quick iterations
> within a technology layer.
> 3. RITE TESTING
> Test, iterate, test is also really only possible with month-long
> sprints. You can have a user-testable piece of software in about two
> weeks and go through several days of RITE testing before you have to
> tighten up and get ready for the end of the sprint. I.e. after about
> two weeks you have a hypothesis that your code is of "shippable"
> quality. Rather than actually ship it, you do some quick tests to
> validate your assumption, and then declare yourself done.
> 4. COLLABORATIVE
> Collaborative teams do not view design as a hinderance. The bad teams
> I've worked with have always contained engineers who were more
> concerned with their personal performance than with the product. They
> would rather finish their stories than deliver decent products. Design
> is collaborative by nature, and if anyone in the team (including any
> designers) is more interested in their personal performance than in
> group performance, design -- and the product -- will always suffer.
> Austin Govella
> User Experience
> Catch my presentation at SXSWi:
> * http://schedule.sxsw.com/events/event_IAP7545
> Work: http://www.grafofini.com
> Blog: http://www.thinkingandmaking.com