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

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

Expand Messages
  • Ron Jeffries
    Jul 5, 2005
      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 ...
    • Show all 12 messages in this topic