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

Re: [agile-usability] Valuing stories

Expand Messages
  • Adrian Howard
    ... Ah - the old classic of design meaning completely different things to different folk (I really must hone that ranty ban the word design lightning
    Message 1 of 53 , Sep 6, 2009
      On 6 Sep 2009, at 17:15, jonathan berger wrote:

      > Lots of great feedback! To clarify, my question has more to do with
      > the integration of a dedicated (UX) designer on an agile team. I _am_
      > that designer, I have a great team of devs, and I came to agile
      > because I saw how effective a methodology it can be. But I feel like
      > Moses on the mountain: I can see the promised land, but I can't enter
      > it.

      Ah - the old classic of "design" meaning completely different things
      to different folk (I really must hone that ranty "ban the word
      'design'" lightning talk I've had on the back burner :-)

      > Should we write design stories separately? If so, do they have points?
      > How would we measure velocity if a "design-point" is different from a
      > "dev-point"? Maybe there should be a separate tracking system? We've
      > found the friction caused by integrating two tracking systems results
      > in the smaller system (design-tracking) breaking down because it
      > ceases to reflect reality.

      What kind of things are appearing on your design tracking stories?
      Stuff related to the stories being developed? Stuff related to
      ideation? Something else?

      > So that's what I'm struggling with. I'd love to hear suggestions or
      > stories relating to concrete, real-world examples or techniques for
      > integrating design into agile planning.


      One of the pattern that several folk have adopted is the N-1/N+1
      pattern. When the developers are coding stories for iteration N, you
      help test and give feedback on the results of iteration N-1, while
      helping groom and refine the stories that go into iteration N+1.

      It's one of the practices that Jeff Patton talks about in his "Twelve
      emerging best practices for adding UX work to Agile development"
      article which I think you might find useful

      http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html

      Lots of great stuff there. I am particular ranty fan of "12. Become a
      design facilitator" - which I personally think is the key to working
      effectively in agile environments.

      To be honest though - I'm not 100% convinced with the N+1/N-1 pattern.
      It hasn't felt quite right to me when I've tried it for a two reasons:

      1) I find it makes me feel disconnected from the work the dev team is
      doing. I think it makes it hard for me to give the appropriate level
      of attention to what's happening "now". I've also encountered some
      folk who have, I think, misinterpreted it to mean that the UX team
      works separately from the rest of the dev folk - which is a big anti-
      pattern for me.

      2) The other reason is that I'm beginning to think that some of the
      rhythms and cadences of the UX work don't map well onto iteration
      lengths. Some seem shorter (as the rhythms of TDD or Continuous
      Integration are on the dev side). Some seem longer (as the rhythm of
      releases sometimes is, or if you're an XP2E person - things like
      Quarterly Cycles.)

      The bad news is I unfortunately don't yet have any solid ideas for how
      to fix this :-) I've been pondering some of the things I've been
      seeing kanban folk talk about where they have an explicit
      representation of features being refined until they're small enough to
      go into dev in a confident way... but I've not done it in "real life"
      - or thought it through enough to feel like attempting to do so - so I
      could be talking complete tosh!

      You might also like digging into some of the experience reports from
      the UX stage at Agile 2009. I think you might find:

      * http://www.agile2009.org/node/2765
      * http://www.agile2009.org/node/2853
      * http://www.agile2009.org/node/3078

      of interest. Hopefully some of those folk will be sticking slides /
      more info up online somewhere at some point.

      Hope this is of some use!

      Cheers,

      Adrian

      --
      http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
    • Adrian Howard
      ... I think that they re probably an orthogonal dimensions myself. I ve met people who make very good decisions about the design of the code/ ux - but are not
      Message 53 of 53 , Sep 11, 2009
        On 6 Sep 2009, at 21:27, Hassan Schroeder wrote:

        > On Sat, Sep 5, 2009 at 8:31 PM, William Pietri<william@...>
        > wrote:
        >
        >> .... In fact, teams are doing design all the time. The choice
        >> isn't between designing and not designing; it's between designing
        >> well
        >> and designing poorly.
        >
        > Or between designing consciously and designing unconsciously,
        > the latter being fairly close to "not designing" :-)


        I think that they're probably an orthogonal dimensions myself. I've
        met people who make very good decisions about the design of the code/
        ux - but are not really able to articulate the reasoning behind them
        very well.

        This can be problematical since their decisions can sound arbitrary to
        others - even when they're really good decisions.

        Cheers,

        Adrian

        --
        http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
      Your message has been successfully submitted and would be delivered to recipients shortly.