Re: [agile-usability] Inside Steve's Brain
- Hello, Robert. On Tuesday, June 10, 2008, at 8:03:31 AM, you
> Ron Jeffries wrote:With all due respect, I'm not at all sure that you do understand,
>> I meant that Agile Software Development is about software
>> development. It begins when the project begins, with software pretty
>> much that day. If someone wants to spend time dreaming or designing
>> or such prior to authorizing the software project, that is, in my
>> opinion, outside Agile.
> So I guess this is a similar resolution to another recent discussion
> on this list. I can understand the distinction you want to make, but
> I don't think it's very helpful, especially on this list.
not entirely because we don't agree, although that might be playing
into it, since I suffer from that disability where one thinks that
smart people must ultimately agree. :-)
> I understood "software development" to be a broad inclusive term, andNo, not just programming. But I do mean the term to refer to the
> so covered, for example, UI designers: but you seem to be using it
> simply to mean "programming". Is that right?
course of actual development of software according to Agile
One of the essentials of Agile Software Development is "early and
continuous delivery of valuable software." As such, it seems to me
that while there might be lots of usability activity going on, and
that would be just wonderful, there //must// be software being
developed, or it isn't an Agile project at all.
Suppose that software is not being written now, but we are doing the
envisioning of software, the creation of fantasies about software,
imagining software, deciding whether or not to write software or
what software to write, or other just plain thinking about software.
What is that activity? I'm not sure. But it isn't Agile Software
Development because No Software.
Mind you, those may be important, even critical activities prior to
actually starting the project. It's just that since Developing
Software is a sine qua non to doing Agile Software Development,
activities like this, in the absence of Developing Software can't
possibly be part of an Agile project.
Now more to what I take to be our purpose here, these activities
certainly are also vitally important /during/ the project.
In my opinion, until a team is producing "Done" software at the end
of every iteration(*), it cannot claim to be doing "Agile Software
Development", or at least cannot claim to be doing it very well.
So what might go on before that could be incredibly wonderful and
valuable, and it could be a critical precursor to the project, but I
don't see how it can be Agile Software Development without ...
> It seems unreasonable toYes, of course UI design work strongly affects the software. No one
> me, as UI design work strongly affects the software.
is denying that. UI design might be critical to its success. Done
//inside// the Agile cycle, it can and should be a key part of Agile
Done //outside// the Agile cycle, I don't see how UI work could
possibly be part of Agile Software Development, nor why we would
want it to be.
> It also seems unhelpful to put designing in a group with dreamingPart of designing is often done prior to authorizing the project,
> and authorizing.
and prior to actually initiating the project. As such it //is// in a
group with envisioning, authorizing, dreaming, and anything else we
do before we start actually doing the project. I don't have anything
against dreaming: I just distinguish it from other forms of work,
notably production of software.
Perhaps we have some disagreement on when an Agile project starts? I
suggest that it starts N days before the first delivery of software,
where N is the length of the iterations. (And no, I don't favor a
long zeroth iteration.)
Now "The XYZ Project" might be deemed to be started a year
beforehand, with people figuring out business models and wonderful
designs of all kinds. But that ain't Agile. With Agile, there
//must// be software. I don't see any way out of that without
completely redefining what we said at Snowbird.
> Further, it seems silly to put UI design outside ofThis argument seems to me to be specious. UI design may be "agile",
> "Agile", when it has a process that is agile, and had it long before
> that was common in programming.
although it isn't always. But if we are talking about "Agile", it
seems to me that we need to talk about what was set forth in
Snowbird, and that includes the delivery of software.
> In a group on "agile usability", you seem to be suggesting that theNo, no, no. I am amazed at my apparent inability to express a simple
> main element of the process should be programming. I don't see how
> that makes sense, when you have not addressed how usability happens.
idea. A //critical// element of Agile Software Development is the
Development of Software. If there is no Software Development going
on, then there is no noun phrase for Agile to modify and therefore
there is no Agile Software Development.
The programming has an interesting aspect. The product cannot exist
without it, and in that sense it is a sine qua non. However, a great
idea or great design, or even a market blitz can sometimes transcend
a cruddy implementation. (Ladies and gentlemen, I give you:
We must have programming (in one form or another). It's critically
important -- and yet it does not o'ershadow other critical elements.
> I still see this area as new, and I don't think there is a widelyFor our purpose here, I do want a single strong distinction: Agile
> accepted way to bring UI design and usability testing together with
> programming in an agile process. You seem to want to some strong
> distinctions, yet I haven't seen any evidence that your approach leads
> to good software that includes good UI design.
Software Development is characterized by the regular iterative
production of software.
I'm not here to offer evidence. I don't know the answer to the
question. I'm just trying to keep us focused on a key question,
which is how to get good UI design //into// Agile Software
Development, rather than (for example) how to do it outside the
loop. To the extent that UX people try to do their work outside the
loop, I think we and they will lose.
> Have I missed something? Or is this word-play?My answers here are: "Yes, I think so. No, emphatically not."
It is common in specialty groups like this one (and in groups with
names like "agile modeling" and "agile testing") to fall back into
looking at a way of doing these specialties "outside" the Agile
iterative cycle. The real value will come from those who recognize
that to use one's special expertise best in an Agile Software
Development project, one has to get //inside// the iteration.
Do you want to do UI in an Agile project? Super! If the Agile
project starts today, then two weeks (**) from today, and every two
weeks after that, we need real, value-bearing, software. "Agile
Usability" needs to get on board with that. Some folks, notably Jeff
Patton, are on board with that. Keep it coming!
Speculation or experimentation - which is more likely to give the correct answer?
(*) There are branches of "Agile" who think that iterations are not
necessary. They agree that frequent delivery of value-bearing
software is necessary, and generally deliver more frequently, not
(**) Or one week, or a month. Some short regular cycle. Shorter
> But I am against research just been done at the before the project starts and then that is it, andI agree totally. Ethnographic user research should aim at understanding the user THROUGH understanding how they work today. The aim is not to just replicate the way they work today.
> totally against design been fixed before the project starts.
> The challenge is that the research is descriptive and not predictive, and is often used in a
> prescriptive manner. I have been involved in some projects where there has been the assumption that
> the consumers behaviour remains fixed.
Here's an example taken from my contextual inquiries with translators.
We noticed that NOT ONE OF THEM used collaboratively built linguistic resources like ProZ, Wiktionary and OmegaWiki. That's not necessarily to say that collaboratively built resources would not be useful to them and that you should not build them. It may be that collaboratively built resources have just not made it into their world right now.
However, the CI observation gives us many useful information about how a collaborative resource should be built to serve the needs of translators. For example, we noticed that translators at least pay a lot of lip service to "trustworthy sources". So you know that with a collaborative resource where pretty much anybody can write content, you are up against a perception of lack of trustworthiness. At the same time, we noticed that when translators can't find a solution in trusted resources (ex: the terminology database of the Gov of Canada), they have no qualms about looking in less trustworthy resources, for example by doing a search on the internet. So, it could be that translators will be willing to use collaborative resources if they have more coverage than "trusted" ones. As the translators use the resource more and more, they will notice that they quality is high, and may get over the lack of trust barrier.
But all of that is of course hypothetical. They are hints that help you narrow down the search space. But a case like this, those hints are particularly important, because a wiki cannot be tested with individuals. It can only be realistically tested with a large community. It's like the WWW. You couldn't test the concept of the WWW without having a network of millions of interlinked pages already (although you could test the concept of a web browser on individuals). So, the only way to realistically test a wiki is to deploy it and see what happens. So the turnaround time for validating your decisions is longer. Hence the importance of having good a-priori data to guide your initial choices. Of course if you deploy something and it doesn't work, you should listen to what the community is telling you through their actual use of the real thing.
> There is research that uses sweeping statements like from Broadbent and Cara's NEW ARCHITECTURES OFI agree that behaviour which is specifically tied to technology can change rapidly, hence the need to conduct this type of research continuously.
> INFORMATION Paris 2002.
> "During the past four years, we have carried out hundreds of observations of people using the Web."
> which leads them to a conclusion that
> Most light users have very stereotypical behaviours: after six months of usage of the Internet they
> stop even trying to do searches through a search engine and consult systematically the same six or
> seven sites.
> Broadbent and Cara's observations tell us about the time before google.
However, CI will also yield information that is pretty much independent of technology. For example, we have noticed that translators do not blindly trust ANY sources (even official ones like Gov of Canada terminology database), and will systematically consult at least two different resources to resolve any given translation difficulty. The only exception to that is when the translator hast the proper translation at the tip of his tongue, and uses lookup in a single resources to remember it. I'm being told that this behaviour was there already when translators used paper dictionaries only.
> My argument is that any new product changes the user behaviour, and therefore you need to get the newYes, you should do that.
> product in front of the user as soon as possible, so that you can feed back the users behaviour back
> into the next iteration.
> Research needs to be carried out before so that you can set up the goals of the project, and theYep.
> stories. It needs to be done during development so that you can feed back the user behaviour back
> into the product, and then after to find out when you need to make the next version.