Extreme Programming


Extreme Programming (XP) was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may have a system whose functionality is expected to change every few months. In many software environments dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not.
XP was also set up to address the problems of project risk. If your customers need a new system by a specific date the risk is high. If that system is a new challenge for your software group the risk is even greater. If that system is a new challenge to the entire software industry the risk is greater even still. The XP practices are set up to mitigate the risk and increase the likelihood of success.
XP is set up for small groups of programmers. Between 2 and 12, though larger projects of 30 have reported success. Your programmers can be ordinary; you don't need programmers with a Ph.D. to use XP. But you cannot use XP on a project with a huge staff. We should note that on projects with dynamic requirements or high risk you may find that a small team of XP programmers will be more effective than a large team anyway. XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well, all working together elbow to elbow. Asking questions, negotiating scope and schedules, and creating functional tests require more than just the developers be involved in producing the software.
Another requirement is testability. You must be able to create automated unit and functional tests. While some domains will be disqualified by this requirement, you may be surprised how many are not. You do need to apply a little testing ingenuity in some domains. You may need to change your system design to be easier to test. Just remember, where there is a will there is a way to test.
The last thing on the list is productivity. XP projects unanimously report greater programmer productivity when compared to other projects within the same corporate environment. But this was never a goal of the XP methodology. The real goal has always been to deliver the software that is needed when it is needed.

A software methodology is the set of rules and practices used to create computer programs.


The most obvious way to start extreme programming (XP) is with a new project. Start out collecting user stories and conducting spike solutions for things that seem risky. Spend only a few weeks doing this. Then schedule a release-planning meeting. Invite customers, developers, and managers to create a schedule that everyone agrees on. Begin your iterative development with an iteration-planning meeting. Now you're started.

The Rules and Practices of Extreme Programming.   
 
Planning
 User stories are written.
 Release planning creates the schedule.
 Make frequent small releases.
 The Project Velocity is measured.
 The project is divided into iterations.
 Iteration planning starts each iteration.
 Move people around.
 A stand-up meeting starts each day.
 Fix XP when it breaks. 

Designing
 Simplicity.
 Choose a system metaphor.
 Use CRC cards for design sessions.
 Create spike solutions to reduce risk.
 No functionality is added early.
 Refactor whenever and wherever possible. 

Coding
 The customer is always available.
 Code must be written to agreed standards.
 Code the unit test first.
 All production code is pair programmed.
 Only one pair integrates code at a time.
 Integrate often.
 Use collective code ownership.
 Leave optimization till last.
 No overtime. 

Testing
 All code must have unit tests.
 All code must pass all unit tests before it can be released.
 When a bug is found tests are created.
 Acceptance tests are run often and the score is published. 


How do I start this XP thing?    
The most obvious way to start extreme programming (XP) is with a new project. Start out collecting user stories and conducting spike solutions for things that seem risky. Spend only a few weeks doing this. Then schedule a release-planning meeting. Invite customers, developers, and managers to create a schedule that everyone agrees on. Begin your iterative development with an iteration-planning meeting. Now you're started.
Usually projects come looking for a new methodology like XP only after the project is in trouble. In this case the best way to start XP is to take a good long look at your current software methodology and figure out what is slowing you down. Add XP to this problem first.
For example, if you find that 25% of the way through your development process your requirements specification becomes completely useless, then get together with your customers and write user stories instead.
If you are having a chronic problem with changing requirements causing you to frequently recreate your schedule, then try a simpler and easier release planning meeting every few iterations. (You will need user stories first though.) Try an iterative style of development and the just in time style of planning of programming tasks.
If your biggest problem is the number of bugs in production, then try automated acceptance tests. Use this test suite for regression and validation testing.
If your biggest problem is integration bugs then try automated unit tests. Require all unit tests to pass (100%) before any new code is released into the code repository.

If one or two developers have become bottlenecks because they own the core classes in the system and must make all the changes, then try collective code ownership. (You will also need unit tests.) Let everyone make changes to the core classes whenever they need to.
You could continue this way until no problems are left. Then just add the remaining practices as you can. The first practice you add will seem easy. You are solving a large problem with a little extra effort. The second might seem easy too. But at some point between having a few XP rules and all of the XP rules it will take some persistence to make it work. Your problems will have been solved and your project is under control. It might seem good to abandon the new methodology and go back to what is familiar and comfortable, but continuing does pay off in the end. Your development team will become much  more efficient than you thought possible. At some point you will find that the XP rules no longer seem like rules at all. There is a synergy between the rules that is hard to understand until you have been fully immersed.
This up hill climb is especially true with pair programming, but the pay off of this technique is very large. Also, unit tests will take time to collect, but unit tests are the foundation for many of the other XP practices so the pay off is very great.
XP projects are not quiet; there always seems to be someone talking about problems and solutions. People move about, asking each other questions and trading partners for programming. People spontaneously meet to solve tough problems, then disperse again. Encourage this interaction, provide a meeting area and set up workspaces such that two people can easily work together. The entire work area should be open space to encourage team communication.


User Stories    
User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax. 
User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.
One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest 
difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. 
Developers estimate how long the stories might take to implement. Each story will get a 1, 2 or 3 week estimate in "ideal development time". This ideal development time is how long it would take to implement the story in code if there were no distractions, no other assignments, and you knew exactly what to do. Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level, combine some stories. About 80 user stories plus or minus 20 is a perfect number to create a release plan during release planning. 
Another difference between stories and a requirements document is a focus on user needs. You should try to avoid details of specific technology, data base layout, and algorithms. You should try to keep stories focused on user needs and benefits as opposed to specifying GUI layouts.

Release Planning
A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each individual iteration.
It is important for technical people to make the technical decisions and business people to make the business decisions. Release planning has a set of rules that allows everyone involved with the project to make their own decisions. The rules define a method to negotiate a schedule everyone can commit to.
The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks. An ideal week is how long you imagine it would take to implement that story if you had absolutely nothing else to do. No dependencies, no extra work, but do include tests. The customer then decides what story is the most important or has the highest priority to be completed. 
User stories are printed or written on cards. Together developers and customers move the cards around on a large table to create a set 
of stories to be implemented as the first (or next) release. A useable, testable system that makes good business sense delivered early is desired.You may plan by time or by scope. The project velocity is used to determine either how many stories can be implemented before a given date (time) or how long a set of stories will take to finish (scope). When planning by time multiply the number of iterations by the project velocity to determine how many user stories can be completed. When planning by scope divide the total weeks of estimated user stories by the project velocity to determine how many iterations till the release is ready.
Individual iterations are planned in detail just before each iteration begins and not in advance. The release planning meeting was called the planning game and the rules can be found at the Portland Pattern Repository.
When the final release plan is created and is displeasing to management it is tempting to just change the estimates for the user stories. You must not do this. The estimates are valid and will be required as-is during the iteration planning meetings. Underestimating now will cause problems later. Instead negotiate an acceptable release plan. Negotiate until the developers, customers, and managers can all agree to the release plan.
The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is how much is to be done. Resources are how many people are available. Time is when the project or release will be done. And quality is how good the software will be and how well tested it will be. 
Management can only choose 3 of the 4 project variables to dictate, development always gets the remaining variable. Note that lowering quality less than excellent has unforeseen impact on the other 3. In essence there are only 3 variables that you actually want to change. Also let the developers moderate the customers desire to have the project done immediately by hiring too many people at one time.

Iteration Planning
An iteration planning meeting is called at the beginning of each iteration to produce that iteration's plan of programming tasks. Each iteration is 1 to 3 weeks long. User stories are chosen for this iteration by the customer from the release plan in order of the most valuable to the customer first. Failed acceptance tests to be fixed are also selected. The customer selects user stories with estimates that total up to the project velocity from the last iteration.
The user stories and failed tests are broken down into the programming tasks that will support them. Tasks are written down on index cards like user stories. While user stories are in the customer's language, tasks are in the developer's language. Duplicate tasks can be removed. These task cards will be the detailed plan for the iteration. 
Developers sign up to do the tasks and then estimate how long their own tasks will take to complete. It is important for the developer who accepts a task to also be the one who estimates how long it will take to finish. People are not interchangeable and the person who is going to do the task must estimate how long it will take.
Each task should be estimated as 1, 2, or 3 ideal programming days in duration. Ideal programming days are how long it would take you to complete the task if there were no distractions. Tasks which are shorter than 1 day can be grouped together. Tasks which are longer than 3 days should be broken down farther.
Now the project velocity is used again to determine if the iteration is over booked or not. Total up the time estimates in ideal programming days of the tasks, this must not exceed the project velocity from the previous iteration. If the iteration has too much then the customer must choose user stories to be put off until a later iteration (snow plowing). 

If the iteration has too little then another story can be accepted. The velocity in task days (iteration planning) overrides the velocity in story weeks (release planning) as it is more accurate.
It is often alarming to see user stories being snow plowed. Don't panic. Remember the importance of unit testing and refactoring. A debt in either of these areas will slow you down. Avoid adding any functionality before it is scheduled. Just add what you need for today. Adding anything extra will slow you down. 
Don't be tempted into changing your task and story estimates. The planning process relies on the cold reality of consistent estimates, fudging them to be a little lower creates more problems.
Keep an eye on your project velocity and snow plowing. You may need to re-estimate all the stories and re-negotiate the release plan every three to five iterations, this is normal. So long as you always implement the most valuable stories first you will always be doing as much as possible for your customers and management. 
An iterative development style can add agility to your development process. Try just in time planning by not planning specific programming tasks farther ahead than the current iteration.


Iterative Development
Iterative Development adds agility to the development process. Divide your development schedule into about a dozen iterations of 1 to 3 weeks in length. Keep the iteration length constant through out the project. This is the heart beat of your project. It is this constant that makes measuring progress and planning simple and reliable in XP.
Don't schedule your programming tasks in advance. Instead have an iteration planning meeting at the beginning of each iteration to plan out what will be done. Just-in-time planning is an easy way to stay on top of changing user requirements.
It is also against the rules to look ahead and try to implement anything that it is not scheduled for this iteration. There will be plenty of time to implement that functionality when it becomes the most important story in the release plan.
Take your iteration deadlines seriously! Track your progress during an iteration. If it looks like you will not finish all of your tasks then call another iteration planning meeting, re-estimate, and remove some of the tasks. 

Concentrate your effort on completing the most important tasks as chosen by your customer, instead of having several unfinished tasks chosen by the developers.
It may seem silly if your iterations are only one week long to make a new plan, but it pays off in the end. By planning out each iteration as if it was your last you will be setting yourself up for an on-time delivery of your product. Keep your projects heart beating loud and clear.

Unit Tests
Unit tests are one of the corner stones of Extreme Programming (XP). But unit tests XP style is a little different. First you should create or download a unit test framework to be able to create automated unit tests suites. Second you should test all classes in the system. Trivial getter and setter methods are usually omitted. And last you should try to create your tests first, before the code. 
Unit tests are released into the code repository along with the code they test. Code without tests may not be released. If a unit test is discovered to be missing it must be created at that time. 
The biggest resistance to dedicating this amount of time to unit tests is a fast approaching deadline. But during the life of a project an automated test can save you a hundred times the cost to create it by finding and guarding against bugs. The harder the test is to write the more you need it because the greater your savings will be. Automated unit tests offer a pay back far greater than the cost of creation.
Another common misconception is that unit tests can be written in the last three months of 
the project. Unfortunately, without the unit tests, development drags on and eats up those last three months and then some. Even if the time is available good unit test suites take time to evolve. Discovering all the problems that can occur take time. In order to have a complete unit test suite when you need it you must begin creating the tests today when you don't.
Unit tests enable collective code ownership. When you create unit tests you guard your functionality from being accidentally harmed. Requiring all code to pass all unit tests before it can be released ensures all functionality always works. Code ownership is not required if all classes are guarded by unit tests.


Agile Modeling and eXtreme Programming (XP)

Introduction   
Setting the record straight 
XP and AM?   
AM throughout the XP lifecycle   
How do you make this work?   
  
1. Introduction
Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner.  On the AM home page I state that one of the goals of AM is to address the issue of how to apply modeling techniques on software projects taking an agile approach such as eXtreme Programming (XP) (Beck, 2000), Dynamic Systems Development Method (DSDM) (Stapleton, 1997), and SCRUM (Beedle & Schwaber, 2001) to name a few.  Because the scope of XP is much greater than that of AM, XP covers the full development lifecycle, it is a candidate "base process" into which the techniques of AM may be tailored.  Furthermore, although XP clearly includes modeling as part of its process it is not as explicit about how to do so as many developers would prefer.  Hence an opportunity for AM.  Luckily XP, like AM, is also an agile practices-based methodology which makes the conceptual fit between the two methods much easier than between AM and a prescriptive process such as the Unified Process (Kruchten, 2000; Ambler, 2001b), the topic of the essay Agile Modeling and the Unified Process.   
  
2. Setting The Record Straight
There are several common misconceptions that people seem to have regarding modeling on an XP project.  The three most common misconceptions are that you don’t model on an XP project, that you don’t document on an XP project, or that if you do model your only options are the modeling artifacts of the UML.  I’ll address these misconceptions in turn in this section, but first I want to explore why they occur so that you can recognize other misconceptions when they arise.  From what I can gather based on the conversations on the AM mailing list, http://www.agilemodeling.com/feedback.htm, the source of these misconceptions is often the result of one or more of the following:

Second-hand knowledge of XP.  The Internet is a major source of information for many developers, in particular newsgroups and emails from colleagues.  As people learn a new technique they often join a newsgroup or mailing list, such as extreme programming at Yahoo groups (http://groups.yahoo.com), and start monitoring the group/list.  Someone will post something, which may not be accurate, and many people will accept it as official, particularly when they haven’t had an opportunity yet to try it out for themselves.  Don’t believe everything that you hear.   

Questionable sources of information regarding XP.  It’s often hard to determine the quality of published material, be it electronic or printed form.  Sometimes honest mistakes are made, that’s happened to me more than once, and sometimes people publish misleading information on purpose.  When you’re just learning a new subject you often cannot distinguish between high-quality sources of information and questionable ones.  If you base your understanding on questionable sources it is very easy to get the wrong idea about XP.  Visit the Agile Modeling Resources page, http://www.agilemodeling.com/resources.htm, for an up-to-date list of what I believe to be good sources of information regarding XP and other agile software processes. 

Difficulty seeing beyond their current environment.  Many developers find themselves in less-than-ideal environments.  XP requires you to adopt practices that are often foreign to your current environment, pair programming and test-first development are new to most organizations, and sometimes these practices simply aren’t feasible to adopt.  If you cannot adopt the practice of pair programming then XP isn’t going to work for you, but instead of proclaiming that XP doesn’t work in their environment many people will instead proclaim that XP doesn’t work at all.  The reality is that XP does in fact work in the right situations, it is just that your situation may not be one of the right ones. 

Too much focus on the word “extreme”.  XP’s name is both one of its greatest strengths its greatest weaknesses.  Because of the name when some people hear XP’s advice to travel light, to reduce the amount of documentation that you create and maintain, that they instead translate it to “create no documentation at all”.  That’s extreme, right?  Or they’ll hear XP’s advice to use simple modeling techniques such as user stories and CRC cards and somehow translate that advice to “you don’t model at all.”  That’s extreme, right?  Sigh. 

In this section I will set the record straight regarding the three most common issues concerning modeling and XP:

  Modeling is Part of XP   
  Documentation happens  
  XP and the UML? 

2.1 Modeling is Part of XP
User stories are a fundamental aspect of XP and artifacts such as Class Responsibility Collaborator (CRC) cards are common to XP efforts.  User stories provide a high-level overview of the requirements for a system -- they are reminders to have a conversation with your project stakeholders regarding their requirements -- and are used to as a primary input into estimating and scheduling, and drive the development of acceptance test cases.   CRC cards are used to explore structure, perhaps for conceptual modeling to understand the problem domain or for design to work through the structure of your software.  User stories and CRC cards are both models, see the Artifacts for AM essay, so therefore modeling is clearly a part of XP.  XP developers will also create sketches, often on a whiteboard or a piece of paper, whenever user stories and CRC cards aren’t the best option.  In Extreme Programming Explained (Beck, 2000), the first book written about XP, Kent Beck includes hand-drawn sketches of class diagrams and other free-form diagrams.  The bottom line is that modeling is a fundamental aspect of XP, something that I explore in detail in this essay. 
  
2.2 Documentation Happens
Documentation is also an important part of XP.  Ron Jeffries (2001b) offers the following advice:

“Outside your extreme programming project, you will probably need documentation: by all means, write it.  Inside your project, there is so much verbal communication that you may need very little else.  Trust yourselves to know the difference.” 

There are several interesting implications of that statement.  First and foremost, the XP community recognizes that documentation should be produced for people external to your team, people that AM would term project stakeholders.  Second, it points out that verbal communication between team members reduces the need for documentation within the team.  This is the result of project team members being co-located, making communication easier, as well as aspects of XP such as Pair Programming and Collective Ownership that promote communication between developers.  As I discuss in the essay on Communication documentation is only one form of communication, one that is typically the least effective, that can be easily replaced by more effective techniques such as face-to-face communication.  Third, it recognizes that sometimes you do in fact need internal documentation for your team.  This is consistent with the advice presented in Extreme Programming Installed (Jeffries, Anderson, & Hendrickson, 2001) where the authors point out that information resulting from conversations with your project stakeholders regarding user stories are captured as additional documentation attached to the card.  More on this in the Section A Closer Look At the XP Lifecycle.  Fourth, it suggests that XP team members should know when documentation is required and be allowed to act accordingly.  Fifth, it implies that you should trust the team and give them control over their own destiny.  This can be hard in many organizations.  If the team is untrustworthy then you have a serious problem that needs to be dealt with, this is true regardless of whether they are following XP, or if they are trustworthy but your organizational culture doesn’t allow you to act based on that trust then once again you have a serious problem to deal with.  Another problem is that when you are an outsider to an XP team, when you haven’t been actively involved in the conversations and interactions that have replaced the need for documentation, that it appears that there isn’t enough documentation.  When this is the case, instead of forcing the team to write documentation instead invest the time to determine if they need the documentation that you believe is missing – suggest the documentation to the team, and if there is an actual need for it then they’ll create it.  As Ron Jeffries likes to say, “It’s called Extreme Programming not stupid programming” (Jeffries, 2001e).  Finally, the most important implication for XP teams is that if you need documentation then write it.

The need for documentation on an XP project is reduced by several of its practices.  First, because of test-first development and a focus on acceptance testing there is always a working test suite that shows that your system works and fulfills the requirements implemented to that point.  For the developers, these tests act as significant documentation because it shows how the code actually works.  When you think about it, this makes a lot of sense.  When you are learning something new do you prefer to read a bunch of documentation or do you look for source code samples?  Many developers prefer to start at source code samples, and the test suite provides these samples.  Second, XP’s focus on simplicity and practice of refactoring result in very clean and clear code.  If the code is already easy to understand, why invest a lot of time writing documentation to help you to understand it?  This applies to both internal and external documentation – why add comments to code that is already clear and unambiguous?  If the code isn’t so, then refactor it to improve its quality or as a last resort write documentation.  Even though some development environments make it easy to include documentation in your code, Java’s Javadoc utility is such an example, you only want to invest in documentation when it makes sense to do so and not just because it is easy.

What confuses many people regarding XP and documentation is that XP doesn’t specify potential documents to create during development.  This is unlike the Unified Process (Kruchten, 2000; Ambler, 2001b) which suggests a slew of potential project artifacts.  Instead, the suggestion is to work together with your project stakeholders in an environment of rapid feedback and trust them to determine the things that they need, not just documents but any type of project enhancements (Jeffries, 2001b).  Once again, you need to have the courage to trust the people involved with the project.  In the essay Agile Documentation I discuss a collection of documents that you may choose to create and provide advice for when to consider creating them.

One of the greatest misunderstandings people have about XP regards concept of traveling light – many people believe that it means you don’t create any documentation, but nothing could be further from the truth.  What traveling light actually means is that you create just enough models and documentation, too little or too much puts you at risk.  As I suggest in Agile Documentation a good rule of thumb to ensure that you’re traveling light is that you shouldn’t create a model or document until you actually need it – creating either thing too early puts you at risk of wasting your time working on something you don’t actually need yet. 

An important thing to understand about documentation on an XP project is that it is a business decision, not a technical one.  This is consistent with AM’s philosophy regarding documentation, discussed in Agile Documentation.  Jeffries (2001b) says it best:

“If there is a need for a document, the customer should request the document in the same way that she would request a feature: with a story card.  The team will estimate the cost of the document, and the customer may schedule it in any iteration she wishes.”
  
2.3 XP and The UML
See the essay XP and the UML?  Clearly the Wrong Question to be Asking 

3. AM and XP?
On the AM Home Page I state that AM should be tailored into an existing, full lifecycle methodology, in order to improve its approach to modeling.  Because modeling is clearly a part of XP, see above, the potential exists for AM to add value to an XP project.  This assumes of course that there is possible to tailor AM into XP, I believe it is and argue so below, and that you can do so without detracting from what currently exists within XP.  In particular, XP’s practices of refactoring and test-first development clearly do a very good job of filling in for two critical goals – promoting clean design and thinking through your design before writing code – that are typically associated with traditional modeling processes.  My experience is that both refactoring and test-first development are complementary to AM and arguably enablers of several AM practices, as I argue below.  In this section I explore the following issues:

  The potential fit between AM and XP  
  Refactoring and AM   
  Test-first development and AM   
  Which AM practices to adopt?  

3.1 The Potential Fit Between AM and XP
A critical issue that must be addressed is how well AM fits with XP.  Table 1 lists the practices of AM and either maps them to existing principles or practices of XP or discusses the potential fit of the AM practice when it is not explicitly a part of XP.  Because XP was used as a foundation for AM many of the practices map straight to XP.  However, because AM’s focus is on modeling several practices are clearly new, hence the potential for AM to bring value to an XP project.

  
Table 1. Applicability of AM Practices on an XP Project.
AM Practice	Fit With XP
Active Stakeholder Participation	This practice is simply a new take on XP’s On-Site Customer practice.  AM uses the term project stakeholder in place of customer and focuses on the concept of their active participation, hence Active Stakeholder Participation and not On-Site Stakeholder.
Apply Modeling Standards	This is the AM version of XP’s Coding Standards practice.
Apply Patterns Gently	This practice reflects the YAGNI principle to the effective application of patterns within your system, in conformance to XP’s practice of Simple Design.
Apply the Right Artifact(s)	This practice is not explicitly described by XP principles and practices although is very much aligned with XP philosophies of “if you need it do it” and using the most appropriate tool or technique for the job at hand.
Collective Ownership	AM has adopted XP’s Collective Ownership practice.
Consider Testability	This is a reflection of XP’s Testing practice with respect to modeling – when you are modeling something, perhaps with CRC cards or sketches, you should keep in the back of your mind what test cases you’ll need to support the ideas captured in your models.  See Chapter 10 for a detailed discussion of AM and testing.
Create Several Models in Parallel	This is a modeling-specific practice.  XP developers can clearly work on several models – such as CRC cards, acceptance test cases, and sketches – if they choose to do so.
Create Simple Content	This is complementary XP’s Simple Design practice that advises to keep your models as simple as possible.
Depict Models Simply	This is complementary XP’s Simple Design practice that suggests that your models do not need to be fancy to be effective, perfect examples of which are CRC cards and user stories.
Discard Temporary Models	This practice reflects XP’s Travel Light principle, which AM has adopted, explicitly advising you to dispose of models that you no longer need.
Display Models Publicly	This practice reflects XP’s (and AM’s) value of Communication, principle of Open & Honest Communication (adopted by AM), and reflects its practice of Collective Ownership.
Formalize Contract Models	This practice is not currently reflected within XP, well perhaps in its “if you need to then do it” philosophy.  This practice was included in AM to provide guidance for how to deal with the very common situation of integrating with other systems.
Iterate to Another Artifact	This practice explicitly states, in a general form, the practice of XP developers to iterate between working on various artifacts such as source code, CRC cards, and tests.
Model in Small Increments	This practice supports XP’s iterative and increment approach to development.  Both XP and AM prefer an emergent approach to development and not a big design up front (BDUF) approach. 
Model to Communicate	This practice is modeling-specific, describing one reason why you would want to model, a practice that reflects XP’s and AM’s principle of Open & Honest Communication.
Model to Understand	This practice is modeling-specific, describing the primary reason why you would want to model.  This practice is consistent with XP’s existing use of CRC cards to explore design issues, and is effectively a generalization of the concept.
Model With Others	This is the AM version of XP’s Pair Programming practice.
Prove it With Code	This is the AM version of XP’s Concrete Experiments principle.  In fact, it was originally called Concrete Experiments although was renamed when it was evolved into a practice.
Reuse Existing Resources	This concept is not explicitly included in XP, although it clearly isn’t excluded either.  XP developers are practical, if there is something available that can be appropriately reused then they will likely choose to do so.
Update Only When it Hurts	This practice reflects AM and XP’s Travel Light principle, advising that you should only update an artifact only when you desperately need to.
Use the Simplest Tools	This practice reflects AM and XP’s Assume Simplicity principle and is consistent with XP’s preference for low-tech tools such as index cards for modeling.
  
The fact that AM’s practices are complementary to XP isn’t sufficient; there should also be a philosophical alignment between the two methodologies as well.  I believe that there is.  First, AM has adopted the four values of XP – Courage, Simplicity, Communication, and Feedback – and added a fifth one, Humility, one that is clearly compatible with XP.  Second, the principles of AM are closely aligned with those of XP.  Nine of eighteen are adopted directly from XP, and the remaining ones – Software is Your Primary Goal, Enabling the Next Effort is Your Secondary Goal, Model With a Purpose, Multiple Models, Content is More Important Than Representation, Everyone Can Learn From Everyone Else, Know Your Models, Know Your Tools, and Maximize Stakeholder Investment – are clearly compatible with XP’s philosophies.  The three modeling-specific principles may cause a hard-core XP developer to pause for a moment, but on reflection should not prove arguable.  Model With a Purpose advises that you shouldn’t work on a model without good cause, Multiple Models says that you have a wide range of techniques available to you that you may choose to apply (including but not limited to CRC cards, user stories, and the diagrams of the UML), and Know Your Models suggests that you need to know what you’re doing to be effective.


3.2 Refactoring and AM
Refactoring (Fowler, 1999) is a technique to restructure code in a disciplined way, a technique that is a fundamental practice of XP.  The basic idea is that you make small changes to your code, called refactorings, to support new requirements and/or to keep your design as simple as possible.  The advantage of refactoring is that it enables programmers to safely and easily evolve their code to fulfill new requirements or to improve its quality.


Is refactoring compatible with AM?  Yes.  Refactoring is a coding technique whereas AM does not address programming-related issues, therefore there is no technical overlap between the two.  What about a conceptual overlap?  AM address design modeling and refactoring addresses design improvement of source code.  This begs the question “What do you do when you have an existing design model and you refactor your code?”  Although it’s an interesting question, the real issue is that you have two artifacts, a design model and source code, that describe the design of your system.  One has changed, the source code, now you need to decide whether or not you wish to update the model.  The way that you originally arrived at the model is irrelevant to this issue, you could have gotten there because you took an AM approach to develop it, you could have taken a BDUF approach, or you could adopted an existing model and are coding to it (for example, several organizations have developed persistence frameworks based on the design that I present at http://www.ambysoft.com/persistenceLayer.html).  The issue is irrelevant of the type of design model, be it a UML class diagram, CRC cards, a physical data model, or a procedural structure chart.  The good news is that AM provides advice for how to deal with such a situation, in particular the practice Discard Temporary Models suggests that you should consider whether you really need the design model and then if not get rid of it and the practice Update Only When it Hurts suggests that it’s often reasonable to have artifacts such as the design model and the code out of sync.

So how do you apply AM and refactoring together?  Simple.  Apply AM practices as appropriate when you are modeling, use those models as input into your programming efforts, and refactor your code as you normally would have.  If you discover that you need to attempt a major refactoring, get the team together to discuss it, modeling whenever appropriate, then approach the major refactoring as you would have in the past: as a collection of small refactorings. 

Modeling tools that reverse-engineer your code can prove valuable when you are refactoring code, particularly when you are unfamiliar with that code. Many developers think visually, they grasp information communicated via pictures more readily than they do information communicated textually, so CASE tools that quickly import a bit of code and create diagrams from them can be very useful.  It's quite common for CASE tools to import object-oriented source code, perhaps written in Java or C++, and generate UML class diagrams that show the static structure of the code and UML sequence diagrams that depict its dynamic nature.  These diagrams can be used to quickly understand the existing code, the first step in refactoring it.
  

3.3 Test-First Development and AM
Test-first development is a development practice where you work in very short cycles where you consider a test, write the test and business code for it, get it to work, then continue.  These tests are collected into a development integration testing suite that must be successfully run whenever code is submitted into your shared repository.  This practice is integral to XP.

Is test-first development compatible with AM?  Yes.  Like refactoring, test-first development is more of a coding practice so there is little opportunity for technical overlap.  However, there is room for conceptual overlap because test-first development clearly delves into the realm of detailed design since it provides developers with an opportunity to think through their code before they write it (as well as important feedback regarding their code).  If you’ve chosen to do a little modeling before writing your code, perhaps to think through an issue larger than a single test case, then that’s okay.  In fact, it may even make your test-first development efforts easier, particularly if you have adopted AM’s Consider Testability practice.  

How do you apply AM within a test-first development environment?  As with refactoring, simply apply AM practices as appropriate when you are modeling, use those models as input into your programming efforts, and iterate between modeling, testing, and programming as needed.
  
3.4 Which AM Practices to Adopt?
Only the ones that add value to what your team is trying to accomplish.  Ideally that will at least be the core practices of AM, therefore it would be fair to claim that you are in fact “doing AM”, and perhaps even adopt the supplementary practices as well.  It is important to note that your goal isn’t simply to be able to say that you’re agile modeling, it is to improve your productivity as software developers. 

4. AM Throughout the XP Lifecycle
To explain how the practices of AM can be applied on an XP I will work through a portion of the SWA Online Case Study and show how modeling is used throughout the XP lifecycle in the essay AM and XP: AM Throughout the XP Lifecycle. 

5. How Do You Make This Work?
How should you approach modeling during development on an XP project?  Beck (2000) suggests that you should apply the XP practice of Small Initial Investment and draw a few pictures at a time.  He states that the XP strategy is that anyone can design with pictures all they want, but as soon as a question is raised that can be answered with code then the designers must turn to code for the answer.  In other works you should then seek Rapid Feedback to discover whether your pictures are on target by following the AM practice Prove it With Code.

When should you consider modeling during development on an XP project?  Whenever creating a model is more effective that writing code.  In other words, follow the AM principle Maximize Stakeholder Investment and the AM practice Apply the Right Artifact(s).

How should you model?  Follow AM’s practice Use the Simplest Tools and prefer tools such as index cards, whiteboards, and Post It notes over more complicated CASE tools.  Simple tools tend to promote interaction and communication, two factors that are critical to your success.  Although XP favors the use of index cards to record user stories, CRC models, and story tasks there is nothing wrong with using a CASE tool as long as its use provides positive value to your effort.

How should you document?  XP teams prefer to write clean, easy-to-understand source code – their philosophy is that only the source code is in sync with the source code.  However, remember that AM’s principle Model With A Purpose states that you should understand the needs of a model/document’s audience.  If the audience for documentation is your system’s users or your senior management then clean source code isn’t going to do it, instead you will need to develop external documentation for this audience.  Your stakeholders should request this documentation and should understand the costs involved, one of which is the fact that any time you spend writing documentation isn’t spent writing software, and be willing to accept those costs.

XP developers need to recognize that you can model on an XP project, that modeling is in fact a part of XP already with its existing application of user stories and CRC cards.  More importantly, XP developers must abandon any preconceived notions that they may have about modeling - that big modeling up front (BMUF) is the only approach to modeling, that models are permanent documents that must always be updated, that you need to use complex CASE tools to model, and that the UML defines the only models available to you - and approach modeling from a new perspective.  One such perspective was presented in this essay, that you can tailor Agile Modeling (AM) into a software process based on eXtreme Programming (XP) and still remain effective as software developers.