Agile In Action

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
analysis and design are still being actively used these days, but I've
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.
Since this is an example from the real world, I'll be using
project-specific terminology, but I hope to make the general sense of
what's going on clear to anyone reading this blog. If you're reading
this and have something to say that may clarify matters, I encourage
you to e-mail me and I'll update this posting.

In our application (oil and gas production accounting), we have the
notion of a gas-equivalent factor (ge factor). It is a number that you
multiply by a volume of light oil, also called condensate, to get an
"equivalent" volume of gas. It's a bit like comparing, say, two grads
from different schools. One grad has a GPA of 3.2 and the other one has
a 78% average. To compare them, you may want to convert the gpa of 3.2
to a percentage, or vice versa. Anyway, the point is that this number
is displayed on several screen of the application. Now, there are
several different ways that this number is obtained, and as part of a
story I was working on, I had to include the source of the ge factor
along with the number itself. The story (similar to a use case)
specified that one of two icons should be displayed along with the
factor: "A" for analysis, and "E" for entered. In one case, an analysis
(a breakdown of the molecular constituents of the condensate) is used
to calculate a ge factor; in the other case, the user simply enters in
the factor manually. As I began to get into code, I realized that there
was a third case that the story didn't talk about. I turned to the
customer who had put together the story, who sits just across from me,
and asked him about it: Al, what happens when the ge factor is not
necessarily derived from an analysis, but it's averaged from ge factors
at several other measurements? After a bit of discussion, the user and
I agreed to include a third icon as part of the story, "C" for
calculated.

I implemented the requirement simply by putting a text label "A", "C",
or "E" next to the ge factors on the appropriate screens. Then I went
to talk to our resident gui (graphical user interface) expert about the
story: Hey Chris, I've put these text labels next to the ge factor on
our balancing screens. Could you cook up some icons that look a bit
nicer? Chris came over and asked Al: What if instead of an extra icon
next to the factor, we turned the factor itself into a link. If the
number came from an analysis, the link would actually take the user to
the analysis that was used. If the number was entered, the link would
lead to the screen where that number was entered. The user really liked
this idea. I objected: In the case that the number was calculated by
averaging several measurements, it would be a fair amount of work to
create a new screen that showed all of those measurements in one place.
The user however told us that it wasn't necessary to go that far. If
the number was an average, simply omitting the link was fine.

The buzzwordz "multidisciplinary" and "synergy" are used a lot these
days, but in this case, we solved a problem by combining our skills and
perspectives. Requirements are a bit like art. If you're a customer,
you generally know what you want when you see it, but describing it
ahead of time isn't so easy. In a non-trivial application, it's hard to
think of all the possible scenarios for a given feature. As a
developer, I'm close to the code and I can see those scenarios, so it's
a lot easier for me to ask the kind of question that I asked. Finally,
the user interface expert was concerned about clutter on the screen and
how effective the user interface would be, whereas I just cared about
the fact that the right information would show up as described in the
story. We all worked together to come up with a better solution -
without really extending the development time. The whole discussion
probably clocked in at about 15-20 minutes, and nothing about the
requirement caused an enormous amount of extra work. In the future, if
someone decides that showing all of the measurements that contribute to
an "averaged" ge factor, we can implement that as a separate story. The
important thing is that the users currently don't consider it to be
especially useful or a high priority. We've built the software not to
honor a general principle of orthogonality, but to meet our users'
actual requirements.

I was really impressed with the process we went through today and I
thought it was a nice simple example the kind of power an agile
approach can have.

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
>analysis 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 analysis 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 analysis 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 analysis 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 analysis 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 Analysis; 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 Analysis 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 Analysis; 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 Analysis 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
analysis 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 analysis 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 Analysis; 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 Analysis 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
> analysis 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
analysis 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!!!