RE: [agile-usability] Digest Number 299
- 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.
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
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.