1257Re: [agile-usability] Re: Choice modeling and Agile?
- Jul 5, 2005On Monday, July 4, 2005, at 5:35:22 PM, Kevin Narey wrote:
> Ron wrote:Actually, Henri Amiel wrote that, and the complete quote, randomly
>>Analysis kills spontaneity
selected by my email client, is:
>> Analysis kills spontaneity.It might be wise not to read too much into the workings of a random
>> The grain once ground into flour germinates no more. -- Henri Amiel
> A curious statement.
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, enjoyWell, I find that that doesn't happen, and the form and tone of the
> 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?
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
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
> Can I also ask what your views on innovation withoutWell, briefly, if you can imagine that, I think that innovation is
> analysis/research are?
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.
> //elseIt's an interesting article. As my original response said, at least
> If you're looking for an approach to determining ROI you might want to
> view Jared Spool's article:
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
Perhaps this Silver Bullet will tell you who I am ...
- << Previous post in topic Next post in topic >>