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

Re: [agile-usability] Core Agile and UCD values

Expand Messages
  • 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 1 of 22 , Jul 25 12:28 PM
    • 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 2 of 22 , Jul 25 4:06 PM
      • 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 3 of 22 , Jul 26 2:49 AM
        • 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 4 of 22 , Jul 27 11:32 AM
          • 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 5 of 22 , Jul 27 11:54 AM
            • 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 6 of 22 , Jul 27 11:58 AM
              • 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 7 of 22 , Jul 27 12:10 PM
                • 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 8 of 22 , Jul 27 1:14 PM
                  • 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 9 of 22 , Jul 27 1:30 PM
                    • 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 10 of 22 , Jul 27 1:32 PM
                      • 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 11 of 22 , Jul 27 1:49 PM
                        • 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 12 of 22 , Jul 27 2:56 PM
                          • 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 13 of 22 , Jul 27 11:29 PM
                            • 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 14 of 22 , Jul 28 6:47 AM
                              • 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 15 of 22 , Jul 28 8:02 AM
                                • 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 16 of 22 , Jul 28 9:41 AM
                                  • 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 17 of 22 , Jul 29 11:06 AM
                                    • 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 18 of 22 , Jul 29 11:14 AM
                                      • 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 19 of 22 , Jul 31 1:11 AM
                                        • 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.