Re: Re: Digest Number 130

Ron Jeffries wrote:

> On Friday, January 9, 2004, at 3:12:59 PM, J. B. Rainsberger wrote:
> 
>  > Ron Jeffries wrote:
> 
>  >>  > We XP enthusiasts certainly don't own the whole truth. Only through
>  >>  > dialog we may advance the state of things to hopefully have more
>  >>  > humane social environments for SW development.
>  >>
>  >> Sadly, "humane" is really not an objective in the minds of most 
> companies.
>  >> I think that I really believe that. If I do, it /does/ sadden me.
> 
>  > That's why I think the way to advance the use of XP is to separate
>  > interface from implementation. More and more I am convinced that the
>  > /only/ way for me to use XP on a project is for my client to outsource
>  > the entire project to me and, if I'm lucky, "my team." (My team, at
>  > present, is me.)
> 
>  > This way we only need XP-related buy-in from the Customer. For the rest,
>  > we get business-related buy-in, which is easier (though not easy) to do.
>  > The Whole Team has to implement the Business interface, which I don't
>  > think I can achieve by joining an existing development group.
> 
> I'm not sure I understand fully about what you see as the business
> interface, and how you would try to match up to it while doing XP.

Perhaps I worded it poorly. Let me try this.

I have used or tried to use XP in three major scenarios.

1. As an independent software development firm, hired to build software 
for someone, where the client only provides a person or people to play 
the Customer role.

2. As both an independent contractor and a full-time employee, 
hired/asked to build software both as part of a programming team where 
the employer provides day-to-day management of the project.

3. As an employee, asked to build software for an internal customer, 
/but as a one-man team/. (Here I used XP for One: "extreme coding" plus 
frequent releases and the planning game.)

#1 and #3 worked well, but #2 did not.

Since #1 and #3 worked well, the problem is likely one of the following:

  * I can't work well with others, as a programmer
  * I can't work well when the programming side of team contains people 
provided by the client/employer

I have some evidence that I work well with others, as a programmer, at 
least in limited situations, so let's assume that the second point is 
the issue.

In the second case, "the client" is providing programming resources, so 
they have to worry about day-to-day management issues related to those 
people, such as evaluating them for the purposes of deciding 
raises/promotions, and so on. The client has a stake in /how the project 
is run/ on a day-to-day basis -- they have a stake in how the 
programmers work.

When the client has a stake in how the programmers work, as opposed to 
just the frequency and quality of software oozing out of them, things go 
badly.

This is just what I've experienced. I don't know what it means. What it 
/encourages/ me to do, however, is never take business responsibility 
for delivering software with programmers that aren't /mine/. What's left 
is what I'm terming the Business interface: stories, priority, release 
schedule, cost per iteration, and the like.
-- 
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


 

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Upgrade to 128-bit SSL Security!
http://us.click.yahoo.com/qZ0LdD/yjVHAA/TtwFAA/nhFolB/TM
---------------------------------------------------------------------~->

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/xpAdoption/

To unsubscribe from this group, send an email to:
 [email protected]

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