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

Re: Help needed - defining software development process - longish

Expand Messages
  • 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 1 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 2 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.