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

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

Expand Messages
  • 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 1 of 22 , Jul 26, 2007
    View Source
    • 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 2 of 22 , Jul 27, 2007
      View Source
      • 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 3 of 22 , Jul 27, 2007
        View Source
        • 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 4 of 22 , Jul 27, 2007
          View Source
          • 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 5 of 22 , Jul 27, 2007
            View Source
            • 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 6 of 22 , Jul 27, 2007
              View Source
              • 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 7 of 22 , Jul 27, 2007
                View Source
                • 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 8 of 22 , Jul 27, 2007
                  View Source
                  • 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 9 of 22 , Jul 27, 2007
                    View Source
                    • 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 10 of 22 , Jul 27, 2007
                      View Source
                      • 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 11 of 22 , Jul 27, 2007
                        View Source
                        • 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 12 of 22 , Jul 28, 2007
                          View Source
                          • 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 13 of 22 , Jul 28, 2007
                            View Source
                            • 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 14 of 22 , Jul 28, 2007
                              View Source
                              • 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 15 of 22 , Jul 29, 2007
                                View Source
                                • 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 16 of 22 , Jul 29, 2007
                                  View Source
                                  • 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 17 of 22 , Jul 31, 2007
                                    View Source
                                    • 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.