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

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

Expand Messages
  • Robin Dymond
    Anyone else got a process they would like to share here? Robin Dymond, CST Managing Partner, Innovel, LLC. www.innovel.net www.scrumtraining.com Americas:
    Message 1 of 9 , Mar 4, 2011
    • 0 Attachment
      Anyone else got a process they would like to share here?

      Robin Dymond, CST
      Managing Partner, Innovel, LLC.
      www.innovel.net
      www.scrumtraining.com
      Americas: (804) 239-4329
      Europe: +32 489 674 366


      On Sun, Feb 20, 2011 at 5:31 AM, Robin Dymond <rdymond@...> 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.

      If you have this nailed, please come blow your horn here! :)

      Robin.

      --
      Sent from my mobile device

      Robin Dymond, CST
      Managing Partner, Innovel, LLC.
      www.innovel.net
      www.scrumtraining.com
      Americas: (804) 239-4329
      Europe: +32 489 674 366

    • Jon Innes
      I ve got a couple of nuggets of a larger process that largely mess with what others here have said. 1. Do a quick design brief up front to kick off each epic,
      Message 2 of 9 , Mar 7, 2011
      • 0 Attachment
        I've got a couple of nuggets of a larger process that largely mess with what others here have said.

        1. Do a quick design brief up front to kick off each epic, but keep it to 5 pages
        2. Track UX work in the product backlog, to do otherwise is a big #fail
        3. Track UX metrics, and this of course means gathering them
        4. Treat UX bugs as bugs, first class
        5. Define a visual style guide so devs work from wireframes when the UI is fairly simple
        6. Sprint ahead for design, behind for research on short sprints, but test before widely releasing

        As for the topic of length of sprints mentioned earlier, I've worked in weekly sprints and I never found myself doing my best work. I iterate within sprints, as I believe most designers do. If the sprint is long enough, the design evolves faster because you iterate in design and research phases in the sprint.

        It's not uncommon for me to radically change something in two days if I get inspired, only to realize it wasn't that good and then rework it again. When we worked in weekly sprints we tended to build something that I still felt was half baked, and we rarely had a chance to go back. In a month sprint that's almost never a problem. Less rework, better quality.

        Full team sprints are not the same as design cycles in my mind. Too many Agile teams confuse designing and building. The goal should be faster, better product, not just more code for codings sake.

        Jon

        --- In agile-usability@yahoogroups.com, Robin Dymond <robin.dymond@...> wrote:
        >
        > Anyone else got a process they would like to share here?
        >
        > Robin Dymond, CST
        > Managing Partner, Innovel, LLC.
        > www.innovel.net
        > www.scrumtraining.com
        > Americas: (804) 239-4329
        > Europe: +32 489 674 366
        >
        >
        > On Sun, Feb 20, 2011 at 5:31 AM, Robin Dymond <rdymond@...> 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.
        > >
        > > If you have this nailed, please come blow your horn here! :)
        > >
        > > Robin.
        > >
        > > --
        > > Sent from my mobile device
        > >
        > > Robin Dymond, CST
        > > Managing Partner, Innovel, LLC.
        > > www.innovel.net
        > > www.scrumtraining.com
        > > Americas: (804) 239-4329
        > > Europe: +32 489 674 366
        > >
        >
      • 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 3 of 9 , Mar 8, 2011
        • 0 Attachment
          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
          >
          > 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
          > 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.
          >
          > 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
          >
          > austin@...
          > 215-240-1265
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.