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

Help needed - defining software development process - longish

Expand Messages
  • eklay
    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
    Message 1 of 6 , Dec 8, 2006
    • 0 Attachment
      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
    • Josh Seiden
      ... Card sorting is very useful for creating categorization schemes, and for identifying the way people think about the relationships between various elements.
      Message 2 of 6 , Dec 8, 2006
      • 0 Attachment
        > 1. Has anyone used card sorting to define a business
        > process? If so,
        > was it helpful?

        Card sorting is very useful for creating
        categorization schemes, and for identifying the way
        people think about the relationships between various
        elements. I have never seen it used to solve the
        problem you describe.

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

        Watching people work.
      • 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 3 of 6 , Dec 8, 2006
        • 0 Attachment

          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 4 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 5 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 6 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.