Challenge : Why XP is not that competitive

[HS Thomas]

Why I think XP is not that competitive :-
It closes all other competition - in terms of using new tools or even new ideas. Does an XPer ever say - hey that's brilliant , can I have some. It seems to be re-invent the wheel all the time.
So I think it could be operated like a closed system which is what CS guys favour and not especially good for building relationships outside the system. Which in a competitive world you need to do to survive.
I hope this extreme comment opens up some new discussion.
[ February 05, 2004: Message edited by: HS Thomas ]

[Jeff Langr]

Originally posted by HS Thomas:
Why I think XP is not that competitive :-
It closes all other competition - in terms of using new tools or even new ideas.
Does an XPer ever say - hey that's brilliant , can I have some. It seems to be re-invent the wheel all the time.

That's an interesting statement, particularly since I've heard the exact opposite as an argument: "There is nothing new in XP, it's just proven stuff with a different name and a fancy marketing wrapper."
The second statement seems to be closer to the truth with respect to the process itself.
If you're referring to tools and other re-uses of existing code, that's a different subject. XP developers prefer to use small, simple tools. They shun bloated tools and/or APIs that (to them) get in the way of getting the job done.
Would you explain what you mean by "competitive?"
-Jeff-
[ February 05, 2004: Message edited by: Jeff Langr ]

[HS Thomas]

Originally posted by Jeff Langr:

Would you explain what you mean by "competitive?"
-Jeff-

I think XP is good at creating value at the bottom of the chain in terms of it's developers.
Sticking really close to the customers gives what the customers want. I guess the onus is on the customers to determine if they need new tools to remain competitive. I can't see the XP department taking on the role of deciding what the customer wants. And sometimes this is required for both to survive.
XP strengths are that it builds strong teams of developers and Systems Analysts. In that way it is more than a couple of steps ahead of Rapid Application Generators and the latter had some very bad press.
Perhaps the XP principles can be applied to Business Analysis as well ?
[ February 05, 2004: Message edited by: HS Thomas ]

[Jeff Langr]

Originally posted by HS Thomas:
I think XP is good at creating value at the bottom of the chain in terms of it's developers.
Sticking really close to the customers gives what the customers want. I guess the onus is on the customers to determine if they need new tools to remain competitive. I can't see the XP department taking on the role of deciding what the customer wants. And sometimes this is required for both to survive.

I agree that what you're describing can be a problem. Remember that a development team shouldn't keep their mouth shut, but should be providing feedback to the customer. Even though XP says the customers make the final decision, there's nothing there that says they shouldn't be pushing back if they think there's a problem or if something is missing. They do need to learn to couch their insistences in terms of business value.
XP now recommends that the customer is a team, not just a single person as it used to recommend. In that team, there need to be people who understand what is going to be necessary to make the product(s) competitive. I heavily promote the idea of an analyst role (not sure what the best name is for it) on this team. This person takes nebulous requirements from marketing, proxy customer, real customers, and shapes them into the stories that the development team will build.
It is their job to also understand the rest of the requirements that are needed to build a robust system, and ensure that these stories are inserted and prioritized appropriately. I like to use the HP acronym FURPS (functionality, usability, reliability, performance, supportability). Most customers worry only about the "F." Someone has to remind the customer that the remainder of the requirements ("URPS") must be considered, otherwise you don't have a real, competitive system.
The analyst role might be filled by the primary proxy customer from the business side, but most organizations supposedly can't afford this. Also, there are few people that have both the business savvy and systems knowledge, hence the need for an analyst and proxy customer to work together as a team.
-Jeff-
[ February 05, 2004: Message edited by: Jeff Langr ]

[Ilja Preuss]

Originally posted by HS Thomas:
I think XP is good at creating value at the bottom of the chain in terms of it's developers.

Mhh, and I always thought that XP was all about creating *business* value. But I might be misunderstanding you...

Sticking really close to the customers gives what the customers want.

Well, yes, of course. Though XP talks about the Customer (notice the capital C), which actually is a *role*. The Customer is the role in the development team which knows what needs to be build.
So basically XP says that those on the team who know how to do business should do business decisions, and those who know how to develop solutions should do development decisions. And there should be tight collaboration between the two.

I guess the onus is on the customers to determine if they need new tools to remain competitive.

It's the responsibility of the business people on the team, yes. And actually XP is agnostic to how they come to their decisions. XP basically starts when business has an idea of what needs to be developed.

I can't see the XP department taking on the role of deciding what the customer wants. And sometimes this is required for both to survive.

I don't understand this. What is the "XP department", and why should it need to decide what the customer wants?

Perhaps the XP principles can be applied to Business Analysis as well ?

I'd guess so - but what were those principles, again?

[HS Thomas]

Sorry I took some time replying -
Mhh, and I always thought that XP was all about creating *business* value. But I might be misunderstanding you...
OK. Jeff's answer about having a purely business *role* helping on the team does ensure there is business value. But the value I meant was that XP seems to concentrate on growing developers within the framework of the business.
Well, yes, of course. Though XP talks about the Customer (notice the capital C), which actually is a *role*. The Customer is the role in the development team which knows what needs to be build.
So the team depends entirely on the Customers immediate needs. Do XP developers feel free to train in new technologies, keep abreast of developments that the Customer doesn't see as immediately necessary ?
This can be frustrating for the solutions developers. The developers are reliant on the Customer 100% on their career choices. Small companies may not have a wide range of careers to choose from so the XP team suffers.
So basically XP says that those on the team who know how to do business should do business decisions, and those who know how to develop solutions should do development decisions. And there should be tight collaboration between the two.
It's the responsibility of the business people on the team, yes. And actually XP is agnostic to how they come to their decisions. XP basically starts when business has an idea of what needs to be developed.

Ditto. Both the XP team and the Customer have to decide whether it is good enough. Can't the XP team sometimes operate in small doses as a consultancy within the firm ? Do XP leaders have the power to ask for budgets.
As Jeff wrote : -

Most customers worry only about the "F." Someone has to remind the customer that the remainder of the requirements ("URPS") must be considered, otherwise you don't have a real, competitive system.

What is the "XP department", and why should it need to decide what the customer wants?
Sorry, I meant team.

HST : Perhaps the XP principles can be applied to Business Analysis as well ?
IP :I'd guess so - but what were those principles, again?

XP as an agile development methodology supports the agile manifesto�
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
Then at http://www.extremeprogramming.org/rules.html we have 28 �rules� that must be followed. There are too many to list here.
According to Rick Hightower (http://www.rickhightower.com/xpj2ee_jdjedge/text5.html) there are 5 principles to XP:
1. Provide rapid feedback.
2. Assume simplicity.
3. Make incremental changes.
4. Embrace change.
5. Do quality work.
There are 4 values of XP:
1. communication
2. simplicity
3. feedback
4. courage
Object mentor tells us that XP is a set of �best practices�
1. customer team member
2. planning game
3. user story
4. small release
5. acceptance testing
6. open workspace
7. test driven design
8. metaphor
9. simple design
10. refactoring
11. continuous integration
Ron Jeffries tells us that there are 13 �core practices�
1. whole team
2. planning game
3. small release
4. customer tests
5. simple design
6. pair programming
7. test-driven development
8. design improvement
9. continuous integration
10. collective ownership
11. coding standard
12. metaphor
13. sustainable pace
Simple, huh ?
[ February 05, 2004: Message edited by: HS Thomas ]

[Lasse Koskela]

HST:So the team depends entirely on the Customers immediate needs. Do XP developers feel free to train in new technologies, keep abreast of developments that the Customer doesn't see as immediately necessary ?
This can be frustrating for the solutions developers. The developers are reliant on the Customer 100% on their career choices. Small companies may not have a wide range of careers to choose from so the XP team suffers.

I think the problem here is that we, the developers, have been wrongly accustomed to having a license to play. It's the Customer (well, usually her boss) that pays the bills so why should he allow the Developer to do something more costly simply because the XYZ will look good on the resume next to ABC and DEF?
I see the possible problem you're seeing -- developers getting bored doing the same stuff day in, day out. Some companies have solved this by scheduling part of the weekly 40 hours for goofing off, contributing to open source projects, learning new technologies, etc. The important part here is that the customer shouldn't be the one picking up the bill. Furthermore, XP doesn't disallow using new technologies so you're free to evaluate whatever technology the development team considers worth of evaluating. Furthermore, the developers sign up for their tasks themselves, which makes for a nice motivation and commitment, but also lets an individual developer to steer his "career" to some degree.
Also, in the long run, it's a lot better to "learn to learn" instead of learning specific technologies.
I don't quite get what you mean with the last sentence, "Small companies may not have a wide range of careers to choose from so the XP team suffers"?

[HS Thomas]

Originally posted by Lasse Koskela:

I don't quite get what you mean with the last sentence, "Small companies may not have a wide range of careers to choose from so the XP team suffers"?

Just that it may be one or two people writing the test , designing and programming, and finally testing of the system. Which probably doesn't leave room to develop other skills. That last actually sounds like pair-programming. There's an extreme danger of being stuck in a loop as you would working for a small company.
[ February 06, 2004: Message edited by: HS Thomas ]

[Frank Carver]

In my experience that happens in small companies regardless of XP. I've worked in several organizations either with me as the only "computer guy", or maybe one or two others.
The business itself may be much bigger - hundreds of production staff, sales and marketing, middle management etc. It's just that it's not a software business, it sells petfood, or chrome plating services, or TV programs.
My personal productivity has often been much higher (both in terms of software produced, and business value produced) in such unencumbered, close to the metal, situations. In bigger companies, with whole divisions and departments devoted to software, I've worked on projects with tens or hundreds of team members and lasting years, which were scrapped before delivery.
As with many agile approaches, one of the aims of XP is to bring the development of software back close to real business needs. Software development is a business function just like any other, and has to fit in with the business model and marketing. Would you consider it reasonable for the paint finish line in an auto factory to decide to paint all the cars pink, just to claim experience of a different color on a resume?

[Jeff Langr]

Originally posted by HS Thomas:
Do XP developers feel free to train in new technologies, keep abreast of developments that the Customer doesn't see as immediately necessary ?
This can be frustrating for the solutions developers. The developers are reliant on the Customer 100% on their career choices. Small companies may not have a wide range of careers to choose from so the XP team suffers.

This is a very valid concern. Which means I've got a long-winded, roundabout answer.
I've heard some developers in XP shops complain that one of the main goals of XP seems to be to make developers plug-compatible. "Management just wants to make sure they can get rid of me if necessary."
While that's a cynical viewpoint, it is to some degree valid: the business wants to avoid the opposite, which is being beholden to one very talented person. Or being dependent upon one twit who couldn't program his way out of a paper bag. I've seen both, and they can be equally devastating: the arrogant guy who knew everything and left in a huff, leaving the team in a lurch, and the loser who held up the entire project because his part of the work sucked.
While the cynic sees the goal of things like pair programming, tests as documentation, and team** code ownership as ways of making sure they can be replaced, the business person sees these as ways of protecting their investment (purportedly better so than producing written docs).
Also, if you're worth your salt and you're contributing to the business, management is not going to get rid of you just because they can. When doing XP properly, it's very clear who the contributors are and aren't. And if I'm not contributing, then management should get rid of me, particularly because they can.
However, my viewpoint is that a process is worthless unless it sells something to everyone involved. Once a participant in the process views something as counterproductive to them, they'll trash it, ignore it, whatever. That's why most design documentation is poor: developers view it as largely worthless to them, and they know it's rarely going to get read, so they expend as little effort on it as possible.
So, what's to sell in XP? One of the benefits is that you're not pigeonholed to being the JSP guy, something that frustrates many would-be "component developers" (whatever the heck those are) in shops that segment people by technology. By virtue of the process, you can pick up any task from the front end through to the back end, and gain enough experience in it to bolster your resume.
In a larger shop, the additional benefit is that you can move more easily from one group to another. In a classic shop, a project manager is lax to let you move around, since you typically have valuable knowledge no one else does. In an XP shop, coming up to speed is a by-definition part of the process.
As a coach, I've also been able to swap two guys between two different teams because there were personality clashes. Neither team took a productivity hit, and in fact both teams improved from this cross-pollination--the switched developers each immediately brought some valuable knowledge and technique to the other team. Thus this switchability is also a sell to management.
Back to your original question. XP developers on a project end up doing what the business demands. This just makes business sense, regardless of the process.
However, I'm 100% in your camp: I don't want to work as an employee for a company that isn't helping me grow. They should be willing to regularly send me to training, or to help me grow into the salesperson role I've always dreamed of***, as long as that's something that might be beneficial to the company.
Management should be even more willing to do this in an XP environment, since they are not as dependent upon your full-time contribution to a project. They should also recognize that part of building successful teams is ensuring you stay happy, and if you're not getting the training you want, you're not going to be happy.
In any case, a customer should have little say in the personnel management of the team. That's the job of the manager. If your manager can pay for you to go to training, you should go to training.
I also believe that the wiser companies find R&D money to let teams go off, experiment, and build something great.
-Jeff-
** the word "collective" leaves a bad taste in my mouth
*** well, not really

[HS Thomas]

Originally posted by Frank Carver:
As with many agile approaches, one of the aims of XP is to bring the development of software back close to real business needs. Software development is a business function just like any other, and has to fit in with the business model and marketing. Would you consider it reasonable for the paint finish line in an auto factory to decide to paint all the cars pink, just to claim experience of a different color on a resume?

I agree. It would seem that the developer either progresses with the business or not at all. Yeah! I too have worked on large hierarchical projects. So people would have to fit in with the business. What about those consultancies / staff contracted to do a piece of work ? Would they be considered part of the XP team as they'd be let go when that work finishes ? Do they have to work the XP way ? A lot do bring in an extra level of expertise. Most are not company men / women in a traditional sense.
[ February 06, 2004: Message edited by: HS Thomas ]

[Jeff Langr]

Originally posted by HS Thomas:
Just that it may be one or two people writing the test , designing and programming, and finally testing of the system. Which probably doesn't leave room to develop other skills.

Greetings HS,
What other sorts of skills are you referring to?
My experience has been that the smaller the team (XP or not), the more you learn since there are fewer people to cover everything that needs to be done. Even so, I've picked up more design, sysadmin, dba, integrator, tester, configuration manager, and help desk skills on XP teams than I would have on a classic team.
-Jeff-
[ February 06, 2004: Message edited by: Jeff Langr ]

[Jeff Langr]

Originally posted by HS Thomas:
What about those consultancies / staff contracted to do a piece of work ? Would they be considered part of the XP team as they'd be let go when that work finishes ? Do they have to work the XP way ? A lot do bring in an extra level of expertise. Most are not company men / women in a traditional sense.

I think consultants provide an even more compelling argument for working the "XP way." Otherwise, they'll leave, and the code they've written typically won't have been tested or even reviewed by anyone else. Been there, seen that, and have been stuck with absolutely unmaintainable cr*p from high-priced, arrogant SOBs who wouldn't give me the time of day when I asked them to explain their code.
If you're trying to write a system that's completely covered with unit tests, and one guy doesn't provide them, you have a glaring hole in your test coverage. Why would you let that happen?
This doesn't preclude you from bringing in true experts that are around for a couple of weeks, providing valuable insights on things like how to properly architect Vitria BusinessWare. They probably don't need to work the way the team does. Just don't let them write code, or if they do, make sure someone understands it and can bolster it with tests and other quality measures before they leave.
Most shops don't bring in expert consultants, they bring workhorses that are around for 6 months or more. If someone's around for that long, why shouldn't they work as part of the team? If you were doing RUP, would you say it's OK that the KPMG guy doesn't produce transition artifacts or show up at inspection meetings, just because he's a KPMG guy?
-Jeff-
[ February 06, 2004: Message edited by: Jeff Langr ]

[Jeff Langr]

Originally posted by HS Thomas:
Then at http://www.extremeprogramming.org/rules.html we have 28 �rules� that must be followed. There are too many to list here.
According to Rick Hightower there are 5 principles to XP:
...
There are 4 values of XP:
...
Object mentor tells us that XP is a set of �best practices�
...
Ron Jeffries tells us that there are 13 �core practices�
...
Simple, huh ?

While listing things this way does make it look onerous, it's really not. If you start on an XP effort, someone guides you through a planning meeting and a regular day of developing. That's it; rinse, repeat. You don't memorize a lot of rules, you don't jump through a lot of hoops.
After a two-week iteration, it's obvious what you should be doing at all times and how you should be acting. Even after two days, it's obvious. The practices become ingrained--it's unlike, say, RUP, where someone's instantiation of the process says that on this day we have to remember to produce this document.
The values and principles are there as underlying philosophies. One need not memorize a list of them, but over time and with modest experience one can learn how to use them to understand why XP works (or doesn't) and to help solve problems that the process doesn't outright cover. I don't even remember the list of all principles, and I taught this stuff many times over several years. Principles are derived from values; for example, the "do the simplest thing that could possibly work" principle derives from the value of simplicity.
While one might view a lot of this as motherhood and apple pie, most other processes pay lip service to things like simplicity, yet counter them with an overwhelming set of requirements for arcane documentation.
As far as the inconsistencies between the practice/rules lists, I don't defend the lack of clarity in the message. However, they all say the same thing, just in slightly different ways.
-J-

[Rob Hunter]

Hi Guys,
Just a quick note. Glancing at bits of some of the postings in here I find it amusing that any product of Microsoft and the idea of customer satification would ever come up in the same place. Extensive testing is what Microsoft really needs to focus on. Having a monopoly tends to leave the provider of goods neglecting his/her customers which can be seen when using XP. XP is more for the family person. Developing home videos and the sort but not extensive developing!!! We, the consumer, are the lab rats in all of this. I bought an XP for my home office and we recently purchased 2 at my workplace. Doesn't anyone get sick of that darn error window that keeps popping up and asking whether to send error message or not? Leave me with workstation anyday. In conclusion, XP will appeal to the family office more than the work office so it will be more competitive in the home than in the office. Didn't read most of the last postings and merely responding to the subject of the initial posting, so I hope I didn't stray off the last bit of conversation. [yawn] Now back to sleep.
Rob

[Jeff Langr]

Originally posted by Rob Pike:
ust a quick note. Glancing at bits of some of the postings in here I find it amusing that any product of Microsoft and the idea of customer satification would ever come up in the same place. Extensive testing is what Microsoft really needs to focus on. Having a monopoly tends to leave the provider of goods neglecting his/her customers which can be seen when using XP. XP is more for the family person. Developing home videos and the sort but not extensive developing!!! We, the consumer, are the lab rats in all of this. I bought an XP for my home office and we recently purchased 2 at my workplace. Doesn't anyone get sick of that darn error window that keeps popping up and asking whether to send error message or not? Leave me with workstation anyday. In conclusion, XP will appeal to the family office more than the work office so it will be more competitive in the home than in the office. Didn't read most of the last postings and merely responding to the subject of the initial posting, so I hope I didn't stray off the last bit of conversation. [yawn] Now back to sleep.

Cute.
Just remember to get XP Professional, otherwise networking is futile. And you're correct, most offices still use 2000. In any case, the dominance of Microsoft cost us about 5 years in OS evolution.
-j-

[Stan James]

Do XP developers feel free to train in new technologies, keep abreast of developments that the Customer doesn't see as immediately necessary? This can be frustrating for the solutions developers. The developers are reliant on the Customer 100% on their career choices. Small companies may not have a wide range of careers to choose from so the XP team suffers.

The customer drives business choices, not technical choices. If customer requirements drive you to an architecture with all new technologies, an XP team can have just as much fun learning as any other kinda team.
If you're asking whether developers should use COMPANY time to do some speculative training and learn a technology before it's really called for, it's probably their choice. Oh yeah, their velocity may suffer and they may not get hired for the next project. Or they may be the only people ready for the next project. I'm not sure XP has any impact on this gamble except that pairing and short iterations make your productivity or lack of very visible!

[Lasse Koskela]

Originally posted by Rob Pike:
Didn't read most of the last postings and merely responding to the subject of the initial posting, ...

Figures...

[HS Thomas]

OK!I give in.
One thing though - the XP team is supposed to work closely with the customer but not get in the way of business decisions and processes. Obviously the degree of closeness would be determined by the customer and the "business" knowledge of the XP team. And this should change over time.
Therefore aiming for closeness all the time can be construed to be a good thing for both XP teams and the business.
I'd say the business would do more than well by adopting XP principles.
Obviously business have different practices.
Thanks to Jeff and everyone for an illuminating discussion.
[ February 06, 2004: Message edited by: HS Thomas ]

[HS Thomas]

But I'd still be aware that developers need to be competitive just as businesses need to.

[Lasse Koskela]

Originally posted by HS Thomas:
But I'd still be aware that developers need to be competitive just as businesses need to.

Yes, and that's exactly what experience with extreme programming does for you -- it gives you a competitive edge against BDUFers via improved quality and higher user satisfaction. If you're talking about competitiveness within the XP team, well, I would bet that the team knows how good a work someone on the team does, remembering that they have total access to that individual's code (collective code ownership) and see how he works (pairing).

[HS Thomas]

But the XP team would not be tasked with finding the right technical platform, what hardware needs to be bought, training programs, inter-operability issues, right ? That's an outside consulting excercise usually.
And developers on the existing platform usually hate the decision they may not have been involved in.
Or can XP be used to help make the decision ? Which may be over-ridden by management anyway ! This book is targeted for the management or customer role on an XP project,
Planning Extreme Programming
"The content of the book covers all aspects of planning, managing and tracking progress on an XP (Extreme Programming) project and is a worthy companion to Kent Beck's anthemic XP Explained. Hard stuff missed out from the earlier work such as how to estimate how long things will take, how to write user stories and how to organize the details of iterations and releases is explained in a straightforward way. It also introduces a few new key XP concepts, showing that this radical methodology didn't spring fully formed into the mind of Beck, but is still evolving. One such key is "Yesterdays Weather", the idea that you can't go far wrong by using past performance as an initial guess for future results."
[ February 08, 2004: Message edited by: HS Thomas ]

[Lasse Koskela]

But the XP team would not be tasked with finding the right technical platform, what hardware needs to be bought, training programs, inter-operability issues, right ?

Yes, XP can be used to make those decisions. Just schedule a story titled "specify required hardware", "develop a training program", etc. and start splitting them up into manageable pieces. They are requirements and should be treated as such.
PS. I've got that book and it's great. Probably the one that I value most over the other 3 books I've bought from the Addison-Wesley XP series.

[HS Thomas]

Originally posted by Rob Pike:
Doesn't anyone get sick of that darn error window that keeps popping up and asking whether to send error message or not? Leave me with workstation anyday. [yawn] Now back to sleep.
Rob

Better than an outright crash with a blue screen, though.
Ok, I fell down but now I am up again sounds much better. And someone at M$ can worry about it and send you some updates. I'm not sure how this works. Do they keep all your machines Error Reports and run some Profiling Analysis which they base their updates on. Weird science !

[Sonny Pondrom]

Better than an outright crash with a blue screen, though.

I'm still using Win95 and getting the blue screens. Is there any advice on a new operating system? XP or Linux? :roll:

[Ilja Preuss]

Originally posted by Sonny Pondrom:

I'm still using Win95 and getting the blue screens. Is there any advice on a new operating system? XP or Linux? :roll:

Hey, we are talking about eXtreme Programming here! Just because Microsoft hijacked the abbreviation for their new version of Windows doesn'T mean that we should discuss it in the *process* forum... :roll:

[Jeff Langr]

Originally posted by HS Thomas:
Thanks to Jeff and everyone for an illuminating discussion.

Thanks for opening it up, and thanks for the discourse!
-Jeff-