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

Re: Core Agile and UCD values

Expand Messages
  • 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 1 of 22 , Jul 27, 2007
    • 0 Attachment
      Hello,

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

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

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

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

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

      Good luck,

      mTp

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

            - George

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

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

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

              I hope this adds some clarity.

              mTp

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




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

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

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

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

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

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

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

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

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

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

                  Thx.

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

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

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

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

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

                    >I hope this adds some clarity.

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

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

                      > - I split the design process in 2:

                      I do, too.

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

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

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

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

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

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

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

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

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

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

                      Dale

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

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

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

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

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

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

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

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

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

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

                          Of

                          B) an open wikipedia like terminology database

                          Or

                          C) An integrated IDE-like environment for translators

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

                              Arlen

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

                                I'm not sure I follow the analogy.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                  Looking forward to reading your examples in future posts.

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

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

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

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

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

                                    Jens


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

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

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