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

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

Expand Messages
  • Four Hewes, Caspian Design
    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
    Message 1 of 7 , Apr 3, 2008
      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/incremental 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.CaspianDesign.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
    • 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 2 of 7 , Apr 17, 2008
        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.