RE:

 

From: Ron Jeffries <[email protected]>

 

On Wednesday, December 11, 2002, at 6:21:30 PM, Alleman, Glen B. wrote:

 

>> In fact this may be the paradigm shift - how can we talk about agile

>> practices from the view of the customer, manager, or funding source?

>> What kinds of practices would they want to use to aid in the outcome.

>> I'm not so interested in the details of story cards, SCRUM meetings,

>> etc., those area actually too low level for my needs. We just had a
blow

>> up (no literally) of a customer because of mis-communication of
intent.

>> An XP practice of continuous engagement and continuous delivery would

>> have adverted this situation. If we had had a release that could be
in

>> place in a few hours all would be forgiven.

 

>What kinds of practices do you contemplate that would be different from
On Site Customer, SCRUM meetings, and laying the story cards on the
table, yet would give you the continuous engagement you need?

 

>What kind of practices do you contemplate that would be different from
micro-level implementation, tests at 100%, and continuous integration,
yet would give you the continuous delivery that you need?

 

Ron,

 

I think we have to look at the customer through their eyes, and think
like they think.  I therefore would adopt some of the practices we used
when we did new product development at 3M, namely:

 

We would find lead customers and recognize that any minute of their time
they gave us was very precious, so we planned our time with them well.
We always sent the technical people to visit customers, and tasked them
with getting a really good feel of what the lead customers were saying.
Then we came back and tired to interpret it, and took our result back to
the lead customers and asked them if we were right.   And then WE, the
development team, took it upon ourselves to discover the things that
weren't said and the hidden agendas and the true underlying values.  If
we failed to get it right, it was OUR fault, and OUR pain, because OUR
product would fail.

 

The issue is one of responsibility.  Who is responsible for getting
things right?  In product development, it is clearly the company
developing the product.  You win or loose based on your ability to know
the customers better than they know themselves, and give them what they
will buy even if they don't know they want it. 

 

For firms which develop software, the economic rules have not changed
just because of XP.

 

For firms which sell services to other firms, the economic rules are
quite similar.

 

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. 

 

Mary Poppendieck

www.poppendieck.com

952-934-7998