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

Re: [agile-usability] UX/Design team working on multiple sprints

Expand Messages
  • Vincent Matyi
    Four, I held on to your post here to give some thought. Would you mind providing some tangible examples of what you d recommend as an effective way to develop
    Message 1 of 7 , Apr 17, 2008
    • 0 Attachment
      Four,

      I held on to your post here to give some thought. Would you mind providing some tangible examples of what you'd recommend as an effective way to develop designs in discovery? Are you suggesting to invest effort towards comping several refined iterations? During a phase as malleable as Discovery, what else could possibly afford the ease of updating, adjusting, and flexibility? I'd consider wires much less deterministic and more suggestive until final round, no?

      Lastly, are we comparing apples to apples here? My assumption is that we're discussing large sized applications and content/interaction intensive sites.

      Vincent



      Four Hewes, Caspian Design wrote:

      Brett,

      I would consider dropping wireframes as an effective way to develop
      designs. I see many designers get hung up in Agile when they bring
      their legacy of design development products (wireframes, flow charts,
      etc.) to iterative/increment al development.

      Wireframe documents initially developed in a slow-paced design
      process as a defining and refining step from concept to
      implementation. As you know Agile/XP/Scrum defines and refines
      in-the-doing, utilizing feedback instead of the determinism inherent
      in wireframes ("I drew this after we thought up this and now we will
      code what I drew") .

      While wireframes and similar artifacts have legitimate, inherent
      value in some design discovery processes, their nature (slow to make
      and abstracted) is at odds with Agile's build-to-evolve- for-fitness
      fundamentals. I have concluded that wireframes and their ilk are too
      tightly tied to linear development to be worth the cost of
      retrofitting them for agile - with one significant exception: as
      quickly made and quickly used artifacts of conversational design
      exploration, typically as hand-drawn sketches.

      I hope these comments help you to find an approach to evolutionary
      design that fully integrates with the rest of your team's work.

      Four
      --
      Four Hewes, Principal
      Caspian Design | A Hybrid Consultancy for changing marketplace,
      technology and business
      Strategic Guidance | New Product Development | Design Services
      http://www.CaspianD esign.com

      == brett.christenson wrote:
      I have read that other UX teams try to keep one cycle ahead of
      development but I still do not understand how this fits into the
      Scrum process. When are wireframes and other cycle 0 design
      deliverables done when the backlog can change from sprint to sprint?

      At 10:38 AM -0700 3/28/08, William Pietri wrote:
      I'm more of an XP guy than a Scrum guy, but let me tell you what my
      best teams do.

      There's a longer answer, which I'd be glad to give when I have a
      little more time. But the short answer is that I see a progressive
      refinement of the plan with just-in-time delivery of required
      information. Working backwards and totally making up the iteration
      numbers, here's an idealized history of a feature over one-week
      iterations:

      iteration 7: we build X
      end of iteration 6: we commit to building X
      iteration 6: we make a detailed estimate for X
      iteration 4: we select X as something we'll do soon
      iteration 3: we make a rough estimate of X
      iteration 3: in prioritizing, we notice that X might fill a business need
      iteration 2: someone has an idea for X

      Now it's important to note that all of this could happen in a week or
      two. If somebody has an idea that everybody agrees is more important
      than whatever we had been planning, then something can go in right
      away. But typically what I see is a gradual, collaborative refinement
      of an idea, from vague notion to detailed implementation.

      It's also vital to realize that although every completed story starts
      with an idea that gets jotted down on a card, the reverse isn't true.
      A detailed plan for a feature is an expense only worth paying if
      we're sure we're going to do it. And even a rough plan is only worth
      doing if it helps us decide whether to do the detailed work. Many
      very good ideas stay only as cards in the backlog that we never quite
      get to. My good teams focus on making decisions at the last
      responsible moment and doing the smallest responsible amount of work
      compatible with good results.

      Typically, I will see a designer spend a fair bit of time working
      with (and often pairing with) developers to implement their stories.
      Another chunk of their time is with the product managers to help
      flesh out what an upcoming story might mean in practice. And
      designers, developers, and product mangers all will participate in
      estimation sessions, iteration planning meetings, and retrospectives.
      Those estimation and planning meetings will drive a lot of the
      designer-only work.

      William

    Your message has been successfully submitted and would be delivered to recipients shortly.