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

RE: [agile-usability] Help needed - defining software development process - longish

Expand Messages
  • Larry Constantine
    Esther wrote: 1. Has anyone used card sorting to define a business process? If so, was it helpful? Having helped many companies define design/development
    Message 1 of 6 , Dec 8, 2006

      Esther wrote:

       

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

      Having helped many companies define design/development processes I would echo Josh Seiden and say card-sorting per se is unlikely to be of great help. However, card storming along with affinity clustering and prioritizing card sorts can be effective for collecting and sorting out ideas about potential process components and objectives.

       

      One of the most effective tricks I’ve found in building process/method models is to start from the back end--the delivered product and its qualities and characteristics--then work backwards to determine what “consumables” are needed from an earlier phase/activity to produce that outcome. This helps the group keep focused on what they truly need to do the job they want to do rather than complicating the process model with “it would be nice to have” stuff.

       

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

      My bias in this department is thorough activity/task modeling so that what you are building reflects real user needs and the activities in which end users are actually engaged. Frankly, I have seen better delivered results in projects with good activity/task modeling but too little user testing and feedback than ones with lavish feedback and testing but inadequate modeling.

       

      Of course you always want to do it all, but you don’t always get what you want. :-)

      --Larry Constantine, IDSA, ACM Distinguished Engineer
        Chief Scientist | Constantine & Lockwood, Ltd.
        58 Kathleen Circle | Rowley, MA 01969
        tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com

       


      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of eklay
      Sent: Friday, 08 December 2006 9:27 AM
      To: agile-usability@yahoogroups.com
      Subject: [agile-usability] Help needed - defining software development process - longish

       

      Hi,

      Background:

      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).

      Our VP of Engineering is an advocate for agile and XP practices. The
      issues with implementing these practices include a very small group
      of Product Managers and training in these methods. Our VP has done
      some initial training and introduced UML, patterns, and unit
      testing. We have 2 product managers and one VP of Product
      Management. In the best case scenario, the product manager would be
      the "user in the room" with software engineer. Let me just say that
      Product Management and Engineering were once the same small group
      of people - now they are two groups and we have to decide who does
      what.

      In Engineering we have one User Experience specialist and a QA group
      in addition to the large group of software engineers. I am the lone
      Technical Writer (and I have some usability experience).

      We are doing some informal brainstorming and I am gathering the
      ideas. On the way to work this morning I was wondering if card
      sorting would be a useful technique to help capture this process we
      are trying to define.

      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. We have access to users (alpha and beta sites and
      some internal folks) which is wonderful. We have a UI styleguide
      started and the User Experience specialist and I have visited our
      alpha site. The Client Services folks are doing some task analyses.
      I would love to make some personas.

      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?

      Thanks for your help!
      Esther

    • 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 2 of 6 , Dec 8, 2006
        --- 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 3 of 6 , Dec 8, 2006
          --- 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 4 of 6 , Dec 9, 2006
            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.