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

Re: Help needed - defining software development process - longish

Expand Messages
  • Dave Churchville
    ... Hi Esther, A couple of thoughts... Beware trying to define your process entirely up front to accomodate anything and everything that comes up during
    Message 1 of 6 , Dec 8, 2006
    • 0 Attachment
      --- In agile-usability@yahoogroups.com, "eklay" <eklay@...> wrote:
      > Questions:
      >
      > 1. Has anyone used card sorting to define a business process? If so,
      > was it helpful?
      >
      > 2. If we could only include one thing from the usability world in
      > our as agile as possible process, what should it be?
      >

      Hi Esther,

      A couple of thoughts...

      Beware trying to define your process entirely up front to accomodate
      anything and everything that comes up during brainstorming.

      In the spirit of "as agile as possible", you may want to start with a
      very simple process, and do bi-weekly retrospectives to see what's
      working and what might need some improvement.

      In other words, be agile in defining your process in the first place.
      Some good places to start (which you may already have in place):

      - Communciate frequently with your customers since you actually have
      some. The most useful way to do this is to deliver and demonstrate
      working software to them. Failing that, the second most useful way is
      to show them prototypes of proposed functionality to get feedback.

      - In terms of usability, I've found paper prototypes to be an
      effective way of this kind of initial communication. For more remote
      customers, some sort of HTML low or medium fidelity prototype can be
      really effective as well.

      - Let the team have as much say as possible in HOW they will work.
      It's much more effective to let the people doing the work specify
      their own process rather than trying to dictate it up front.

      Good luck!

      --Dave

      Dave Churchville
      http://www.extremeplanner.com/blog
    • Jeff Patton
      ... One critical question is: do development efforts span time zones - and by that I mean concept to cash - the ideas about what to build and the actual
      Message 2 of 6 , Dec 8, 2006
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, "eklay" <eklay@...> wrote:
        > I am in the unique position of working at a company that is growing
        > rapidly and is ready to establish a software development process
        > (feels like a start-up to me). We have a multi-national workforce
        > with offices and developers in St. Louis, Montreal, and Hyderabad
        > (India).

        One critical question is: do development efforts span time zones - and
        by that I mean "concept to cash" - the ideas about what to build and
        the actual construction of the thing. Separating ideas from
        construction is sort of a risk. It forces your process to have more
        elements to effectively capture and communicate ideas, and later
        evaluate the software built based on those ideas.

        >
        > Questions:
        >
        > 1. Has anyone used card sorting to define a business process? If so,
        > was it helpful?

        Not card sorting, but card modeling. It was Larry Constantine that
        infected me with my love of card modeling. In my current work we use
        cards to model most anything. Random information can be clustered by
        affinity. Cards can be arranged in sequence to form business
        processes. Standard swimlane style business processes can be easily
        built using cards.

        As a tool, cards will help.

        But using cards won't solve your problem - just like me recommending
        you use a hammer won't solve a house-building problem. You've got
        lots of other concerns to balance.

        I'd echo Larry's statements about starting with end, or successful
        outcomes in mind. Identify "deliverables" to communicate from one
        group to another. Keep them as light as possible - and favor face to
        face communication. Identify "consumables" as models or artifacts you
        build to help you progress your level of understanding. Insert
        validation or feedback loops wherever you can to validate decisions
        made a forwarded to others. Remember the only real deliverable is the
        finished software to the consumer. Real validation is made by their
        sucessful use of the product to meet their goals.

        > 2. If we could only include one thing from the usability world in
        > our as agile as possible process, what should it be?

        I'm not sure. Larry makes a good point about task and activity
        modeling. But, part of me is concerned that thinking about tasks and
        activities seems a bit abstract for some folks - though I wish it
        wasn't. I struggle when teaching it to some groups. I've had very
        good luck teaching paper prototyping as a technique. I think Dave
        brought that up. Look at this paper from Gerrard - which I've likely
        mentioned before:
        http://www.agileproductdesign.com/useful_papers/meszaros_agile_usabilty.pdf
        Handouts for classes I teach are here:
        http://www.agileproductdesign.com/presentations/usage_to_user_interface/index.html
        I've stolen Larry's abstract prototyping ideas and combined them with
        Carolyn Snyder's prototyping and testing basics.

        Also, to further confuse you, this recent blog entry about process and
        methodology might be worth looking at since it reports on statements
        made by Christine Perfetti of UIE fame:
        http://www.agileproductdesign.com/blog/there_is_no_spoon.html

        Looking back there's lots of self promotion in my response to you.
        (I'm just so damn excited to actually have a website to point people
        to. ;-) ) But, if I were constructing a process, I'd really suggest
        getting a coach - someone who's done it before to help out. (I'd
        probably choose Alistair Cockburn.) Processes are a different type of
        user centered design. Just as your software needs to meet user goals
        and context of use, so does the process you adopt. You need to
        understand your company's goals and lots about their context. Think
        of techniques, deliverables, and consumables as possible problem
        solutions, then seek to assemble a process solution that helps your
        organization reach its goals.

        Thanks for your post!

        -Jeff
      • Peter Boersma
        ... In that case I encourage you to read an article I wrote for the ASIS&T Bulletin in 2005: StUX - integrating IA deliverables in a software development
        Message 3 of 6 , Dec 9, 2006
        • 0 Attachment
          Esther wrote:
          > I expect that our process will have as many elements from agile as
          > possible(and maybe rational unified process - RUP) massaged a bit
          > here and there.

          In that case I encourage you to read an article I wrote for the ASIS&T Bulletin in 2005:
          "StUX - integrating IA deliverables in a software development methodology"
          http://www.asis.org/Bulletin/Feb-05/boersma.html (site is down at the moment of writing, see below for alternative)

          It deals with how, at a previous employer, I helped introduce user centered design activities into a RUP-based software development process. Both were documented but, compared to some RUP implementations, pretty light-weight.
          (the material was also presented at the 2005 IA Summit. The presentation can be found here:
          http://www.peterboersma.com/blog/2005/03/my-ia-summit-presentation-stux_10.html )

          > 1. Has anyone used card sorting to define a business process? If so,
          > was it helpful?

          No, but I can recommend a group session where each stakeholder places cards/post-it notes on a large surface. Sorting them in order and discussing their definitions, placement, input and output should get you a good first look at a potential process.

          > 2. If we could only include one thing from the usability world in
          > our as agile as possible process, what should it be?

          The mantra "research, design, evaluate". Implementation is important but design, founded on good research and evaluated with users in mind (personas help, real people are also good) is crucial to arrive at a well thought-through product that can be the basis for a long and happy product life-cycle.

          And I second Jeff's(?) suggestion about getting a coach. I have now helped 4 companies develop their processes and I notice I am getting better at guiding the rest of the organization into the flow. Expect obstruction, rejection, conservatism. But stay enthusiastic, because it is worth it in the end!

          Peter
          --
          Peter Boersma | Senior Experience Designer | Info.nl
          http://www.peterboersma.com/blog | http://www.info.nl
        Your message has been successfully submitted and would be delivered to recipients shortly.