What is Business Value? (slight return)

I think this deserves its own thread, so I've
reposted it out of the 'Estimating' thread with
additional comments....

"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:cj7gal$mqk$1@news.freedom2surf.net...
> Corey Burnett wrote:
> 
news:<10lbmlna1r6lb41@news.supernews.com>... 
>
> What is business value?
>
> We tend to think its fully working, fully developed systems meeting all
> of the critical requirements...
>

From the customer's point of view, business value is more
about  how completely they can do their work in the new
application.

>
> By implementing small sub-parts of the critical requirements in dribs
> and drabs, with each passing iteration. The customers get to see REAL
> working applications that meet those small sub-part requirements.
>

They get to see them, but they may not be able to use them. The above
example; we installed a working login module, of course, it doesn't connect
to anything.... is a good example.

Philip, when business value comes up, usually characterizes it as
'improving customer productivity', and the amount of value is the
amount by which productivity improves.

If software is 'testable but not releasable',
then at best, it has no impact on customer productivity, at worst,
it reduces productivity to the extent that customers are expected to
break from their work to test the software.

If the software released doesn't allow the customer to do complete
transactions or business processes, then it reduces productivity to the
extent that customers must do duplicate work.

(This was my experience
in a project that did iterative releases of functions. The goal of the
project
was to replace 2 separate case management applications with 1 case
management
application, implement functions pertaining to HIPAA regs, and respond to
new state audit requirements.) Until the functionality achieved a certain
critical mass (enough to eliminate 1 application, for example), what was
data entry into 2 systems became data entry into 3 systems.

While I wouldn't call the XP claim to 'deliver business value with each
iteration'
an illusion, I do think the claim needs something more in the way of
concrete evidence.

(An interesting footnote; in the books I've read so far on
agile methods and XP, none of the examples of release planning
given would meet Philip's test of improving customer productivity.
They were more in line with Corey's point, delivery of admittedly
working software too limited to be of actual use.)

Scott Kinney wrote:
> They get to see them, but they may not be able to use them. The above
> example; we installed a working login module, of course, it doesn't connec
t
> to anything.... is a good example.

I was wondering in the login example, if 5 people worked
on a feature and all of them needed to login first, and
the login hadn't been done yet because it is not
an end-to-end story itself, would all 5 developers create
their own login system to get there story implemented?
I think there is room for dependency based horizontal
features.

On Mon, 27 Sep 2004 19:50:48 -0700, George <somewhere@nowhere.com>
wrote:
 
>
>I was wondering in the login example, if 5 people worked
>on a feature and all of them needed to login first, and
>the login hadn't been done yet because it is not
>an end-to-end story itself, would all 5 developers create
>their own login system to get there story implemented?
>I think there is room for dependency based horizontal
>features.

Yes, but the team will figure that out on the fly unless they are as
dumb as frogs and never talk to each other. And if they are like that,
they should be doing some other process, since they're doomed and we
want to keep our average up. :)

But seriously, folks, the dependencies aren't what we think they are,
they are often much easier to deal with than we fear, and the team can
and should sort them out as they go.

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Mon, 27 Sep 2004 19:50:48 -0700, George <somewhere@nowhere.com>
wrote:

>
>
>Scott Kinney wrote: 
>
>I was wondering in the login example, if 5 people worked
>on a feature and all of them needed to login first, and
>the login hadn't been done yet because it is not
>an end-to-end story itself, would all 5 developers create
>their own login system to get there story implemented?

No, each one would stub out the login process.

>I think there is room for dependency based horizontal
>features.

There probably is, but the more we can creatively avoid dependencies
the more flexibility we have to deliver business value.



-----
Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

Ronald E Jeffries wrote:
> Yes, but the team will figure that out on the fly unless they are as
> dumb as frogs and never talk to each other.

I guess robert thinks they eat flies then :-)

Though i am not sure why they would figure it out on
the fly or why that is better than just recongnizing the
obvious, that we need to do the login. Loging in, especially
in a servlet/jsp environment is not at all simple and does require
some thought and research.


> But seriously, folks, the dependencies aren't what we think they are,
> they are often much easier to deal with than we fear, and the team can
> and should sort them out as they go.

I am not sure what that all means. In this case the dependency is quite
clear and obvious so i'll risk saying it is what we think it is.
I don't fear them in any scenario.

George wrote:
> Ronald E Jeffries wrote: 
>
> Though i am not sure why they would figure it out on
> the fly

Because they discuss what they will do in the morning (Stand Up Meeting),
all work in the same room and pair program with a different partner every
few hours?

> or why that is better than just recongnizing the
> obvious, that we need to do the login.

Because it isn't obvious - you just think it is. Seriously.

> Loging in, especially
> in a servlet/jsp environment is not at all simple and does require
> some thought and research.

And that's exactly why we should defer the effort until we really need it.
 
>
> I am not sure what that all means. In this case the dependency is
> quite clear and obvious so i'll risk saying it is what we think it is.

Well, we did exactly that: wrote a web frontend for an
until-then-swing-application that needed users to login and deferred the
implementation of the login until ws after the first deployment.

Cheers, Ilja

On Mon, 27 Sep 2004 21:27:42 -0700, George <somewhere@nowhere.com>
wrote:

>Ronald E Jeffries wrote: 
>
>I guess robert thinks they eat flies then :-)

Yum.
>
>Though i am not sure why they would figure it out on
>the fly or why that is better than just recongnizing the
>obvious, that we need to do the login. Loging in, especially
>in a servlet/jsp environment is not at all simple and does require
>some thought and research.

If it's obvious, then certainly it'll be recognized. In this case, as
I'll mention below, I suspect there's no dependency at all, or not
much of one.
>
> 
>
>I am not sure what that all means. In this case the dependency is quite
>clear and obvious so i'll risk saying it is what we think it is.
>I don't fear them in any scenario.

I don't fear them either, because I've learned there aren't as many as
I thought.

For example, what makes you think we couldn't do login /after/ other
pages? I don't see a real dependency there at all. What am I missing?

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

"George" <somewhere@nowhere.com> wrote in message
news:10lisopmr1rfb52@news.supernews.com...
>
>
> John Roth wrote: 
>
> Can't it just be something the customer wants?
> They don't really need a reason that makes
> sense to you.

1. Something that the customer wants; absent
a business driver, is a preference, not a value.
2. If their reason doesn't make sense to you, you
don't understand their needs or business very well.
You should probably ask.

'Value' as John (increased revenue, reduced cost) and I
(increased productivity, which covers a multitude of
conditions) is concrete and measurable.

George wrote:

> John Roth wrote: 
>
> Can't it just be something the customer wants?
> They don't really need a reason that makes
> sense to you.

It ain't XP until you release a working version to real users, they use it,
it boosts their productivity, and they give feedback.

Put another way, the best possible feedback for a system is boosts in end
user productivity.

(If your project is online gambling, the best feedback is reductions in user
productivity.)

So, if your onsite customer has indeed set the autopilot for the center of
the Earth, the Customer and Developer Bills of Rights don't let you fix
things, but you can at least detect the poor situation early and often.

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

George wrote:

> And in the daily meeting why would i talk about a part
> of the story that i haven't got to yet because
> i haven't started coding yet? This seems contradictory.
> Should i talk about all the other classes i don't
> know about yet too?

Because the standup meeting is about yesterday's successes and today's
concerns.

> You really need it. Every stateful web app needs a bullet proof
> login. The issues are wide and deep. If you haven't done it
> before you will be very surprised.

Pick one:

- security
- internationalization
- concurrency
- data integrity

They are all things we have (generally) bad memories trying to retrofit into
an existing system. Such memories are (generally) untainted by TDD. There is
simply no comparison between hacking complex code and adding features to
simple code.

> It's a duh you can defer it. The question is with 5 people with
> a login in their story would all of them make a seperate stub
> or would you converge on a single solution before they checkin?
>
> Robert says you'll make 5 different ones. And that makes sense and
> is not necessarily bad. You seem to think it is bad and trying
> to make up a scenario where it won't happen.
>
> But some others are saying we'll magically talk about
> something we haven't done yet at a meeting or some how during
> the day.

Uh, I lost track. Why are 5 similar user story cards on the bulletin board?

In general, questions about specific XP practices have answers in other
practices...

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces