Agile Development - Extreme Programming

From what I can tell Extreme Programming (XP) is the most misunderstood Agile methodology out there.  For example one time I was giving Extreme Programming (XP) as an example of Agile development, and one person's response was "Extreme Programming?  I don't want to talk about just how you plan to write the code, I want to talk about how you're going to run your project." *SIGH*

I think its name helps to tie into this sort of thing.  Some people hear the word "programming" and just shut down because they think they're going to start hearing about something technical.

At any rate, I digress.  So what is Extreme Programming (XP)?  Like all the other Agile processes it focuses on frequent releases to promote the gathering of feedback and incorporation of that feedback to create a stable product that meets the customer's needs. 

Like other Agile methodologies XP has a set of core principles that it focuses on for success.  The team must deliver customer satisfaction

1. The team must deliver customer satisfaction
   1. Part of this is helped by having extensive customer involvement.  The ideal XP project has customers involved in the project full time, actually sitting with the project team.    Not all projects can meet that ideal, but working as closely as you can with your customers is key to the success of an XP project. 
   2. Since tight customer involvement is key, and many customer's are non technical, XP focuses on defining product objectives as "what" the software must do, rather than "how" its going to do it.  
2. Deliver working software frequently
   1. Again this is a common Agile principle, get the software in peoples hands as quick and as often as possible to get feedback, iterate, and improve.   Short iterations are best, 1 - 3 weeks if possible.
3. Working software: Working software is the primary measure of progress.
   1. It doesn't do you any good to talk about/write up the greatest software system in the world.  You need to build it.
   2. Working software also means quality software so
      • Have comprehensive unit test coverage.
      • Define acceptance tests for all features.
      • Code reviews are key to software quality.
4. Promote communication.
   1. Have averyone sit together to promote conversation. 
   2. Involve the ecustomer frequently in planning, steering, and evaluation.

So how does this all tie together and work?

Generally XP starts with exploring the problem space.  Talk to the customer and experiment with things such as story cards and paper protypes to make sure the team understands what is needed and what that may mean from an implementation perspective.

Then the team goes into Release Planning.  Here customers and developers work together to complete the stories that are required, and then together decide what to do for the next release.

Ok, so now the team has defined the bigger release picture, but how to get to that finish line?  At this point customers and developers come up with a set of iteration cycles to implement the features.    At the start of each iteration the customers pick the particular release stories that they want implemented in that iteration cycle. 

The iteration commences, and developers work basic eight-hour work days, overtime is actually discouraged in XP as its considered as a sign of a dysfunctional project, dropping productivity, and quality.  This is something I've actually never seen, that doesn't mean it doesn't happen, but every project has some sort of crunch time that requires some extra time. 

One other note about the implementation.  XP espouses the idea that you should pair developers together.  I've seen projects that do this, and projects that are XP in nearly all other ways, that don't.  Long story short, you don't have to do this if you don't want to.  It does have benefits, but it also has some detractions.  Decide for yourself what's best for you.

As the iteration progresses the project team continually collaborates with the customers to make sure they've gotten the stories implemented properly.

At the end of each cycle the stories that are to be done as part of the Release are updated/added/dropped based upon discussions and things learned during the iteration.  As a result the requirements can change at any point in the XP process.

Finally, the iteration cycle is repeated until all the chosen release stories have been implemented, and the software is released.