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

Core Agile and UCD values

Expand Messages
  • jens.ulferts
    Hi, I am currently working to identify the core values of UCD and agile. I do this as part of my master s thesis. The fields have a lot in common, but the more
    Message 1 of 22 , Jul 25, 2007
    • 0 Attachment
      Hi,

      I am currently working to identify the core values of UCD and agile. I
      do this as part of my master's thesis.
      The fields have a lot in common, but the more I learn about them the
      more differences I spot. Just comparing them will yield no real
      results as their aim is different. And the worst is, that a lot of
      terms are employed by both fields but with different meanings. My
      approach is hence to abstract from the concrete methods, tools and
      processes and analyze the inherent values of both fields. For that I
      studied literature, a lot of literature, and came up with two lists of
      about 20 values each. I want to merge them in the end and ask
      practitioners how important each value is for their work to succeed.

      There are a lot of approches towards merging UCD and agile but
      validation is scarce. This is understandable as validating a process
      empircally is not feasible. And a one-fits-all process is unrealistic.
      Hence my approach of evaluating the values. The results can then be
      employed to develop agile+UCD processes that fit the project's
      characteristics.

      But before I release the final questionnaire I would like to validate
      the values I have identified so far. Please have a look at them and
      give me some feedback. You are the practitioners and my knowledge is
      mostly from literature. So if you feel anything missing, unclear or
      not belonging there please let me know. I tried to have the values on
      an equal level of abstraction. Of course there are values behind this
      but I want each statement to represent values clearly belonging to the
      respective field.You will not need very long but might even learn what
      you are supposed to do according to literature ;)

      Core Agile values:
      - Employ dependable feedback as a guide to improve work and decisions
      iteratively.
      - Ensure prompt validation of work and decisions
      - Receive requirements from those knowledgeable in the respective
      field (technology, user, business) of the problem domain
      - Gather business needs and use them as requirements for the solution
      - Employ concrete communication mediums, understood by every party
      involved in the communication
      - Strive for simplicity in all aspects
      - Justify every decision concerning the solution with knowledge of the
      problem space
      - Ignore eventualities but those with the utmost probability when
      shaping the solution
      - Cover those aspects with planning that are interfaces between
      different groups of people
      - Minimize overhead so that everyone can focus their effort on the
      process' product - the solution
      - Deliver value as soon as possible and the highest value first
      - Adapt the process to the project's characteristics
      - Be able to address new and changing requirements throughout the process
      - Consider costs when making decisions
      - Have decisions made by those involved who have the most profound
      knowledge in the respective domain
      - Employ objective measurements to show progress
      - Spread knowledge throughout team members and stakeholders
      - Share a vision of the later solution with team members and stakeholders
      - Work together as a team to succeed
      - Apply the most suitable technology to create the solution and to be
      used by it
      - Ensure that multiple solution options to a problem are presented,
      compared and take the most appropriate one
      - Obtain buy-in for the processes values of everyone involved
      - Be able to stop the process at multiple points and still deliver value

      UCD core values:
      - Go for breadth first, then see to the details and depths
      - Employ dependable feedback as a guide to improve work and decisions
      iteratively.
      - Ensure that multiple solution options to a problem are presented,
      compared and take the most appropriate one
      - Aim to optimize the end-user's work practices
      - Strives for a solution with which work is delightful
      - Create more than just the software to address the problem(s)
      - Gather requirements from multiple sources, and then consolidate them.
      - Justify every decision concerning the solution with knowledge of the
      problem space
      - Have an throughout and holistic understanding of the problem domain,
      especially the end-user
      - Gather business needs and use them as requirements for the solution
      - Apply the most suitable technology to create the solution and to be
      used by it
      - Consider costs when making decisions
      - Adapt the process to the project's characteristics
      - Fail early to minimize the need for costly corrections
      - Employ concrete communication mediums, understood by every party
      involved in the communication
      - Spread knowledge throughout team members and stakeholders
      - Strive for simplicity in all aspects
      - Obtain buy-in for the processes values of everyone involved
      - Complete an activity before beginning the next
      - Work together as a team to succeed
      - Receive requirements from those knowledgeable in the respective
      aspect (technology, user, business) of the problem domain
      - Share a vision of the later solution with team members and stakeholders

      With hopes for your valuable answers, best regards

      Jens
    • Desilets, Alain
      I think this is an excellent project. I think spelling out the values of both disciplines will lead to more understanding between practitionners of both. I
      Message 2 of 22 , Jul 25, 2007
      • 0 Attachment
        I think this is an excellent project. I think spelling out the values of both disciplines will lead to more understanding between practitionners of both. I think what you will find is that there is a lot of overlap, but also a few important differences that are at the core of disagreements and arguments between Ux and Agile practitioners.

        I wrote a bit about this here:

        http://www.carleton.ca/hotlab/hottopics/Articles/June2005-AreAgileandUxMet.html

        I was surprised to not find the standard agile values listed in your list:

        http://www.ambysoft.com/essays/agileManifesto.html

        I guess you are looking for lower level values, right?


        ----
        Alain Désilets, MASc
        Agent de recherches/Research Officer
        Institut de technologie de l'information du CNRC /
        NRC Institute for Information Technology

        alain.desilets@...
        Tél/Tel (613) 990-2813
        Facsimile/télécopieur: (613) 952-7151

        Conseil national de recherches Canada, M50, 1200 chemin Montréal,
        Ottawa (Ontario) K1A 0R6
        National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
        K1A 0R6

        Gouvernement du Canada | Government of Canada


        > -----Original Message-----
        > From: agile-usability@yahoogroups.com
        > [mailto:agile-usability@yahoogroups.com] On Behalf Of jens.ulferts
        > Sent: July 25, 2007 3:09 AM
        > To: agile-usability@yahoogroups.com
        > Subject: [agile-usability] Core Agile and UCD values
        >
        > Hi,
        >
        > I am currently working to identify the core values of UCD and
        > agile. I do this as part of my master's thesis.
        > The fields have a lot in common, but the more I learn about
        > them the more differences I spot. Just comparing them will
        > yield no real results as their aim is different. And the
        > worst is, that a lot of terms are employed by both fields but
        > with different meanings. My approach is hence to abstract
        > from the concrete methods, tools and processes and analyze
        > the inherent values of both fields. For that I studied
        > literature, a lot of literature, and came up with two lists
        > of about 20 values each. I want to merge them in the end and
        > ask practitioners how important each value is for their work
        > to succeed.
        >
        > There are a lot of approches towards merging UCD and agile
        > but validation is scarce. This is understandable as
        > validating a process empircally is not feasible. And a
        > one-fits-all process is unrealistic.
        > Hence my approach of evaluating the values. The results can
        > then be employed to develop agile+UCD processes that fit the
        > project's characteristics.
        >
        > But before I release the final questionnaire I would like to
        > validate the values I have identified so far. Please have a
        > look at them and give me some feedback. You are the
        > practitioners and my knowledge is mostly from literature. So
        > if you feel anything missing, unclear or not belonging there
        > please let me know. I tried to have the values on an equal
        > level of abstraction. Of course there are values behind this
        > but I want each statement to represent values clearly
        > belonging to the respective field.You will not need very long
        > but might even learn what you are supposed to do according to
        > literature ;)
        >
        > Core Agile values:
        > - Employ dependable feedback as a guide to improve work and
        > decisions iteratively.
        > - Ensure prompt validation of work and decisions
        > - Receive requirements from those knowledgeable in the
        > respective field (technology, user, business) of the problem domain
        > - Gather business needs and use them as requirements for the solution
        > - Employ concrete communication mediums, understood by every
        > party involved in the communication
        > - Strive for simplicity in all aspects
        > - Justify every decision concerning the solution with
        > knowledge of the problem space
        > - Ignore eventualities but those with the utmost probability
        > when shaping the solution
        > - Cover those aspects with planning that are interfaces
        > between different groups of people
        > - Minimize overhead so that everyone can focus their effort
        > on the process' product - the solution
        > - Deliver value as soon as possible and the highest value first
        > - Adapt the process to the project's characteristics
        > - Be able to address new and changing requirements throughout
        > the process
        > - Consider costs when making decisions
        > - Have decisions made by those involved who have the most
        > profound knowledge in the respective domain
        > - Employ objective measurements to show progress
        > - Spread knowledge throughout team members and stakeholders
        > - Share a vision of the later solution with team members and
        > stakeholders
        > - Work together as a team to succeed
        > - Apply the most suitable technology to create the solution
        > and to be used by it
        > - Ensure that multiple solution options to a problem are
        > presented, compared and take the most appropriate one
        > - Obtain buy-in for the processes values of everyone involved
        > - Be able to stop the process at multiple points and still
        > deliver value
        >
        > UCD core values:
        > - Go for breadth first, then see to the details and depths
        > - Employ dependable feedback as a guide to improve work and
        > decisions iteratively.
        > - Ensure that multiple solution options to a problem are
        > presented, compared and take the most appropriate one
        > - Aim to optimize the end-user's work practices
        > - Strives for a solution with which work is delightful
        > - Create more than just the software to address the problem(s)
        > - Gather requirements from multiple sources, and then
        > consolidate them.
        > - Justify every decision concerning the solution with
        > knowledge of the problem space
        > - Have an throughout and holistic understanding of the
        > problem domain, especially the end-user
        > - Gather business needs and use them as requirements for the solution
        > - Apply the most suitable technology to create the solution
        > and to be used by it
        > - Consider costs when making decisions
        > - Adapt the process to the project's characteristics
        > - Fail early to minimize the need for costly corrections
        > - Employ concrete communication mediums, understood by every
        > party involved in the communication
        > - Spread knowledge throughout team members and stakeholders
        > - Strive for simplicity in all aspects
        > - Obtain buy-in for the processes values of everyone involved
        > - Complete an activity before beginning the next
        > - Work together as a team to succeed
        > - Receive requirements from those knowledgeable in the
        > respective aspect (technology, user, business) of the problem domain
        > - Share a vision of the later solution with team members and
        > stakeholders
        >
        > With hopes for your valuable answers, best regards
        >
        > Jens
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
      • Adrian Howard
        [snippet from what I posted on the IdX list for folk to disagree with :-) ] ... [snip] For me these don t seem very core to UCD. A UCD practitioner would
        Message 3 of 22 , Jul 25, 2007
        • 0 Attachment
          [snippet from what I posted on the IdX list for folk to disagree
          with :-) ]

          > But before I release the final questionnaire I would like to validate
          > the values I have identified so far. Please have a look at them and
          > give
          > me some feedback. You are the practitioners and my knowledge is mostly
          > from literature. So if you feel anything missing, unclear or not
          > belonging there please let me know. I tried to have the values on an
          > equal level of abstraction. Of course there are values behind this
          > but I
          > want each statement to represent values clearly belonging to the
          > respective field.You will not need very long but might even learn what
          > you are supposed to do according to literature ;)
          >
          > Core UCD values:
          >
          [snip]

          For me these don't seem very "core" to UCD. A UCD practitioner would
          probably agree with them. Then again a practitioner of something like
          RUP would do. They seem very general.

          UCD is design based on the needs of the user. That doesn't really
          come out of that list to me.

          [snip]

          > In the fortunate case that you have worked in an agile environment you
          > can also give me feedback on the second list. Those are the agile core
          > values:
          >
          [snip]

          These don't really seem to capture agile for me. Again somebody
          running a non-agile software development process would be more than
          happy to agree to the majority.

          Some of them (e.g. "Employ concrete communication mediums") seem to
          run counter to the way agile environments work (depending on what you
          mean by "concrete" :-)

          Others (e.g."Be able to stop the process at multiple points and still
          deliver value") seem to be emphasising the wrong thing (it's not the
          stopping the process that's valuable, it's the continual regular
          release of business value - whether you stop the process or not).

          Have you come across the Agile Manifesto? It has a pretty explicit
          list of values/principles that most agile folk would agree with
          (http://agilemanifesto.org/, http://agilemanifesto.org/
          principles.html). You also might want to look at the list of XP
          values from Beck's XP Explained.

          Cheers,

          Adrian
        • Elizabeth Whitworth
          Hi Jens, Nice to see someone is working in this space...what is your final thesis going to be focused on? I also had trouble associating the core values of
          Message 4 of 22 , Jul 25, 2007
          • 0 Attachment
            Hi Jens,

            Nice to see someone is working in this space...what is your final thesis going to be focused on?

            I also had trouble associating the 'core' values of both agile and UCD to your lists. The priorities seem a little mixed up. It would be nice to see you go a little deeper into the realities of each field.

            Some suggestions for continuing your research:

            - do some interviews with practitioners of each field (over email or phone if needs be).
             - do more reading, e.g. read the core books (some nice overview books to start are Kent Becks Extreme programming explained, and Jesse James Garrett's elements of user experience);
            read archives from mailing lists such as this one, the major agile lists, and the ixda mailing list;
            read the blogs/articles from the major writers in each field. for agile you could start with the agile manifesto authors. for ucd you can start members of this list: http://www.usabilityviews.com/userati_rating.html and take a look on the web for the less prolific writers (but good designers).
             - read through job postings for agile and/or ucd jobs.
             - read portfolios of people in the field (look for paragraphs outlining principles, goals, vision etc. ).
             - attend some agile/ucd workshops or conferences (the agile alliance has funding available for students researching agile - http://www.agilealliance.org/show/1655).

            I hope you let us know the results of your work. good luck!
             - liz



            On 7/25/07, jens.ulferts <jens.ulferts@...> wrote:

            Hi,

            I am currently working to identify the core values of UCD and agile. I
            do this as part of my master's thesis.
            The fields have a lot in common, but the more I learn about them the
            more differences I spot. Just comparing them will yield no real
            results as their aim is different. And the worst is, that a lot of
            terms are employed by both fields but with different meanings. My
            approach is hence to abstract from the concrete methods, tools and
            processes and analyze the inherent values of both fields. For that I
            studied literature, a lot of literature, and came up with two lists of
            about 20 values each. I want to merge them in the end and ask
            practitioners how important each value is for their work to succeed.

            There are a lot of approches towards merging UCD and agile but
            validation is scarce. This is understandable as validating a process
            empircally is not feasible. And a one-fits-all process is unrealistic.
            Hence my approach of evaluating the values. The results can then be
            employed to develop agile+UCD processes that fit the project's
            characteristics.

            But before I release the final questionnaire I would like to validate
            the values I have identified so far. Please have a look at them and
            give me some feedback. You are the practitioners and my knowledge is
            mostly from literature. So if you feel anything missing, unclear or
            not belonging there please let me know. I tried to have the values on
            an equal level of abstraction. Of course there are values behind this
            but I want each statement to represent values clearly belonging to the
            respective field.You will not need very long but might even learn what
            you are supposed to do according to literature ;)

            Core Agile values:
            - Employ dependable feedback as a guide to improve work and decisions
            iteratively.
            - Ensure prompt validation of work and decisions
            - Receive requirements from those knowledgeable in the respective
            field (technology, user, business) of the problem domain
            - Gather business needs and use them as requirements for the solution
            - Employ concrete communication mediums, understood by every party
            involved in the communication
            - Strive for simplicity in all aspects
            - Justify every decision concerning the solution with knowledge of the
            problem space
            - Ignore eventualities but those with the utmost probability when
            shaping the solution
            - Cover those aspects with planning that are interfaces between
            different groups of people
            - Minimize overhead so that everyone can focus their effort on the
            process' product - the solution
            - Deliver value as soon as possible and the highest value first
            - Adapt the process to the project's characteristics
            - Be able to address new and changing requirements throughout the process
            - Consider costs when making decisions
            - Have decisions made by those involved who have the most profound
            knowledge in the respective domain
            - Employ objective measurements to show progress
            - Spread knowledge throughout team members and stakeholders
            - Share a vision of the later solution with team members and stakeholders
            - Work together as a team to succeed
            - Apply the most suitable technology to create the solution and to be
            used by it
            - Ensure that multiple solution options to a problem are presented,
            compared and take the most appropriate one
            - Obtain buy-in for the processes values of everyone involved
            - Be able to stop the process at multiple points and still deliver value

            UCD core values:
            - Go for breadth first, then see to the details and depths
            - Employ dependable feedback as a guide to improve work and decisions
            iteratively.
            - Ensure that multiple solution options to a problem are presented,
            compared and take the most appropriate one
            - Aim to optimize the end-user's work practices
            - Strives for a solution with which work is delightful
            - Create more than just the software to address the problem(s)
            - Gather requirements from multiple sources, and then consolidate them.
            - Justify every decision concerning the solution with knowledge of the
            problem space
            - Have an throughout and holistic understanding of the problem domain,
            especially the end-user
            - Gather business needs and use them as requirements for the solution
            - Apply the most suitable technology to create the solution and to be
            used by it
            - Consider costs when making decisions
            - Adapt the process to the project's characteristics
            - Fail early to minimize the need for costly corrections
            - Employ concrete communication mediums, understood by every party
            involved in the communication
            - Spread knowledge throughout team members and stakeholders
            - Strive for simplicity in all aspects
            - Obtain buy-in for the processes values of everyone involved
            - Complete an activity before beginning the next
            - Work together as a team to succeed
            - Receive requirements from those knowledgeable in the respective
            aspect (technology, user, business) of the problem domain
            - Share a vision of the later solution with team members and stakeholders

            With hopes for your valuable answers, best regards

            Jens


          • jennifer ferreira
            Hi Jens I have worked on the agile/ucd topic for my masters ... well. Those are good lists --- just a little long don t you think? If you re really talking
            Message 5 of 22 , Jul 25, 2007
            • 0 Attachment
              Hi Jens

              I have worked on the agile/ucd topic for my masters
              --- good to hear there are others looking into it as
              well. Those are good lists --- just a little long
              don't you think? If you're really talking *core* then
              I'd expect something a little more concise. But
              perhaps that's your aim with the merge.
              Anyhoo, I agree with you that on the surface ucd and
              agile seem like they're very similar and that a
              development team should easily incorporate one with
              the other --- both use iterations, right? However, as
              you have noticed, and I have found digging a little
              deeper, there are fundamental differences that make
              using both a little tricky. And widely open to
              interpretation.
              One major insight for me was the different points of
              view among uc designers and agile practitioners on how
              to start work. The ucd team might insist they can't
              produce anything until they have an overall view of
              the whole product, while the agile developers want to
              start coding right away with the few requirements that
              are known now. How the teams resolve this issue is
              most interesting. Some may feel that they'll let the
              uc designers do some user research up front for now,
              but not feel totally comfortable with it and hope that
              in the future it can somehow be eliminated, while
              others are cool with up front uc design as long as the
              developers don't go changing the design during
              implementation.

              Sorry for rambling but this topic fascinates me.

              So I think you should definitely follow Liz's advice,
              particularly about speaking to people in the field, to
              hear "Here's how we did it..." The literature's
              allright but the real nuts and bolts of it has to be
              figured out by those on the real-world teams and I
              think that's where the values really become evident.

              J.

              On 7/26/07, Elizabeth Whitworth
              <elizabethwhitworth@...> wrote:

              Hi Jens,

              Nice to see someone is working in this
              space...what is your final thesis going to be focused
              on?

              I also had trouble associating the 'core' values
              of both agile and UCD to your lists. The priorities
              seem a little mixed up. It would be nice to see you go
              a little deeper into the realities of each field.

              Some suggestions for continuing your research:

              - do some interviews with practitioners of each
              field (over email or phone if needs be).
              - do more reading, e.g. read the core books (some
              nice overview books to start are Kent Becks Extreme
              programming explained, and Jesse James Garrett's
              elements of user experience);
              read archives from mailing lists such as this one,
              the major agile lists, and the ixda mailing list;
              read the blogs/articles from the major writers in
              each field. for agile you could start with the agile
              manifesto authors. for ucd you can start members of
              this list:
              http://www.usabilityviews.com/userati_rating.html and
              take a look on the web for the less prolific writers
              (but good designers).
              - read through job postings for agile and/or ucd
              jobs.
              - read portfolios of people in the field (look
              for paragraphs outlining principles, goals, vision
              etc. ).
              - attend some agile/ucd workshops or conferences
              (the agile alliance has funding available for students
              researching agile -
              http://www.agilealliance.org/show/1655).

              I hope you let us know the results of your work.
              good luck!
              - liz




              On 7/25/07, jens.ulferts <jens.ulferts@...>
              wrote:

              Hi,

              I am currently working to identify the core
              values of UCD and agile. I
              do this as part of my master's thesis.
              The fields have a lot in common, but the more
              I learn about them the
              more differences I spot. Just comparing them
              will yield no real
              results as their aim is different. And the
              worst is, that a lot of
              terms are employed by both fields but with
              different meanings. My
              approach is hence to abstract from the
              concrete methods, tools and
              processes and analyze the inherent values of
              both fields. For that I
              studied literature, a lot of literature, and
              came up with two lists of
              about 20 values each. I want to merge them in
              the end and ask
              practitioners how important each value is for
              their work to succeed.

              There are a lot of approches towards merging
              UCD and agile but
              validation is scarce. This is understandable
              as validating a process
              empircally is not feasible. And a one-fits-all
              process is unrealistic.
              Hence my approach of evaluating the values.
              The results can then be
              employed to develop agile+UCD processes that
              fit the project's
              characteristics.

              But before I release the final questionnaire I
              would like to validate
              the values I have identified so far. Please
              have a look at them and
              give me some feedback. You are the
              practitioners and my knowledge is
              mostly from literature. So if you feel
              anything missing, unclear or
              not belonging there please let me know. I
              tried to have the values on
              an equal level of abstraction. Of course there
              are values behind this
              but I want each statement to represent values
              clearly belonging to the
              respective field.You will not need very long
              but might even learn what
              you are supposed to do according to literature
              ;)

              Core Agile values:
              - Employ dependable feedback as a guide to
              improve work and decisions
              iteratively.
              - Ensure prompt validation of work and
              decisions
              - Receive requirements from those
              knowledgeable in the respective
              field (technology, user, business) of the
              problem domain
              - Gather business needs and use them as
              requirements for the solution
              - Employ concrete communication mediums,
              understood by every party
              involved in the communication
              - Strive for simplicity in all aspects
              - Justify every decision concerning the
              solution with knowledge of the
              problem space
              - Ignore eventualities but those with the
              utmost probability when
              shaping the solution
              - Cover those aspects with planning that are
              interfaces between
              different groups of people
              - Minimize overhead so that everyone can focus
              their effort on the
              process' product - the solution
              - Deliver value as soon as possible and the
              highest value first
              - Adapt the process to the project's
              characteristics
              - Be able to address new and changing
              requirements throughout the process
              - Consider costs when making decisions
              - Have decisions made by those involved who
              have the most profound
              knowledge in the respective domain
              - Employ objective measurements to show
              progress
              - Spread knowledge throughout team members and
              stakeholders
              - Share a vision of the later solution with
              team members and stakeholders
              - Work together as a team to succeed
              - Apply the most suitable technology to create
              the solution and to be
              used by it
              - Ensure that multiple solution options to a
              problem are presented,
              compared and take the most appropriate one
              - Obtain buy-in for the processes values of
              everyone involved
              - Be able to stop the process at multiple
              points and still deliver value

              UCD core values:
              - Go for breadth first, then see to the
              details and depths
              - Employ dependable feedback as a guide to
              improve work and decisions
              iteratively.
              - Ensure that multiple solution options to a
              problem are presented,
              compared and take the most appropriate one
              - Aim to optimize the end-user's work
              practices
              - Strives for a solution with which work is
              delightful
              - Create more than just the software to
              address the problem(s)
              - Gather requirements from multiple sources,
              and then consolidate them.
              - Justify every decision concerning the
              solution with knowledge of the
              problem space
              - Have an throughout and holistic
              understanding of the problem domain,
              especially the end-user
              - Gather business needs and use them as
              requirements for the solution
              - Apply the most suitable technology to create
              the solution and to be
              used by it
              - Consider costs when making decisions
              - Adapt the process to the project's
              characteristics
              - Fail early to minimize the need for costly
              corrections
              - Employ concrete communication mediums,
              understood by every party
              involved in the communication
              - Spread knowledge throughout team members and
              stakeholders
              - Strive for simplicity in all aspects
              - Obtain buy-in for the processes values of
              everyone involved
              - Complete an activity before beginning the
              next
              - Work together as a team to succeed
              - Receive requirements from those
              knowledgeable in the respective
              aspect (technology, user, business) of the
              problem domain
              - Share a vision of the later solution with
              team members and stakeholders

              With hopes for your valuable answers, best
              regards

              Jens







              Send instant messages to your online friends http://au.messenger.yahoo.com
            • Jens Ulferts
              [Also as posted on IxDA] You are right my values are not core . I used the wrong expression. What I am looking for is the first level of values, the ones that
              Message 6 of 22 , Jul 26, 2007
              • 0 Attachment
                [Also as posted on IxDA]

                You are right my values are not "core". I used the wrong expression.
                What I am looking for is the first level of values, the ones that stand
                right behind the activities and their flow. So one value alone can also
                be found within other methodologies. But as I see it the combination of
                the values constitutes what UCD and Agile is about. The question is -
                and this is where my master's thesis comes in - how important each value
                is for the people working in agile/UCD projects. Combining the two will
                necessarily lead to compromises. The two can not be merged in their pure
                form. Ones I have an empirical answer to how important each value is I
                hope to be able to give recommendations on how the activities need to be
                adjusted so that both groups can find their needs met. Therefore, I need
                to stay on a level where a match between value and activity is easy but
                not 1:1.

                The values in the agile manifesto are to abstract for my needs and so
                are the principals, but I feel that it is quite easy to match most of
                what I have been working on with the principals stated. I have extracted
                the values for agile from the agile principles, Beck's XP Explained,
                Schwaber Agile Management with Scrum and some papers I have read. BTW is
                there something similar, some manifesto, for UCD?

                The point you mentioned as an example - "Employ concrete communication
                mediums" - is the one I have been struggling with for some time now.
                What I was referring to is that with agile you are striving for means to
                support your communication with people from outside your culture
                (business, technical, designer, user, ...). To me this is apparent when
                looking at the way requirements are gathered. You create user stories
                and maybe prototypes. You have a vision, which is just a couple of words
                in the case of Scrum/XP. You show the working software to the users and
                management. All this is done so as to minimize the effort needed for
                imagination, to avoid misunderstandings and to shield the different
                groups from details that are superfluous for them to know. And this is
                the same in UCD. But again this only becomes agile when combining this
                value with others so that you minimize the overhead required to build
                the mediums and that you produce value fast among others.
                Do you have any suggestion so that it is less misunderstanding? English
                is not my native language so I am sometimes struggling with the
                connotation of word.

                The second point you mention seems absolutely true to me (being able to
                stop at any given time). I think I will omit this one as it is already
                enclosed in another one. So I will change one value to:
                - Deliver value as soon as possible, constantly and the highest value first

                Thanks for your insights, helped a lot

                Adrian Howard schrieb:
                >
                > [snippet from what I posted on the IdX list for folk to disagree
                > with :-) ]
                >
                > > But before I release the final questionnaire I would like to validate
                > > the values I have identified so far. Please have a look at them and
                > > give
                > > me some feedback. You are the practitioners and my knowledge is mostly
                > > from literature. So if you feel anything missing, unclear or not
                > > belonging there please let me know. I tried to have the values on an
                > > equal level of abstraction. Of course there are values behind this
                > > but I
                > > want each statement to represent values clearly belonging to the
                > > respective field.You will not need very long but might even learn what
                > > you are supposed to do according to literature ;)
                > >
                > > Core UCD values:
                > >
                > [snip]
                >
                > For me these don't seem very "core" to UCD. A UCD practitioner would
                > probably agree with them. Then again a practitioner of something like
                > RUP would do. They seem very general.
                >
                > UCD is design based on the needs of the user. That doesn't really
                > come out of that list to me.
                >
                > [snip]
                >
                > > In the fortunate case that you have worked in an agile environment you
                > > can also give me feedback on the second list. Those are the agile core
                > > values:
                > >
                > [snip]
                >
                > These don't really seem to capture agile for me. Again somebody
                > running a non-agile software development process would be more than
                > happy to agree to the majority.
                >
                > Some of them (e.g. "Employ concrete communication mediums") seem to
                > run counter to the way agile environments work (depending on what you
                > mean by "concrete" :-)
                >
                > Others (e.g."Be able to stop the process at multiple points and still
                > deliver value") seem to be emphasising the wrong thing (it's not the
                > stopping the process that's valuable, it's the continual regular
                > release of business value - whether you stop the process or not).
                >
                > Have you come across the Agile Manifesto? It has a pretty explicit
                > list of values/principles that most agile folk would agree with
                > (http://agilemanifesto.org/, <http://agilemanifesto.org/,>
                > http://agilemanifesto.org/ <http://agilemanifesto.org/>
                > principles.html). You also might want to look at the list of XP
                > values from Beck's XP Explained.
                >
                > Cheers,
                >
                > Adrian
                >
                >
              • Michael T. Pullen
                Hello, I have a basic problem with this comparison. Agile development is a process created for the engineering aspect of software development. UCD is created
                Message 7 of 22 , Jul 27, 2007
                • 0 Attachment
                  Hello,

                  I have a basic problem with this comparison. Agile development is a
                  process created for the engineering aspect of software development.
                  UCD is created for the design aspect of software.

                  Traditionally we smush these 2 things together in the software world
                  so that software is made up of development and sales - product
                  strategy and design just happen. Can you imagine if that was done in
                  the car or movie industries? They follow a general breakdown of three
                  processes 1) strategy/design --> 2)engineering --> 3) Sales.

                  So what you ask?
                  - User centered design is a process focused on coming up with the
                  correct design and then ensuring that the correct design becomes the
                  best it can be during development.
                  - Agile processes are set up to develop the best product in the
                  timeframes needed.
                  Figuring out the correct design is very different from designing and
                  developing the best design.

                  In conclusion: the usability aspect of UCD could be analyzed in the
                  context of Agile development but not the design. UI design within the
                  engineering process is about making the optimal changes within the
                  context of the design selected.

                  The analogy that I use is building an apartment complex one room at a
                  time. You can do that and you will have an interesting building in the
                  end. However, a designer (architect) is required to go through the
                  design process to identify what kind of apartment is being created and
                  what it is generally going to look like, if you want a cohesive
                  correct design.

                  Good luck,

                  mTp

                  PS Here are my 4 bullets to the design manifesto in the agile process:
                  Story Centered Techniques for Agile Design
                  1 Intimacy of stories over iteration management
                  2 Breadth of screens to provide a vision over depth and detail
                  3 User Acceptance every iteration over usability tests
                  4 Design Standards embedded in UI code libraries over unique designs



                  --- In agile-usability@yahoogroups.com, "jens.ulferts"
                  <jens.ulferts@...> wrote:
                  >
                  > Hi,
                  >
                  > I am currently working to identify the core values of UCD and agile. I
                  > do this as part of my master's thesis.
                  > The fields have a lot in common, but the more I learn about them the
                  > more differences I spot. Just comparing them will yield no real
                  > results as their aim is different. And the worst is, that a lot of
                  > terms are employed by both fields but with different meanings. My
                  > approach is hence to abstract from the concrete methods, tools and
                  > processes and analyze the inherent values of both fields. For that I
                  > studied literature, a lot of literature, and came up with two lists of
                  > about 20 values each. I want to merge them in the end and ask
                  > practitioners how important each value is for their work to succeed.
                  >
                  > There are a lot of approches towards merging UCD and agile but
                  > validation is scarce. This is understandable as validating a process
                  > empircally is not feasible. And a one-fits-all process is unrealistic.
                  > Hence my approach of evaluating the values. The results can then be
                  > employed to develop agile+UCD processes that fit the project's
                  > characteristics.
                  >
                  > But before I release the final questionnaire I would like to validate
                  > the values I have identified so far. Please have a look at them and
                  > give me some feedback. You are the practitioners and my knowledge is
                  > mostly from literature. So if you feel anything missing, unclear or
                  > not belonging there please let me know. I tried to have the values on
                  > an equal level of abstraction. Of course there are values behind this
                  > but I want each statement to represent values clearly belonging to the
                  > respective field.You will not need very long but might even learn what
                  > you are supposed to do according to literature ;)
                  >
                  > Core Agile values:
                  > - Employ dependable feedback as a guide to improve work and decisions
                  > iteratively.
                  > - Ensure prompt validation of work and decisions
                  > - Receive requirements from those knowledgeable in the respective
                  > field (technology, user, business) of the problem domain
                  > - Gather business needs and use them as requirements for the solution
                  > - Employ concrete communication mediums, understood by every party
                  > involved in the communication
                  > - Strive for simplicity in all aspects
                  > - Justify every decision concerning the solution with knowledge of the
                  > problem space
                  > - Ignore eventualities but those with the utmost probability when
                  > shaping the solution
                  > - Cover those aspects with planning that are interfaces between
                  > different groups of people
                  > - Minimize overhead so that everyone can focus their effort on the
                  > process' product - the solution
                  > - Deliver value as soon as possible and the highest value first
                  > - Adapt the process to the project's characteristics
                  > - Be able to address new and changing requirements throughout the
                  process
                  > - Consider costs when making decisions
                  > - Have decisions made by those involved who have the most profound
                  > knowledge in the respective domain
                  > - Employ objective measurements to show progress
                  > - Spread knowledge throughout team members and stakeholders
                  > - Share a vision of the later solution with team members and
                  stakeholders
                  > - Work together as a team to succeed
                  > - Apply the most suitable technology to create the solution and to be
                  > used by it
                  > - Ensure that multiple solution options to a problem are presented,
                  > compared and take the most appropriate one
                  > - Obtain buy-in for the processes values of everyone involved
                  > - Be able to stop the process at multiple points and still deliver value
                  >
                  > UCD core values:
                  > - Go for breadth first, then see to the details and depths
                  > - Employ dependable feedback as a guide to improve work and decisions
                  > iteratively.
                  > - Ensure that multiple solution options to a problem are presented,
                  > compared and take the most appropriate one
                  > - Aim to optimize the end-user's work practices
                  > - Strives for a solution with which work is delightful
                  > - Create more than just the software to address the problem(s)
                  > - Gather requirements from multiple sources, and then consolidate them.
                  > - Justify every decision concerning the solution with knowledge of the
                  > problem space
                  > - Have an throughout and holistic understanding of the problem domain,
                  > especially the end-user
                  > - Gather business needs and use them as requirements for the solution
                  > - Apply the most suitable technology to create the solution and to be
                  > used by it
                  > - Consider costs when making decisions
                  > - Adapt the process to the project's characteristics
                  > - Fail early to minimize the need for costly corrections
                  > - Employ concrete communication mediums, understood by every party
                  > involved in the communication
                  > - Spread knowledge throughout team members and stakeholders
                  > - Strive for simplicity in all aspects
                  > - Obtain buy-in for the processes values of everyone involved
                  > - Complete an activity before beginning the next
                  > - Work together as a team to succeed
                  > - Receive requirements from those knowledgeable in the respective
                  > aspect (technology, user, business) of the problem domain
                  > - Share a vision of the later solution with team members and
                  stakeholders
                  >
                  > With hopes for your valuable answers, best regards
                  >
                  > Jens
                  >
                • William Pietri
                  ... I disagree with this. In my view, agile methods include the entirety of the software development process. That can (and IMHO usually should) include a lot
                  Message 8 of 22 , Jul 27, 2007
                  • 0 Attachment
                    Michael T. Pullen wrote:
                    > I have a basic problem with this comparison. Agile development is a
                    > process created for the engineering aspect of software development.
                    > UCD is created for the design aspect of software.
                    >

                    I disagree with this. In my view, agile methods include the entirety of
                    the software development process. That can (and IMHO usually should)
                    include a lot of user-focused design activity.

                    > Traditionally we smush these 2 things together in the software world
                    > so that software is made up of development and sales - product
                    > strategy and design just happen.

                    I'm not sure I agree with this particular split. However, I do agree
                    that short-cycle iterative processes can be used to drive a lot of other
                    activity, so they seemingly "just happen". However, there's no rule
                    against planning ahead in an agile process.

                    There is a rule against stopping other work to plan. And it's also poor
                    form to decline to update your plan in the face of new information, or
                    to decide you've done such a good job planning that you don't need to
                    frequently test your theories in the real world.

                    As long as you can keep up with that, though, there's nothing wrong with
                    planning ahead, including in doing user-related design, as much as you
                    see fit.

                    William
                  • Mark Schraad
                    ... I am having some trouble parsing this paragraph... please help me, is this what you meant? An analysis of the worth, of the usability component of the user
                    Message 9 of 22 , Jul 27, 2007
                    • 0 Attachment
                      On Friday, July 27, 2007, at 02:33PM, "Michael T. Pullen" <michaeltpullen@...> wrote:

                      >In conclusion: the usability aspect of UCD could be analyzed in the
                      >context of Agile development but not the design. UI design within the
                      >engineering process is about making the optimal changes within the
                      >context of the design selected.

                      I am having some trouble parsing this paragraph... please help me, is this what you meant?

                      An analysis of the worth, of the usability component of the user center design process is possible, within an agile project, but the design itself can not be analyzed.

                      Within the engineering process the best you can do as a interface designer is to rearrange the visual elements, but you can not alter the user's work flow.

                      Is this correct? If so - I am very glad that I am not a designer on your team.

                      Mark
                    • George Dinwiddie
                      ... Wonderful! I hope you don t mind I ve quoted this at http://idiacomputing.com/moin/FortuneCookies - George -- ... * George Dinwiddie *
                      Message 10 of 22 , Jul 27, 2007
                      • 0 Attachment
                        On Fri, July 27, 2007 14:54, William Pietri wrote:
                        > there's no rule
                        > against planning ahead in an agile process.
                        >
                        > There is a rule against stopping other work to plan. And it's also poor
                        > form to decline to update your plan in the face of new information, or
                        > to decide you've done such a good job planning that you don't need to
                        > frequently test your theories in the real world.

                        <snag/> Wonderful! I hope you don't mind I've quoted this at
                        http://idiacomputing.com/moin/FortuneCookies

                        - George

                        --
                        ----------------------------------------------------------------------
                        * George Dinwiddie * http://blog.gdinwiddie.com
                        Software Development http://www.idiacomputing.com
                        Consultant and Coach http://www.agilemaryland.org
                        ----------------------------------------------------------------------
                      • Michael T. Pullen
                        Thanks for the insult but I think I may be unclear in my description. Within the engineering process the best you can do as a interface designer is to
                        Message 11 of 22 , Jul 27, 2007
                        • 0 Attachment
                          Thanks for the insult but I think I may be unclear in my description.

                          "Within the engineering process the best you can do as a interface
                          designer is to rearrange the visual elements, but you can not alter
                          the user's work flow."
                          - You can do what ever you want during the engineering process. At the
                          level you are describing this is just perfecting the design you have
                          chosen.
                          - How do you select the correct design of the product as a whole?
                          Do you come up with a couple of ideas and select from those and move
                          forward? Or do you come up with 100s or 1000s of ideas and narrow the
                          list to a few possible? I believe you need to do the latter to come up
                          with the "correct" product design.

                          " An analysis of the worth, of the usability component of the user
                          center design process is possible, within an agile project, but the
                          design itself can not be analyzed. "
                          - I split the design process in 2:
                          - Product strategy/design: I believe that there is a component of
                          design which is outside the development process (goal to find the best
                          whole product design)
                          - Engineering design: design that is inside the development process -
                          this design is focused on taking the "best idea" and making it the
                          best product

                          I hope this adds some clarity.

                          mTp

                          PS I understand this is not "accepted" thought in the software
                          industry but let's focus on the ideas rather than whether I am good to
                          work with.




                          --- In agile-usability@yahoogroups.com, Mark Schraad <mschraad@...> wrote:
                          >
                          >
                          > On Friday, July 27, 2007, at 02:33PM, "Michael T. Pullen"
                          <michaeltpullen@...> wrote:
                          >
                          > >In conclusion: the usability aspect of UCD could be analyzed in the
                          > >context of Agile development but not the design. UI design within the
                          > >engineering process is about making the optimal changes within the
                          > >context of the design selected.
                          >
                          > I am having some trouble parsing this paragraph... please help me,
                          is this what you meant?
                          >
                          > An analysis of the worth, of the usability component of the user
                          center design process is possible, within an agile project, but the
                          design itself can not be analyzed.
                          >
                          > Within the engineering process the best you can do as a interface
                          designer is to rearrange the visual elements, but you can not alter
                          the user's work flow.
                          >
                          > Is this correct? If so - I am very glad that I am not a designer on
                          your team.
                          >
                          > Mark
                          >
                        • Desilets, Alain
                          ... I agree with this. There is a whole bunch of work that has to happen before an organisation decides to comission the building of a particular kind of
                          Message 12 of 22 , Jul 27, 2007
                          • 0 Attachment
                            > - Product strategy/design: I believe that there is a
                            > component of design which is outside the development process
                            > (goal to find the best whole product design)

                            I agree with this. There is a whole bunch of work that has to happen before an organisation decides to comission the building of a particular kind of software. Who are we building this for, why, how do we hope to make money out of it, what's the basic product concept, etc...

                            For example, I am leading a research group that's tasked with developing new and innovative computer assisted translation tools that translators will actually use. At the moment, we have about half a dozen brilliant ideas for new products (all of them inspired by the results of contextual inquiry), and our biggest challenge is deciding which one we'll spend the next 6 months working on.

                            If you choose the wrong idea to work on, no amount of good UI design and engineering is going to salvage the product.

                            ----
                            Alain Désilets, MASc
                            Agent de recherches/Research Officer
                            Institut de technologie de l'information du CNRC /
                            NRC Institute for Information Technology

                            alain.desilets@...
                            Tél/Tel (613) 990-2813
                            Facsimile/télécopieur: (613) 952-7151

                            Conseil national de recherches Canada, M50, 1200 chemin Montréal,
                            Ottawa (Ontario) K1A 0R6
                            National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
                            K1A 0R6

                            Gouvernement du Canada | Government of Canada
                          • Desilets, Alain
                            ... Oh, forgot to mention. This is a part of my job I m still struggling with. Over the past 5 years, I have learned various Ux techniques which allow me to
                            Message 13 of 22 , Jul 27, 2007
                            • 0 Attachment
                              > I agree with this. There is a whole bunch of work that has to
                              > happen before an organisation decides to comission the
                              > building of a particular kind of software. Who are we
                              > building this for, why, how do we hope to make money out of
                              > it, what's the basic product concept, etc...

                              Oh, forgot to mention. This is a part of my job I'm still struggling
                              with. Over the past 5 years, I have learned various Ux techniques which
                              allow me to figure out what the end user wants and needs, and what
                              product will best meet his needs.

                              But I'm still struggling with figure out what the *business customer*
                              wants and needs, and what product will best meet those needs. Does
                              anyone have hints on how to do this?

                              Thx.

                              Alain
                            • Mark Schraad
                              ... Seriously? My intent was not insult. I just wanted to be emphatic about my seat at the table as a designer. I am a user experience designer. As such I
                              Message 14 of 22 , Jul 27, 2007
                              • 0 Attachment
                                On Friday, July 27, 2007, at 04:18PM, "Michael T. Pullen" <michaeltpullen@...> wrote:
                                >Thanks for the insult but I think I may be unclear in my description.

                                Seriously? My intent was not insult. I just wanted to be emphatic about my seat at the table as a designer. I am a user experience designer. As such I touch research, information architecture, process flow, user interaction and visual design. Take any one of those away am it lessens my ability to make an optimal contribution. Reduce my role to that of visual (cake decorating) and I am likely gone.

                                >"Within the engineering process the best you can do as a interface
                                >designer is to rearrange the visual elements, but you can not alter
                                >the user's work flow."
                                >- You can do what ever you want during the engineering process. At the
                                >level you are describing this is just perfecting the design you have
                                >chosen.
                                > - How do you select the correct design of the product as a whole?
                                >Do you come up with a couple of ideas and select from those and move
                                >forward? Or do you come up with 100s or 1000s of ideas and narrow the
                                >list to a few possible? I believe you need to do the latter to come up
                                >with the "correct" product design.
                                >
                                Designers should be the ultimate iterators. Sure, 100 sketches before I touch a mouse... not uncommon.

                                >" An analysis of the worth, of the usability component of the user
                                >center design process is possible, within an agile project, but the
                                >design itself can not be analyzed. "
                                >- I split the design process in 2:
                                >- Product strategy/design: I believe that there is a component of
                                >design which is outside the development process (goal to find the best
                                >whole product design)
                                >- Engineering design: design that is inside the development process -
                                >this design is focused on taking the "best idea" and making it the
                                >best product
                                >

                                Ideally, we can work collaboratively - back and forth between the two stages you describe. If you lock down strategy and design to then move to engineering, aren't we just talking a waterfall?

                                >I hope this adds some clarity.

                                Very much so. Please don't take my comments personally...

                                >mTp
                                >
                                >PS I understand this is not "accepted" thought in the software
                                >industry but let's focus on the ideas rather than whether I am good to
                                >work with.
                                >
                                >
                                >
                                >
                                >--- In agile-usability@yahoogroups.com, Mark Schraad <mschraad@...> wrote:
                                >>
                                >>
                                >> On Friday, July 27, 2007, at 02:33PM, "Michael T. Pullen"
                                ><michaeltpullen@...> wrote:
                                >>
                                >> >In conclusion: the usability aspect of UCD could be analyzed in the
                                >> >context of Agile development but not the design. UI design within the
                                >> >engineering process is about making the optimal changes within the
                                >> >context of the design selected.
                                >>
                                >> I am having some trouble parsing this paragraph... please help me,
                                >is this what you meant?
                                >>
                                >> An analysis of the worth, of the usability component of the user
                                >center design process is possible, within an agile project, but the
                                >design itself can not be analyzed.
                                >>
                                >> Within the engineering process the best you can do as a interface
                                >designer is to rearrange the visual elements, but you can not alter
                                >the user's work flow.
                                >>
                                >> Is this correct? If so - I am very glad that I am not a designer on
                                >your team.
                                >>
                                >> Mark
                                >>
                                >
                                >
                                >
                              • Dale Emery
                                Hi Michael, ... I do, too. ... I see this as defining the system s responsibilities, and its role in the business processes in which it takes part. I like to
                                Message 15 of 22 , Jul 27, 2007
                                • 0 Attachment
                                  Hi Michael,

                                  > - I split the design process in 2:

                                  I do, too.

                                  > - Product strategy/design: I believe that there is a
                                  > component of
                                  > design which is outside the development process (goal to
                                  > find the best
                                  > whole product design)

                                  I see this as defining the system's responsibilities, and
                                  its role in the business processes in which it takes part.

                                  I like to separate this from what you call "engineering
                                  design" by applying The Fantasy of Perfect Technology
                                  (TFoPT):

                                  1. Imagine that the system could be implemented with
                                  /perfect/ technology. Perfect technology suffers none of
                                  the disadvantages of current, real-world technology.
                                  Perfect technology is free. It has infinite storage
                                  capacity. It never breaks. It uses no energy and generates
                                  no heat. It responds not at the speed of light, but (as my
                                  friend III puts it) at the speed of /dark/.

                                  2. Now, how would you describe the system's
                                  responsibilities?

                                  TFoPT invites us to focus on the /essence/ of the system:
                                  the features that we would require of the system regardless
                                  of what technology we use to implement it.

                                  Note that TFoPT applies only inside the system. Outside the
                                  system is regular old messy fallible technology.

                                  > - Engineering design: design that is inside the
                                  > development process -
                                  > this design is focused on taking the "best idea" and
                                  > making it the
                                  > best product

                                  Yes, this fits my idea of design (adapted from III's): A
                                  blueprint for the selection of, organization of, and control
                                  over elements of technology to satisfy system
                                  responsibilities.

                                  The first kind of design creates a technology-agnostic view
                                  of the system from outside. The second kind creates a
                                  technology-laden view of the inside of the system.

                                  Dale

                                  --
                                  Dale Emery, Consultant
                                  Inspiring Leadership for Software People
                                  Web: http://www.dhemery.com
                                  Weblog: http://www.dhemery.com/cwd
                                • William Pietri
                                  ... I agree with every bit of this except the before part. Yes, you will need to figure out all of those things in great detail if you want to have a
                                  Message 16 of 22 , Jul 27, 2007
                                  • 0 Attachment
                                    Desilets, Alain wrote:
                                    > There is a whole bunch of work that has to happen before an organisation decides to comission the building of a particular kind of software. Who are we building this for, why, how do we hope to make money out of it, what's the basic product concept, etc...
                                    >
                                    > [...]
                                    >
                                    > If you choose the wrong idea to work on, no amount of good UI design and engineering is going to salvage the product.
                                    >

                                    I agree with every bit of this except the "before" part.

                                    Yes, you will need to figure out all of those things in great detail if
                                    you want to have a successful product. But why would you have to do all
                                    of that first?

                                    As Robert Cringely says, "That's because every startup -- EVERY STARTUP
                                    -- faces a crisis early-on and changes dramatically what it intends to
                                    do. So the smart VC invests more in the people than in the idea because
                                    the idea is going to
                                    change."

                                    William
                                  • Desilets, Alain
                                    ... The agile methodology I have most experience with is XP. In XP, there is an assumption that there is a customer (or customer team) who knows enough about
                                    Message 17 of 22 , Jul 28, 2007
                                    • 0 Attachment
                                      > Desilets, Alain wrote:
                                      > > There is a whole bunch of work that has to happen before an
                                      > organisation decides to comission the building of a
                                      > particular kind of software. Who are we building this for,
                                      > why, how do we hope to make money out of it, what's the basic
                                      > product concept, etc...
                                      > >
                                      > > [...]
                                      > >
                                      > > If you choose the wrong idea to work on, no amount of good
                                      > UI design and engineering is going to salvage the product.
                                      > >
                                      >

                                      William replied:
                                      > I agree with every bit of this except the "before" part.

                                      The agile methodology I have most experience with is XP. In XP, there is an assumption that there is a customer (or customer team) who knows enough about the business, domain and users in order to guide product development.

                                      All I am saying is that these people have to do a lot of homework in order to be in a position to act as customer on an XP team.

                                      For example, I currently have to decide whether my team should be building:

                                      A) a large translation memory based on bilingual web content that's freely available

                                      Of

                                      B) an open wikipedia like terminology database

                                      Or

                                      C) An integrated IDE-like environment for translators

                                      All three of those seem like good opportunities and are well supported by data I collected through contextual inquiry. But there is very little overlap between those three products and we don't have the resources to pursue all three of those opportunities at once.

                                      So how do I go about picking the most promising one?

                                      I haven't found good techniques for making those kinds of decisions yet.


                                      ----
                                      Alain Désilets, MASc
                                      Agent de recherches/Research Officer
                                      Institut de technologie de l'information du CNRC /
                                      NRC Institute for Information Technology

                                      alain.desilets@...
                                      Tél/Tel (613) 990-2813
                                      Facsimile/télécopieur: (613) 952-7151

                                      Conseil national de recherches Canada, M50, 1200 chemin Montréal,
                                      Ottawa (Ontario) K1A 0R6
                                      National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
                                      K1A 0R6

                                      Gouvernement du Canada | Government of Canada
                                    • Dean Morrow
                                      ... happen before an organisation decides to comission the building of a particular kind of software. For me, it s design vs. manufacturing – building the
                                      Message 18 of 22 , Jul 28, 2007
                                      • 0 Attachment
                                        --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                                        <alain.desilets@...> wrote:
                                        >
                                        > > - Product strategy/design: I believe that there is a
                                        > > component of design which is outside the development process
                                        > > (goal to find the best whole product design)
                                        >
                                        > I agree with this. There is a whole bunch of work that has to
                                        happen before an organisation decides to comission the building of a
                                        particular kind of software.


                                        For me, it's design vs. manufacturing – building the right thing vs.
                                        building it right.

                                        Chef Analogy:
                                        Creating a recipe is exploratory, trial & error (the right thing).
                                        Once you have the recipe, making it is about following the recipe
                                        and doing it efficiently (do it right).

                                        While I think most of the UX camp would agree on "goal to find the
                                        best whole product design," I think this is misguided.

                                        1. The enemy of the good is not the bad. The enemy of the good is
                                        the best. I think design needs to continually ask "is it good
                                        enough?" Optimizing has a very high price.

                                        2. A holistic perspective and an overall design are desirable.
                                        You're not going to know it all up front. Again, the UX community
                                        (those not reading this list) has a lot to gain by embracing an
                                        agile approach.

                                        -Dean
                                      • Arlen Bankston
                                        ... This is a great question; one of the key challenges I ve seen with Agile projects is this (thanks Alain): In XP, there is an assumption that there is a
                                        Message 19 of 22 , Jul 28, 2007
                                        • 0 Attachment
                                          > But I'm still struggling with figure out what the *business customer*
                                          > wants and needs, and what product will best meet those needs. Does
                                          > anyone have hints on how to do this?

                                          This is a great question; one of the key challenges I've seen with
                                          Agile projects is this (thanks Alain): "In XP, there is an assumption
                                          that there is a customer (or customer team) who knows enough about the
                                          business, domain and users in order to guide product development." In
                                          my experience, this has _never_ been completely true (at best,
                                          customers still need validation and refinement of their knowledge), and
                                          in many cases far from it. Thankfully, the iterative nature of Agile
                                          can help to ameliorate this issue somewhat, but addressing the heart of
                                          it is the bread and butter of business process methodologies like Lean,
                                          Six Sigma, Theory of Constraints and the like.

                                          Business customers simply want the product that provides the most
                                          effective return on their investments. There is a handy acronym that
                                          provides high-level categories around typical project
                                          benefits: "IRACIS," for Improve Revenue, Avoid Cost, and/or Improve
                                          Service.

                                          To break these down into more useful details, the "Voices" of the
                                          Customer, Business, Process and have typically been employed. In
                                          practice, these exercises are grab bags of requirements gathering
                                          techniques, ranging from simple interviews to contextual inquiry and
                                          many other tools familiar to most UCD practitioners. They provide
                                          broad feedback which can then be distilled through use of affinity
                                          clustering and tools like the Critical to Quality Tree, Quality
                                          Function Deployment matrices and the like. Where existing processes
                                          are being automated or bolstered, valuable information can often be
                                          gleaned through process mapping and analysis techniques like Value
                                          Stream Analysis (recently, Activity Modeling has shown promise as well,
                                          though my personal experience with it is limited thus far). I would be
                                          happy to provide examples of any of these to interested parties.

                                          The bottom line is that projects should have a clear purpose in mind
                                          before they are ever launched (which is where Lean et al can most
                                          naturally play, providing a reasonably clear definition of the problem
                                          and business context at hand before the quest for the solution begins);
                                          Agile can help to provide a deeper understanding of a problem and a
                                          more targeted solution, but if it's the wrong problem to begin with,
                                          you're still suboptimizing. Failing the proper up-front homework on
                                          the business side, Agile UCD/UED folks can still apply some of these
                                          techniques in the initial discovery phases to ensure that the ship is
                                          launching towards the right general heading.

                                          I've applied the techniques above in a variety of circumstances,
                                          including new customer sign-up processes (mostly Web, plus back-office
                                          process redesign), system access control dashboards and associated
                                          processes, and marketing and print production workflow product
                                          implementation. One key insight has been that business process
                                          analysis (e.g. Lean Six Sigma), business analysis and user experience
                                          design are truly kissing cousins in most cases, and that the roles will
                                          probably converge over the next decade or so, given current trends.
                                          This would be exciting, as it could provide user experience
                                          practitioners an entirely new level of involvement and influence over
                                          not only how projects are done, but which are done and why.

                                          Arlen

                                          PS -- I will be writing several articles and creating a brief training
                                          course about blending Lean and Agile Usability techniques over the next
                                          month, and would love to get this group's feedback, so if you're
                                          interested, keep an eye out.
                                        • Desilets, Alain
                                          ... I m not sure I follow the analogy. In sw building, I don t think it s ever possible to just follow a recipe. You re ALWAYS exploring a solution space, i.e.
                                          Message 20 of 22 , Jul 29, 2007
                                          • 0 Attachment
                                            > Chef Analogy:
                                            > Creating a recipe is exploratory, trial & error (the right thing).
                                            > Once you have the recipe, making it is about following the recipe
                                            > and doing it efficiently (do it right).

                                            I'm not sure I follow the analogy.

                                            In sw building, I don't think it's ever possible to just follow a
                                            recipe. You're ALWAYS exploring a solution space, i.e. doing exploratory
                                            cooking.

                                            That said, even when you are doing exploratory cooking, you better have
                                            an idea of whether what you are trying to create is a cake or an omelet.

                                            That's what I mean by "there is some work that has to be done before
                                            development".

                                            Alain
                                          • Desilets, Alain
                                            ... Great posting. Yes, please share examples of how these techniques can be used. I want to learn. ... Yep. That s EXACTLY the kind of upfront work that I was
                                            Message 21 of 22 , Jul 29, 2007
                                            • 0 Attachment
                                              > Business customers simply want the product that provides the
                                              > most effective return on their investments. There is a handy
                                              > acronym that provides high-level categories around typical project
                                              > benefits: "IRACIS," for Improve Revenue, Avoid Cost, and/or
                                              > Improve Service.
                                              >
                                              > To break these down into more useful details, the "Voices" of
                                              > the Customer, Business, Process and have typically been
                                              > employed. In practice, these exercises are grab bags of
                                              > requirements gathering techniques, ranging from simple
                                              > interviews to contextual inquiry and many other tools
                                              > familiar to most UCD practitioners. They provide broad
                                              > feedback which can then be distilled through use of affinity
                                              > clustering and tools like the Critical to Quality Tree,
                                              > Quality Function Deployment matrices and the like. Where
                                              > existing processes are being automated or bolstered, valuable
                                              > information can often be gleaned through process mapping and
                                              > analysis techniques like Value Stream Analysis (recently,
                                              > Activity Modeling has shown promise as well, though my
                                              > personal experience with it is limited thus far). I would be
                                              > happy to provide examples of any of these to interested parties.

                                              Great posting. Yes, please share examples of how these techniques can be
                                              used. I want to learn.

                                              >
                                              > The bottom line is that projects should have a clear purpose
                                              > in mind before they are ever launched (which is where Lean et
                                              > al can most naturally play, providing a reasonably clear
                                              > definition of the problem and business context at hand before
                                              > the quest for the solution begins); Agile can help to provide
                                              > a deeper understanding of a problem and a more targeted
                                              > solution, but if it's the wrong problem to begin with, you're
                                              > still suboptimizing. Failing the proper up-front homework on
                                              > the business side, Agile UCD/UED folks can still apply some
                                              > of these techniques in the initial discovery phases to ensure
                                              > that the ship is launching towards the right general heading.

                                              Yep. That's EXACTLY the kind of upfront work that I was talking about.

                                              BTW: I think one of the great things about Agile is that if you choose
                                              the wrong problem to solve you will find out earlier than you would with
                                              a waterfallish process. The reason being that you can deploy something
                                              very early on and get feedback on it.

                                              With an agile approach, it seems almost impossible to end up in a
                                              situation where you have invested two years and millions of dollars into
                                              something that was completely the wrong ideai. With agile, you would
                                              probably find out after six months and pull the plug on the project
                                              before too much energy has been wasted into it.

                                              But still, if you can avoid wasting six months of work solving the wrong
                                              problem, and choose the right problem to solve right away, it's much
                                              better.

                                              >
                                              > I've applied the techniques above in a variety of
                                              > circumstances, including new customer sign-up processes
                                              > (mostly Web, plus back-office process redesign), system
                                              > access control dashboards and associated processes, and
                                              > marketing and print production workflow product
                                              > implementation. One key insight has been that business
                                              > process analysis (e.g. Lean Six Sigma), business analysis and
                                              > user experience design are truly kissing cousins in most
                                              > cases, and that the roles will probably converge over the
                                              > next decade or so, given current trends.

                                              I have the same feeling. I know a lot about Ux stuff and they often
                                              bring me a bit towards business issues.

                                              > This would be exciting, as it could provide user experience
                                              > practitioners an entirely new level of involvement and
                                              > influence over not only how projects are done, but which are
                                              > done and why.

                                              Also, it would provide business analysts with Ux expertise as well. One
                                              of the great things about Agile is that it provides a means by which
                                              people with different expertise can interact with each other on a same
                                              project, and learn from each other.

                                              Looking forward to reading your examples in future posts.

                                              Alain
                                            • Jens Ulferts
                                              Hi Jennifer, core was definitely the wrong expression. I hope to have clarified it here: http://tech.groups.yahoo.com/group/agile-usability/message/3593 I
                                              Message 22 of 22 , Jul 31, 2007
                                              • 0 Attachment
                                                Hi Jennifer,

                                                "core" was definitely the wrong expression. I hope to have clarified it here: http://tech.groups.yahoo.com/group/agile-usability/message/3593
                                                I aim for about 30 statements to be judged in my questionair. That should not take more than 10 minutes to answer.

                                                What you are describing with the different approaches at the beginning is a symptom for a difference on a much grander scale. The two have a fields live different cultures. It is apparent in their work style, their language and their values which is the basis of it all. They have incorporated those values during their education and work. Their values have to be accounted for in the processes if a successful combination is to be acchieved.

                                                Hence my approach to let practitioners judge the importance of values for their work. Asking practitioners "How did you do it..." will not yield the results I look for. The answers will again be symptoms, with a limited applicability as project and team changes. But now I come to think of it, I believe that asking this questions once I have the value systems identified might be very interesting. It would be possible to explain why something did or didn't work.

                                                BTW, is it possible for you to send my your master's thesis. Always good to have more research material.

                                                Jens


                                                -------- Original-Nachricht --------
                                                Datum: Thu, 26 Jul 2007 11:06:08 +1200 (NZST)
                                                Von: jennifer ferreira <jenniferferreira484@...>
                                                An: agile-usability@yahoogroups.com
                                                Betreff: Re: [agile-usability] Core Agile and UCD values

                                                > Hi Jens
                                                >
                                                > I have worked on the agile/ucd topic for my masters
                                                > --- good to hear there are others looking into it as
                                                > well. Those are good lists --- just a little long
                                                > don't you think? If you're really talking *core* then
                                                > I'd expect something a little more concise. But
                                                > perhaps that's your aim with the merge.
                                                > Anyhoo, I agree with you that on the surface ucd and
                                                > agile seem like they're very similar and that a
                                                > development team should easily incorporate one with
                                                > the other --- both use iterations, right? However, as
                                                > you have noticed, and I have found digging a little
                                                > deeper, there are fundamental differences that make
                                                > using both a little tricky. And widely open to
                                                > interpretation.
                                                > One major insight for me was the different points of
                                                > view among uc designers and agile practitioners on how
                                                > to start work. The ucd team might insist they can't
                                                > produce anything until they have an overall view of
                                                > the whole product, while the agile developers want to
                                                > start coding right away with the few requirements that
                                                > are known now. How the teams resolve this issue is
                                                > most interesting. Some may feel that they'll let the
                                                > uc designers do some user research up front for now,
                                                > but not feel totally comfortable with it and hope that
                                                > in the future it can somehow be eliminated, while
                                                > others are cool with up front uc design as long as the
                                                > developers don't go changing the design during
                                                > implementation.
                                                >
                                                > Sorry for rambling but this topic fascinates me.
                                                >
                                                > So I think you should definitely follow Liz's advice,
                                                > particularly about speaking to people in the field, to
                                                > hear "Here's how we did it..." The literature's
                                                > allright but the real nuts and bolts of it has to be
                                                > figured out by those on the real-world teams and I
                                                > think that's where the values really become evident.
                                                >
                                                > J.
                                                >
                                                > On 7/26/07, Elizabeth Whitworth
                                                > <elizabethwhitworth@...> wrote:
                                                >
                                                > Hi Jens,
                                                >
                                                > Nice to see someone is working in this
                                                > space...what is your final thesis going to be focused
                                                > on?
                                                >
                                                > I also had trouble associating the 'core' values
                                                > of both agile and UCD to your lists. The priorities
                                                > seem a little mixed up. It would be nice to see you go
                                                > a little deeper into the realities of each field.
                                                >
                                                > Some suggestions for continuing your research:
                                                >
                                                > - do some interviews with practitioners of each
                                                > field (over email or phone if needs be).
                                                > - do more reading, e.g. read the core books (some
                                                > nice overview books to start are Kent Becks Extreme
                                                > programming explained, and Jesse James Garrett's
                                                > elements of user experience);
                                                > read archives from mailing lists such as this one,
                                                > the major agile lists, and the ixda mailing list;
                                                > read the blogs/articles from the major writers in
                                                > each field. for agile you could start with the agile
                                                > manifesto authors. for ucd you can start members of
                                                > this list:
                                                > http://www.usabilityviews.com/userati_rating.html and
                                                > take a look on the web for the less prolific writers
                                                > (but good designers).
                                                > - read through job postings for agile and/or ucd
                                                > jobs.
                                                > - read portfolios of people in the field (look
                                                > for paragraphs outlining principles, goals, vision
                                                > etc. ).
                                                > - attend some agile/ucd workshops or conferences
                                                > (the agile alliance has funding available for students
                                                > researching agile -
                                                > http://www.agilealliance.org/show/1655).
                                                >
                                                > I hope you let us know the results of your work.
                                                > good luck!
                                                > - liz
                                                >
                                                >
                                                >
                                                >
                                                > On 7/25/07, jens.ulferts <jens.ulferts@...>
                                                > wrote:
                                                >
                                                > Hi,
                                                >
                                                > I am currently working to identify the core
                                                > values of UCD and agile. I
                                                > do this as part of my master's thesis.
                                                > The fields have a lot in common, but the more
                                                > I learn about them the
                                                > more differences I spot. Just comparing them
                                                > will yield no real
                                                > results as their aim is different. And the
                                                > worst is, that a lot of
                                                > terms are employed by both fields but with
                                                > different meanings. My
                                                > approach is hence to abstract from the
                                                > concrete methods, tools and
                                                > processes and analyze the inherent values of
                                                > both fields. For that I
                                                > studied literature, a lot of literature, and
                                                > came up with two lists of
                                                > about 20 values each. I want to merge them in
                                                > the end and ask
                                                > practitioners how important each value is for
                                                > their work to succeed.
                                                >
                                                > There are a lot of approches towards merging
                                                > UCD and agile but
                                                > validation is scarce. This is understandable
                                                > as validating a process
                                                > empircally is not feasible. And a one-fits-all
                                                > process is unrealistic.
                                                > Hence my approach of evaluating the values.
                                                > The results can then be
                                                > employed to develop agile+UCD processes that
                                                > fit the project's
                                                > characteristics.
                                                >
                                                > But before I release the final questionnaire I
                                                > would like to validate
                                                > the values I have identified so far. Please
                                                > have a look at them and
                                                > give me some feedback. You are the
                                                > practitioners and my knowledge is
                                                > mostly from literature. So if you feel
                                                > anything missing, unclear or
                                                > not belonging there please let me know. I
                                                > tried to have the values on
                                                > an equal level of abstraction. Of course there
                                                > are values behind this
                                                > but I want each statement to represent values
                                                > clearly belonging to the
                                                > respective field.You will not need very long
                                                > but might even learn what
                                                > you are supposed to do according to literature
                                                > ;)
                                                >
                                                > Core Agile values:
                                                > - Employ dependable feedback as a guide to
                                                > improve work and decisions
                                                > iteratively.
                                                > - Ensure prompt validation of work and
                                                > decisions
                                                > - Receive requirements from those
                                                > knowledgeable in the respective
                                                > field (technology, user, business) of the
                                                > problem domain
                                                > - Gather business needs and use them as
                                                > requirements for the solution
                                                > - Employ concrete communication mediums,
                                                > understood by every party
                                                > involved in the communication
                                                > - Strive for simplicity in all aspects
                                                > - Justify every decision concerning the
                                                > solution with knowledge of the
                                                > problem space
                                                > - Ignore eventualities but those with the
                                                > utmost probability when
                                                > shaping the solution
                                                > - Cover those aspects with planning that are
                                                > interfaces between
                                                > different groups of people
                                                > - Minimize overhead so that everyone can focus
                                                > their effort on the
                                                > process' product - the solution
                                                > - Deliver value as soon as possible and the
                                                > highest value first
                                                > - Adapt the process to the project's
                                                > characteristics
                                                > - Be able to address new and changing
                                                > requirements throughout the process
                                                > - Consider costs when making decisions
                                                > - Have decisions made by those involved who
                                                > have the most profound
                                                > knowledge in the respective domain
                                                > - Employ objective measurements to show
                                                > progress
                                                > - Spread knowledge throughout team members and
                                                > stakeholders
                                                > - Share a vision of the later solution with
                                                > team members and stakeholders
                                                > - Work together as a team to succeed
                                                > - Apply the most suitable technology to create
                                                > the solution and to be
                                                > used by it
                                                > - Ensure that multiple solution options to a
                                                > problem are presented,
                                                > compared and take the most appropriate one
                                                > - Obtain buy-in for the processes values of
                                                > everyone involved
                                                > - Be able to stop the process at multiple
                                                > points and still deliver value
                                                >
                                                > UCD core values:
                                                > - Go for breadth first, then see to the
                                                > details and depths
                                                > - Employ dependable feedback as a guide to
                                                > improve work and decisions
                                                > iteratively.
                                                > - Ensure that multiple solution options to a
                                                > problem are presented,
                                                > compared and take the most appropriate one
                                                > - Aim to optimize the end-user's work
                                                > practices
                                                > - Strives for a solution with which work is
                                                > delightful
                                                > - Create more than just the software to
                                                > address the problem(s)
                                                > - Gather requirements from multiple sources,
                                                > and then consolidate them.
                                                > - Justify every decision concerning the
                                                > solution with knowledge of the
                                                > problem space
                                                > - Have an throughout and holistic
                                                > understanding of the problem domain,
                                                > especially the end-user
                                                > - Gather business needs and use them as
                                                > requirements for the solution
                                                > - Apply the most suitable technology to create
                                                > the solution and to be
                                                > used by it
                                                > - Consider costs when making decisions
                                                > - Adapt the process to the project's
                                                > characteristics
                                                > - Fail early to minimize the need for costly
                                                > corrections
                                                > - Employ concrete communication mediums,
                                                > understood by every party
                                                > involved in the communication
                                                > - Spread knowledge throughout team members and
                                                > stakeholders
                                                > - Strive for simplicity in all aspects
                                                > - Obtain buy-in for the processes values of
                                                > everyone involved
                                                > - Complete an activity before beginning the
                                                > next
                                                > - Work together as a team to succeed
                                                > - Receive requirements from those
                                                > knowledgeable in the respective
                                                > aspect (technology, user, business) of the
                                                > problem domain
                                                > - Share a vision of the later solution with
                                                > team members and stakeholders
                                                >
                                                > With hopes for your valuable answers, best
                                                > regards
                                                >
                                                > Jens
                                                >
                                                >
                                                >
                                                >
                                                >
                                                >
                                                >
                                                > Send instant messages to your online friends http://au.messenger.yahoo.com

                                                --
                                                GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
                                                Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
                                              Your message has been successfully submitted and would be delivered to recipients shortly.