Agile In Action - Theory and Concepts

On 16 Jun 2006 20:34:59 -0700, "Vladimir Levin" <vlad.levin{}>
wrote:

>This is a post from my blog (vladimirlevin.blogspot.com). I welcome
>comments.
>
>I don't know to what extent the notions of up-front requirements
>****ysis and design are still being actively used these days, but I've

Vlad,

I work as an independent contract programmer. I first became intrigued
with XP/Agile in 1999 (?) after reading an article in IEEE Software.
Since I have worked at three different clients since then and am now
seeking new work, I have seen little requirement for this knowledge.
In fact, a quick search on DICE would demonstrate that it has not been
as widely adapted as some seem to think. If fact, it seems only a
small percentage of shops have adopted these practices. Even in the
organizations I've been in that are well aware of XP/Agile, none are
taking any serious effort to adopt it.

One must wonder why, if this is the silver bullet claimed by the
zealots, that is has not been more widely adopted after so many years.

>heard a lot of debate on the subject over the past few years. I'm
>currently working on an agile project and today I had a good experience
>in which three of us, a customer and two developers, worked together to
>flesh out a requirement in a way that simply would not be possible in a
>more traditional environment heavy on up-front requirement preparation.

Why wouldn't it be possible? I don't see it. Nothing you have
described precludes the ability of an RE from identifying the three
types of ****ysis you describe. In fact, I would say it would be an RE
who failed to ask the appropriate defining questions. As for the UI
design, that too is completely doable. Whether or not people thought
creatively has little to do with the methodology used. In fact, I
would posit that quick drawings on paper or whiteboard could elicit
exactly the same response, then it could be formally defined in a
document.

Your conclusion, it seems to me, seems unwarranted.

<snip description of experience>


Bill
------------------------------------------
Bill Turner

A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff


Views expressed are entirely my own and only coincidentally represent those of other persons or entities.

bill turner wrote:

> Your conclusion, it seems to me, seems unwarranted.
>
> <snip description of experience>

Welcome to USENET, Vlad! Your report of specific first-hand experiences gets
snipped in favor of idle gainsaying.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

bill turner wrote:

> I have seen little requirement for this knowledge. In fact, a quick search on
> DICE would demonstrate that it has not been as widely adapted as some seem
> to think. If fact, it seems only a small percentage of shops have adopted these
> practices.

That's very possible. Since I make an extra effort to work on agile
projects, I am very likely to think they are more pervasive than they
really are!

> Why wouldn't it be possible? I don't see it. Nothing you have
> described precludes the ability of an RE from identifying the three
> types of ****ysis you describe. In fact, I would say it would be an RE

Good question. Here's my attempt at an answer: From my point of view,
the problem is one of time and perspective. For any requirement, one
can always ask "Is there anything more? Anything different? Anything
you haven't thought of?" as a generic question. One doesn't even need
an RE. One could write a computer program that responds that way to any
requirement that you input into it. In fact, it is something I try to
do, both in the software world and when I am leaving on a trip! I
suspect that in many cases the user would simply say "As far as I know
right now, no." I've had quite a lot of experience eliciting
requirements, and I have often witnessed the scenario where I ask
repeatedly whether a particular difficult feature will ever be needed
and repeatedly get the answer "no" only to see the feature pop up
later. Sometime's it's exactly the feature I asked about, and sometimes
there's a spin on it that would be difficult for anyone without
extremely deep knowledge and foresight to come up with. Anyhow, my
point is this: All of the stories we develop on our project go through
a review committee of subject experts before reaching the developers,
and yet it is often the case that stories are modified as in my example
during development. In my opinion (and it's just an opinion), one
cannot think of every possible angle on a story, and furthermore,
trying to do so is probably not a good idea (because the amount of time
and effort it takes to get there is prohibitive). When you're dealing
with a real, complex, application, the number of combinations gets
large, and it becomes almost impossible to cover things ahead of time.
If one thing is not missed, then something else will be. It reminds me
of diagonalization, where you can always add another infinitely long
binary string to the list, but then you look anew at the diagnonal, and
the complement is still not in the list, ad infinitum. Hence the set of
all infinitely long binary strings is uncountable.

In software, I believe there is this principle at work: For every new
requirement, there will always be a number of things that are vague,
can be interpreted in a several ways, or may not be considered until
the story is in development, or even afterward.

My point was to try to show how three people worked together to satisfy
a requirement. I introduced a requirement that had been missed because
it was not a common case and because our experts only have so much time
to develop stories. The GUI expert had some additional input that
neither I nor the customers had thought of. There is a natural
temptation to think that some more skillful forethought could have
achieved the same result. Personally, I don't think so, at least not in
most cases. It would be interesting to do some experiments with
requirement gathering to see how good up-front elicitation of
requirements really is.



> who failed to ask the appropriate defining questions. As for the UI
> design, that too is completely doable. Whether or not people thought
> creatively has little to do with the methodology used. In fact, I
> would posit that quick drawings on paper or whiteboard could elicit
> exactly the same response, then it could be formally defined in a
> document.




> Your conclusion, it seems to me, seems unwarranted.
>
> <snip description of experience>
>
>
> Bill
> ------------------------------------------
> Bill Turner
>
> A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
>
>
> Views expressed are entirely my own and only coincidentally represent those of other persons or entities.

Phlip wrote:
> Welcome to USENET, Vlad! Your report of specific first-hand experiences gets
> snipped in favor of idle gainsaying.

I think you might be ready for a break from usenet Seriously though:
First of all, I don't expect people to just fall over in recognition of
how right I am. I want people to ask questions and disagree. As long as
we can all do so in a respectful way, then we're all learning. I didn't
see anything in Bill's reply that struck me as gainsaying. His way of
looking at things is very natural. I had a long debate about this
subject with a student in one of my youth software courses. At 14, he
was convinced that rigorous ****ysis was the way to go. I don't think
even the bugs that he was constantly chasing in his project really
disuaded him from his point of view! Anyway, he's a very bright kid and
we had good discussions. Second: If there are people who's motivations
really are malicious, to discredit what I'm saying just for the heck of
it or out of some kind of deep-seated hatred of agile methodologies,
fine. All I can do is hope that people will largely take any postings I
make in the spirit that I intended: To share my experiences, help other
people in the software world, and also learn myself from responses.

Vladimir Levin wrote:
> bill turner wrote:
-snip-
> > Why wouldn't it be possible? I don't see it. Nothing you have
> > described precludes the ability of an RE from identifying the three
> > types of ****ysis you describe. In fact, I would say it would be an RE
>
> Good question. Here's my attempt at an answer: From my point of view,
> the problem is one of time and perspective. For any requirement, one
> can always ask "Is there anything more? Anything different? Anything
> you haven't thought of?" as a generic question.

afaict Your realization that there could be a third case which the
story didn't cover isn't necessarily linked to implementing the story,
but is necessarily linked to carefully reviewing the story and having
other domain knowledge.

A N Other person may just have gone ahead and implemented A & E.


(But now I'm curious - are the averaged ge factors possibly averaged
from both A and E ge factors, or just from ****ysis; does the
additional category make any difference in how the information is
interpreted or is the useful distinction between a ge factor derived
directly from ****ysis and a ge factor from some other source?)

Isaac Gouy wrote:
> A N Other person may just have gone ahead and implemented A & E.

That's a good point. In the end, that's effectively what happened,
since for "C" that's the only information we provide - just that it's
calculated.

> (But now I'm curious - are the averaged ge factors possibly averaged
> from both A and E ge factors, or just from ****ysis; does the
> additional category make any difference in how the information is
> interpreted or is the useful distinction between a ge factor derived
> directly from ****ysis and a ge factor from some other source?)

I'm not sure. I think the reality is that the average could indeed come
from both A and E ge factors. For any given measurement, it comes down
to how much information is available. Sometimes there's a useful
****ysis and sometimes there isn't. As far as I know, the users don't
care about the distinction you refer to - yet. One thing I've found
about the kind of project I am currently on, where we have more than 10
full-time subject matter experts preparing requirements, is that they
often don't agree about such matters. Some of them don't even seem to
care about providing the context information "A", "E" and "C". Others
think it's important to show the distinction in the app.

Vladimir Levin wrote:

> ... I had a long debate about this
> subject with a student in one of my youth software courses. At 14, he
> was convinced that rigorous ****ysis was the way to go. I don't think
> even the bugs that he was constantly chasing in his project really
> disuaded him from his point of view!

I ... don't think I need to defend you much. ;-)

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

Vladimir Levin wrote:
> Isaac Gouy wrote:
> > A N Other person may just have gone ahead and implemented A & E.
>
> That's a good point. In the end, that's effectively what happened,
> since for "C" that's the only information we provide - just that it's
> calculated.
>
> > (But now I'm curious - are the averaged ge factors possibly averaged
> > from both A and E ge factors, or just from ****ysis; does the
> > additional category make any difference in how the information is
> > interpreted or is the useful distinction between a ge factor derived
> > directly from ****ysis and a ge factor from some other source?)
>
> I'm not sure. I think the reality is that the average could indeed come
> from both A and E ge factors. For any given measurement, it comes down
> to how much information is available. Sometimes there's a useful
> ****ysis and sometimes there isn't. As far as I know, the users don't
> care about the distinction you refer to - yet. One thing I've found
> about the kind of project I am currently on, where we have more than 10
> full-time subject matter experts preparing requirements, is that they
> often don't agree about such matters. Some of them don't even seem to
> care about providing the context information "A", "E" and "C". Others
> think it's important to show the distinction in the app.

And that's ordinary - we can do a superset, we can make an arbitrary
choice between them, we can appoint one of the to be /the/ customer, we
can ask them to justify their opinion, we can weight each feature with
an opportunity cost (you can have X or Y - choose).

The way I heard your story, there was something a little strange - it
sounded like as part of implementing something we'd added another
feature which might or might not be useful. iirc That's one of the
criticisms made of up front requirements.

bill turner wrote:

> In fact, a quick search on DICE would demonstrate that it has not been
> as widely adapted as some seem to think.

I just heard, on KFOG in San Francisco, an advertisement requesting resumes
for "Agile" IT personnel. Note that ain't CraigsList. A radio advertisement
is an expensive, high-end investment, on the same level as, say, beer or
cars.

(The quality of search engine may also be a factor.

They plugged this:

http://www.solutionsiq.com/agile_dev_services.html

Of course one always has to work to detect the difference between buzz-word
compliance and "getting it", but I doubt the Bay Area will have much problem
with that.

From the page (for anyone claiming there's no statistics available for such
things):

KEY BENEFITS OF AGILE:
Agile development results in reduced time, costs and solid ROI according to
****ysis from Forrester Consulting, 2004 and Agile Methodologies Survey
Results, Shine Technologies Pty Ltd, 2003

57% reduction in costs compared to other IT solutions for similar complex
projects.

62% reduction in effort compared to alternatives, including in-house
development and previously employed consultants.

80% reduction in critical defects

60% reduction in overall defects

93% stated productivity was better / significantly better

88% stated that quality was better / significantly better

83% stated that business satisfaction was better / significantly better

--
110% Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!