RE: Responsibility

--- Kent Beck <kent-hJ4WY/gWbur3XBa+dPFJ6Fr/[email protected]> wrote:
Mary Poppendieck wrote:
>> Only for internal development do we allow the development team to pass
>> responsibility for success on to the customer.  It's a nice, but limited
>> concept.  
>> 
>> If you feel responsible for the overall business value you deliver, then
>> 'customer on site' doesn't quit tell you enough about how to go about
>> it. I think that when the development team owns the responsibility for
>> delivering business value, and for uncovering what that really means,
>> and does not delegate this to 'the customer' (whoever that is), then you
>> have a dynamite approach. 
> 
> What I see from my perspective that you don't seem to see from yours is
> that the customer, those whose lives are intimately affected by the
> software we build, is part of the team. Nygard went over this ground
> long ago in Participatory Design
> http://www.cpsr.org/program/workplace/PD.html. The game where we
> separate ourselves (as technical people) from those whose
> responsibilities rely on the products we create is a nice, but limited,
> game.

When I've been a product manager for commercial products, I've been most
successful when I've let the customer define value, and least successful when I
thought I knew the customer's business better than they did.

I now believe that, in commercial software development, every step we take that
is not done with the customer involves a significant risk. I hear every now and
again with XP that the product manager should be the Customer in the XP sense
-- alarm bells go off: the customers are the Customer -- the challenge is to
get them to speak with one voice.

There are business relationships, with contractual support, that help here:
we've worked out partnership agreements that are a cross between a standard SLA
and contracted development.

On the other hand, I agree with Mary in the following respects:
1) The entire team needs to be responsible for providing customer value, though
the customer gets to define value. I sometimes hear on the XP list people say:
XP means that I don't have to worry about business issues, only technical
issues. I think the entire team should be working on business issues, with
technical issues well subordinated to those issues. (I believe Kent has written
of this separation of responsibilities as a first move to get the customer's
voice back into the process, and not the final stance)
2) It takes some work to get down to a good understanding of customer value,
and customers often don't know how to help us to do that. We need to do good
and hard work to get to that understanding. The common failure mode is to ask
the customer what the software should do, and come back with a list of
features, which we then implement, and wonder why the customer isn't satisfied.
Only after we understand what drives value should we be talking about features.

Arien

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/