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

RE: [agile-usability] Digest Number 299

Expand Messages
  • Desilets, Alain
    The creative solution was not what I would consider whiz-bang or on the cutting edge of technology, since we have been doing it since the 1950 s at least. I
    Message 1 of 5 , Dec 9, 2005
    • 0 Attachment
      The creative solution was not what I would consider "whiz-bang" or on
      the cutting edge of technology, since we have been doing it since the
      1950's at least. I simply proposed to the company that they require
      their systems to re-use every element of data that was already known to
      any system, and dismantle the beleaguered data entry team altogether.

      -- Alain:
      Great story!

      What it illustrates is the importance of choosing the right problem to
      solve (in your example, "minimize data re-entry by integrating different
      systems" rather than "make data entry easier by reimplementing the
      interface for existing systems"). This is an area where upfront work
      pays off tremendously. If you choose the wrong problem to solve, you
      will end up with something useless no matter what development
      methodology you use.

      That said, in my experience choosing the right problem to solve is
      usually not that cut and dry (especially when developping highly
      innovative products like in startup companies or in research
      organisations where I work). This is where Agile methodologies can help.

      In your example, suppose cost of integrating different systems was
      estimated to be 100 times higher than the cost of reimplementing the
      interface for existing systems. In such a situation, "make data entry of
      existing systems easier" might still have been a contender. In a
      situation like this, rather than embark on a 3 year integration project
      and hoping that you chose right, you might start out with a 3 month
      spike. For example you might pick two highly used systems that also have
      highly redundant data, and try to integrate parts of their databases
      together. Then you would deploy that into operation and evaluate its
      impact.

      This would yield valuable information to help you decide whether or not
      system integration is indeed the right choice. You might find out that
      the cost of integration is lower than you expected, or on the contrary,
      higher. Or you might find that integrating data from those two systems
      did not really decrease data entry time that much because the old
      practice of copying and pasting from different systems was relatively
      efficient after all.

      After that 3 month spike, you might decide that system integration is
      still the way to go and embark on another 3 month release plan in that
      direction. Or, you might decide that "make data entry easier" is
      starting too look more and more attractive and instead try a 3 month
      spike in that direction. For example, you might try to put links or
      buttons in one system, that lead you to appropriate places in other
      systems, to make copying and pasting of data more efficient. This too
      would yield valuable information. You might find that in the same 3
      months, this approach allowed you to decrease data entry time for 5
      different systems as opposed to the the 2 systems that you tried to
      integrate in the first spike. Or you might find that this "kludge"
      simply does not help with data entry time, and that you should indeed
      return to the systems integration approach. Or you might find that what
      makes the most sense is to use the system integration approach for the
      most tightly coupled (in terms of shared data) and most frequently used
      systems, and use the linking kludge for all others.

      In my experience, this kind of information is very hard to get upfront
      without having had a chance to learn from the experience of deploying
      running software in the production environment.

      As a researcher working on innovative new products like: "a system that
      records the audio of meetings and allows participants to browse and
      search it after the fact to refresh their memory about what was said", I
      find the hardest part of my work is indeed, choosing the right problem
      to solve. I used to agonize for months over this kind of decision,
      talking to lots and lots of people, floating white papers around, etc...
      And in spite of this, I still got it wrong and only found out after
      sinking a year or more into solving an irrelevant problem. Now, I still
      spend a lot of time talking to people and floating white papers (but
      less than I used to), but once I think I have a good thing, I start out
      by implementing the smallest and simplest version of the concept
      possible. Then I look for places to deploy it and get feedback.
      ----
    Your message has been successfully submitted and would be delivered to recipients shortly.