For developers, XP allows you to focus on coding and avoid needless paperwork and meetings. It provides a more social atmosphere, more opportunities to learn new skills, and a chance to go home at a decent hour each night. It gives you very frequent feelings of achievement, and generally allows you to produce code that you feel good about.

For the Customer, XP creates working software faster, and that software tends to have very few defects. It allows you to change your mind whenever you need to, with minimal cost and almost no complaining from the developers. It produces reliable estimates so you can coordinate your schedule easier.

For management, XP delivers working software for less money, and the software is more likely to do what the end users actually want. It cuts risk in a couple ways: 1) It allows you to "pull the plug" on development at almost any time, and still have highly valuable code, and probably even a valuable working (if incomplete) application. 2) It reduces your dependence on individual superstars, and at the same time can improve employee satisfaction and retention.

The biggest disadvantage: It’s hard. It’s difficult to get many developers to accept the practices, and it takes a lot of discipline to keep doing them all. Customers may not like the idea of having to be so involved. Management may expect fixed-cost, fixed-scope estimates, which XP teams often refuse to create (because they are usually incorrect with any methodology).

Also, certain people may feel their jobs are being threatened, particularly architects, testers, and project managers. "Cowboy" coding "superstars" may dislike the reduction in fame, attention, and adreneline from "saving" the project at the last minute.

 >Because it is important for the customer to have an idea of how much
 >> everything will cost ...

 In 99% of the times customer neither needs nor wants "everything"! One
 of the big dangers of BRUF is that it imposes the wrong feeling that
 "everything" is important. This is a major distraction that inevitably
 leads to scope-creep and eventually project failures. When we have the
 first meeting with a new customer we ask the following 3 questions:
 1. What is your biggest pain?
 2. If we solve this and only this pain, will your life get better?
 3. Are you willing to pay X amount of Euros to us to solve this pain.

 If any of these questions is answered with "no" we just thank for the
 coffee and walk away. If all 3 questions are answered with yes, we move
 to the first planning game...

 Put it in another way: I do believe it is extremely dishonest and
 incorrect behavior to conduct 9 months BRUF only to reach the
 conclusion that the customer does not have enough resources to
 continue. It is dishonest because as I wrote in an earlier posting,
 _all_ good developers I know are able to estimate almost immediately
 the scale of any software project without conducting BRUF.

As part of my interview, I was required to sit and pair program for about half an hour. We worked on an writing a unit test for an actual defect that currently existed on the project (although it could easily have been a real user story, or a contrived scenario if the project had not yet started).

I thought this was a great idea, and a great source of knowledge for both sides. I was able to show that I did indeed know how to program, write unit tests, knew my way around an IDE, had acceptable interpersonal communication skills, etc. I was also able to get a different perspective on what the team dynamics were like, which I could not have gotten from a formal interview setting.

The interesting thing is that both me and my partner (one of the interviewers) taught each other about some tools and approaches that we were not previously aware of.

Even though I didn’t get the job (the position was withdrawn), I kept in touch and became friends with the interviewer/partner, and the things we taught each other came in useful in our future development work.

This company also asked for code samples and a mini-presentation, which I also thought was a great idea for separating the wheat from the chaff.

Since I have had responsibility for helping interview, select and recommend job candidates in the past, I know for a fact that the best resume and interview performance in the world is inconclusive. You can still get a lemon, even though the lemon may be very good at piling on the BS.

From my perspective as a job candidate, I am confident in my skills and my abilities. I know that I can quickly adapt and excel in any position within my skill set. However, its very frustrating when I cannot convince the potential employer of this through only a traditional resume and interview.

In future interviews that I go for (which will hopefully only be with XP/Agile shops), I am going to suggest this as a way for the hiring company to get a better idea of my skills, knowledge and abilities, both technical and interpersonal. If I am ever part of a hiring team in the future, I will definitely propose that code samples and a pair-programming session be part of the interview process for candidates who make it to the final stages. This is admittedly very time-consuming, but probably much less net investment than being forced to live with (or try to get rid of) an employee who looked much better "on paper".

Thanks, Chad

(Source: XP-mailinglist; thoughtful post by Ken Schwaber) Scrum is purely a project/product management process that can be applied to software projects, hardware projects, marketing projects, and any mix of the above. It does not contain engineering practices or any specific work practices. It is instead a way to maximize the ROI of work.

People who use Scrum in software development environment often adopt one or more of the XP practices to improve the engineering practices of the develpment organization. Scrum calls for an increment of potentially shippable product functionality every iteration. This means a fully cleaned up, refactored, tested, documented ready to go increment. Many organizations are incapable of this. It is easy to bring in XP practices because they are excellent and both Scrum and XP are pretty radically agile.

Project managers using Scrum are called ScrumMasters to differentiate the type of work they do ... they facilitate, manage the process, and optimize the team's productivity. They don't tell the team what to do, nor do they set of pairs of programmers, or parse out user stories. During the iteration, the team is entirely self- organizing ... whether it is doing software development or anything else related to the increment of functionality they are building.

XP seems to focus on team productivity... doing something the right way and as productively as possible. Scrum does this some, but instead focuses more on doing the right thing, getting ROI from building the 20% of the functionality that is necessary to get the value and maybe not building the rest.

We've implemented Scrum without telling the customer, users, or stakeholders. We've done this in one day. We seduce them into iterative, incremental development where they collaborate with us on what to do next. XP seems to require a steeper implementation curve with less acceptance from the users and customers. Scrum can't keep the customers away.

Estimating is a subtle diffrence that points out the XP and Scrum dividing point. XP works hard to estimate very finely defined stories, and to measure and improve these estimates. Scrum keeps the requirements more broad, more in general user terms that are analyzed during the iteration. Estimating isn't as important. The team does what it can, and gets better and better at figuring out how much it can do each iteration as it learns each other, the business domain, and the technology - iteration by iteration. We care more about delivering business value that having defensible estimates, which become meaningless in a collaborative setting.

Scrum also has a formal methodology that lays out how to scale Scrum to any sort of project with any number of people in any number of locations ... all based on the optimized 7 person team. This is an important mangement requirement, but not so important to an engineering discipline like XP.

I feel we are blessed to have such compatible practices and processes to apply to our software engineering projects.

I’ve been thinking about the problems of applying XP to whole organizations. Turns out this is ground thoroughly covered by the lean production folks.

Here is a paper I found helpful: www.nwlean.net/no_harm.zip The premise is that every step of the transformation must pay for itself.

Getting people to understand that their problems are tractable can be hard, I’ve found. Rob Mee was talking to a guy about TDD on a gig of ours recently. "Sure, yeah, TDD is a great idea." "Why don’t you do it?" "It’ll make us go slower." "But it makes you go faster." "Yes, of course, but it’ll make us go slower." "But it’ll make you go faster" *iterate N times for annoying large N* "Okay, it makes people go faster everywhere but here."

Amongst other things this article tells you when best to have children :-). groups.yahoo.com/group/extremeprogramming/files/when%20should%20we%20test.pdf

• Eliminate waste: Spend time only on what adds real customer value
• Amplify learning: When you have tough problems, increase feedback
• Decide as late as possible: Keep your options open as long as practical, but no longer
• Deliver as fast as possible: Deliver value to customers as soon as they ask for it
• Empower the team: Let the people who add value use their full potential.
• Build integrity in: Don’t try to tack on integrity after the fact - build it in
• See the whole: Beware of the temptation to optimize parts at the expense of the whole

Link

 >Reciprocity is not guaranteed on airlines (or toll bridges - it
 >has always amused me that the toll on the Severn Bridge between
 >England and Wales is GBP 4.20 for a car to enter Wales but there
 >is no toll the other way, ie entering England). (Maybe it shows
 >how the two countries value themselves?)

All of the bridges in the San Francisco Bay area only charge toll in one direction. Some genius realized that, on the average, just about as many cars went each way for the obvious reason that most trips across the bridges are round trips. So they doubled the toll and took down the toll booths going one way (except for the Golden Gate Bridge where the toll booths remain, unattended). There has been considerable saving in toll collection costs and the toll booth traffic jams in one direction are gone. Is it possible the Severn Bridge does similarly?

This from a lean manufacturing consultant:

Find the simple path to what works and follow it, always looking for a simpler path.

Patrick D. Smith

  >>Here is a version of Forth that runs under Windows, written in Whitespace:
  >
  >>
  >>I can't get it to run.  Do you think my browser has clobbered the code?
  Hmmm. I did exactly as the web page[1] suggests: "What do you do? Simply
  print it out and delete the file, ready to type in at a later date.
  Nobody will know that your blank piece of paper is actually vital
  computer code!"  I sure hope that I didn't mistake my only copy of the
  source code for an ordinary blank page!

  Perhaps writing my Befunge[2] compiler in Malborge[3] and then making it
  to a Forth[4] compiler written in Whitespace[1] wasn't such a good idea...

 References:
 1 http://compsoc.dur.ac.uk/whitespace/
 2 http://dmoz.org/Computers/Programming/Languages/Befunge/
 3 http://www.freebsd.org/cgi/query-pr.cgi?pr=28147
 4 http://www.cbel.com/forth_programming_language/

 >>Which brings me to an excellent 'forthism' I once read in a
 >> newsletter.  It stated:
 >>
 >>     "You can do anything in Forth - but you must be prepared
 >>     to do it yourself."
 In a recent discussion in c.l.functional, about why popular languages
 are popular, I summarized the relationship between Lisp and Forth
 more-or-less as follows:
 "From the Lisper's perspective, every other language is a cute subset
 of lisp; whereas from the Forther's perspective, every other language
 is a cute extension of Forth."

Basically it’s an ad for Whiteboard Photo. ;-)

 In years past, we have implemented some extremely complicated databases in
 Forth.  The first was done in the mid 1970's for the company Cybek in NJ,
 and it was used in some extremely complex applications.  FORTH, Inc. also
 did some very complex databases for other companies, one of which was still
 in use last time I checked, at www.calmuni.com.  That one was a
 2-dimensional database, with a huge bit matrix in the center used to
 calculate overlapping bonded indebtedness.  A few years ago my contact  there
 told me that a state agency had just spent several million $$ trying to
 replicate it using modern database tools, but the result was too large and
 too slow to be usable.

 In the late 1980's we added class-based techniques to it, which many people
 liked (although I personally preferred the earlier, simpler version).

 It's hard to describe the whole approach in a newsgroup post, though.  It
 certainly didn't resemble SQL!

Phlip:

 During the planning game, you review last week's
 finished stories, and they inspire you to write some
 new cards, to edit some cards, and to toss some cards.
 Then you (the Onsite Customer) re-sort all the cards,
 and draw off the top batch for the next week.

 But another input into this system that affects the
 planning game - the competition.

 The USA occupied Iraq using an effective new battle
 technique. In traditional advances, you send a
 diversionary force against one of your enemies flanks,
 draw them that way, then send your main force against
 their other flank.

 Modern soldiers, with cell-phones and such, follow a
 more agile approach. You simply send two forks of your
 forces, probing towards both flanks. You use sensitive
 algorithms to detect the defending commander's
 decision which flank to defend. If you can rapidly
 turn one advance into the diversion, and the other
 into the main attack, you will soon collapse the
 opposition's ability to effectively make decisions.

 Agile onsite customers can play this card too. If you
 detect your competition's marching orders, in
 real-time (using either sensitive algorithms,
 good-old-fashioned industrial espionage, or just
 reading their self-congratulatory Web site), you can
 then request iteration features which provide the
 minimum amount of code needed to start your project
 towards blocking the competition's advance. This
 technique will, again, collapse the competition's
 ability to make decisions.

 Or convince them to hire an XP coach or three. So
 either way it's a win-win-win for us! ;-)

Steven’s reply: :-)

 Or you could follow the agile strategy that Microsoft
 pioneered - announcing products with your competitions'
 features before you even start implementing them.

"Process waste" is the behaviors that don’t produce a working product. The biggest waste in the industry today is "programming in the debugger". This is so endemic nobody even calls it waste. Our vendors work very hard to supply us with advanced debuggers, so we can merrily cause problems and then fix them, instead of preventing problems.

Another big waste is delayed integration. Some shops account for how many modules we must write, then specify the modules’ interfaces, and tell each programmer to write a module separate from the others. Then at the end of this cycle the programmers start trying to integrate. They might not even have build scripts to plug the modules together; they might find themselves manually integrating by clicking on the user interface to an IDE.

Delayed integration costs some orders of magnitude more than the cumulative cost of continuous integration does.

Get ahead of these problems. Write tests first, constantly review code, don’t own code, and integrate continuously. Write and maintain build scripts that support all these behaviors seamlessly.

Don’t delay surprises. If "our product has an installer" appears as a motherhood story, integrate the installation system early, and test it every day. Don’t wait for the last iteration.

The ideal is that the last week before a big release should look and feel just like any other.

But there are similarities: software is developed in stages, it is created in a process amenable to change, and it’s developed in a team. Lean manufacturing is a different approach than a traditional assembly line, and offers some lessons for software development. xp123.com/xplor/xp0312/index.shtml