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

Re: [agile-usability] Choice modeling and Agile?

Expand Messages
  • Adi The
    Jeff, Thanks for sharing the information about the choice modeling. One of our researchers conducted a similar workshop session called Idea Shopping after
    Message 1 of 12 , Jul 2, 2005
    • 0 Attachment
      Jeff,
      Thanks for sharing the information about the choice modeling.
      One of our researchers conducted a similar workshop session called
      "Idea Shopping" after
      preceding ethnographic field work results analysed and synthesised.
      For the "Idea Shopping" workshop, several UI paper prototypes, such as
      login UI prototypes, were prepared.
      Each prototype was assigned some "Kroner" values (Scandinavian
      currency) based on the analysis and synthesis of field work results
      and
      each workshop participant was given some "pocket money" to shop for
      the prototypes.
      The workshop participants could shop until they spent all their "money".
      During the shopping, the participants could provide instant feedback,
      ask questions, have dialogues with the other shoppers, etc.
      The results of the workshop were then used to narrow down the choices
      and refine the prototypes.

      --
      Adi B. Tedjasaputra

      IT and User Experience Manager
      TRANSLATE-EASY
      :: RFID and Human-centred Design Innovation Centre in Asia ::
      http://TRANSLATE-EASY.com

      Menara Kadin Indonesia 30th Floor
      Jl. Rasuna Said Block X-5, Kav 2-3
      Jakarta 12950
      INDONESIA

      Direct. +45 - 20 27 77 53
      Fax. +45 - 28 17 09 78
    • Kevin Narey
      ... A curious statement. Do you find that users of software, built using agile methods, enjoy it when they can t use the software because the architect of that
      Message 2 of 12 , Jul 4, 2005
      • 0 Attachment
        Ron wrote:

        >Analysis kills spontaneity

        A curious statement.

        Do you find that users of software, built using agile methods, enjoy
        it when they can't use the software because the architect of that
        software, as a result of not performing a prior phase of analysis (and
        design) 'spontaneously' second guessed what their goals were? Can I
        also ask what your views on innovation without analysis/research are?

        //else

        If you're looking for an approach to determining ROI you might want to
        view Jared Spool's article:

        http://www.uie.com/articles/cost_of_frustration/

        Kevin
      • Desilets, Alain
        Well, of course they should be able to express the ROI. But I d suggest that it s not necessary . Given two features, if they can decide which one to do
        Message 3 of 12 , Jul 4, 2005
        • 0 Attachment
          Well, of course they "should" be able to express the ROI. But I'd suggest that it's not "necessary".

          Given two features, if they can decide which one to do first, that's often "enough".

          Sometimes folks have trouble doing that. I help them along by picking something obviously valuable and something obviously dull. (There are always features that qualify.) Then I suggest that we do the dull one first, and defer the valuable one for a long time. They call me an idiot, and get about the business of deciding what to do next.

          -- Alain:
          Great suggestion Ron! I'll have to remember that.

          Most people (including myself) can't quantify things in abolute terms. But they can usually rank things one against the other.
          ----
        • Jim Kauffman
          That s one great thing about Agile, if it s being done right. Customers get lots of chances to change their priorities along the way. Jim K.
          Message 4 of 12 , Jul 4, 2005
          • 0 Attachment
            That's one great thing about Agile, if it's being done right. Customers get
            lots of chances to change their priorities along the way.


            Jim K.


            > -----Original Message-----
            > From: agile-usability@yahoogroups.com
            > [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
            > Sent: Monday, July 04, 2005 5:52 PM
            > To: 'agile-usability@yahoogroups.com'
            > Subject: RE: [agile-usability] Re: Choice modeling and Agile?
            >
            > Well, of course they "should" be able to express the ROI. But
            > I'd suggest that it's not "necessary".
            >
            > Given two features, if they can decide which one to do first,
            > that's often "enough".
          • Ron Jeffries
            ... Actually, Henri Amiel wrote that, and the complete quote, randomly ... It might be wise not to read too much into the workings of a random number
            Message 5 of 12 , Jul 5, 2005
            • 0 Attachment
              On Monday, July 4, 2005, at 5:35:22 PM, Kevin Narey wrote:

              > Ron wrote:

              >>Analysis kills spontaneity

              Actually, Henri Amiel wrote that, and the complete quote, randomly
              selected by my email client, is:

              >> Analysis kills spontaneity.
              >> The grain once ground into flour germinates no more. -- Henri Amiel

              > A curious statement.

              It might be wise not to read too much into the workings of a random
              number generator. It might be more fruitful to comment on what I
              wrote, not on what Mr Amiel wrote. However, your questions below are
              answerable. These are my answers: I don't know what Mr Amiel would
              say, had he not unfortunately passed away in 1881.

              > Do you find that users of software, built using agile methods, enjoy
              > it when they can't use the software because the architect of that
              > software, as a result of not performing a prior phase of analysis (and
              > design) 'spontaneously' second guessed what their goals were?

              Well, I find that that doesn't happen, and the form and tone of the
              question makes me want to recommend a bit more study of agile
              methods. Here are some reasons why:

              Agile methods do analysis all the time, not just in a prior phase.

              Agile teams work with the users of the software, addressing only
              features that those users ask for, in the order they are
              requested. The goals are explicit, discussed continuously.

              The software is delivered frequently, every couple of weeks, or
              every month, so that the customers can see it, use it, test it in
              any way that they see fit.

              Agile teams do design all the time, not just in a prior phase.

              Agile teams start with a simple design at the beginning, enough to
              support the few features they need to deliver at the beginning. In
              order to sustain continuous delivery

              Agile teams generally do not have an individual designated as "the
              architect".

              Agile teams generally share the conventional duties of development
              teams, analysis, architecture, design, testing, coding, and so on.
              Certainly each team will have individuals who are more or less
              skilled in these areas, but it is rare to have specific
              individuals called out into roles.

              Agile teams value spontaneity, but also discipline.

              Agility is about noticing what's going on and responding to it.
              But spontaneity alone, the late Mr Amiel notwithstanding, does not
              accomplish much. That's why Agile teams follow a discipline that
              keeps them in touch, at all times, with the customer and what the
              customer wants.

              > Can I also ask what your views on innovation without
              > analysis/research are?

              Well, briefly, if you can imagine that, I think that innovation is
              at its highest when one maintains a bit of distance from "reality",
              but is quite aware of all that is going on. If by "analysis" we mean
              "paying attention", if by "research" we mean "looking around", then
              they're quite valuable to innovation.

              If on the other hand we mean something more formal, rigid,
              stratified, phased, then I would likely begin to come down more on
              the side of the sadly departed Henri-Frederic.

              Analysis and research, in the conventional sense, are likely to lead
              to refinement. I would be less sanguine about their leading to true
              innovation. But there's always a spectrum, a continuum: innovation
              is very likely a soup made up of many ingredients.

              > //else

              > If you're looking for an approach to determining ROI you might want to
              > view Jared Spool's article:

              > http://www.uie.com/articles/cost_of_frustration/

              It's an interesting article. As my original response said, at least
              twice, I'm all for knowing ROI. I'm also pointing out that projects
              can proceed on the basis of less detail, specifically users' ability
              to choose between alternatives, even when they don't have detailed
              numbers.

              Ron Jeffries
              www.XProgramming.com
              Perhaps this Silver Bullet will tell you who I am ...
            • grahamastles
              While the emphasis on finding a dollar ROI for each feature may be an idea to make the customer more aware of the resources she is spending, I think that there
              Message 6 of 12 , Jul 5, 2005
              • 0 Attachment
                While the emphasis on finding a dollar ROI for each feature may be an
                idea to make the customer more aware of the resources she is spending,
                I think that there is a risk to fall into the same legalistic trap
                that traditional project management does when it treats estimates as
                commitments and a schedule as a prediction.

                It seems to me that the core purpose behind any prioritization is to
                work on the most important things first. For this need, a ranking
                gives you 90% of the value with 10% of the work.

                Thus, I think that the discussion on "feature ROI" should be part of a
                pep-talk in the initial project definition phase, with occasional
                reminders during the planning game, but the tough work required to get
                an actual ROI for each feature sounds non-agile in the sense that it
                is "up-front work" that does not produce working code that the user
                can actually approve. Since priority ranking is a cheaper alternative
                that can get you to actual coding quicker, I would recommend keeping
                feature-ROI as a conceptual construct and not a mathematical process.

                In any case, if we go down this path, Agile would require having a
                feedback process where you actually do testing to determine if your
                calculations corresponded to reality, so that you could improve the
                process on the next round. That sounds like a very long feedback loop
                to me, and I wonder if the ROI is positive at all, and I certainly
                think that most of our teams would find a higher ROI from implementing
                or improving other aspects of our craft.
              Your message has been successfully submitted and would be delivered to recipients shortly.