Loading ...
Sorry, an error occurred while loading the content.

Re: What does an ass kicking Agile+UX team look like?

Expand Messages
  • patrick.sansom
    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
    Message 1 of 9 , Mar 8, 2011
      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)?

      Thanks, Patrick.

      --- In agile-usability@yahoogroups.com, 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
      > 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.
      > 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
      > with data via javascript, so we need this data from the server in this
      > 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.
      > 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
      > austin@...
      > 215-240-1265
    Your message has been successfully submitted and would be delivered to recipients shortly.