Agile Development

Implementing Extreme Programming (XP)

Extreme Programming, further referred to simply as XP, is a method of agile development, that, when properly implemented, can make a huge positive impact on application development. It is meant to improve both software quality and the ability to respond to changing customer requirements. And though it may seem easy to implement in theory, the implementation of XP it is much easier when the following factors are taken into account. 

Management Support
Though XP works best within teams with a flat management structure, it is necessary to have support from management to implement it, and actively supportive management is best. Your organization needs the following: 

• Paired workspaces for coding
• The team members who are devoted to the XP project
• A manager who communicates with the customer or the customer on-site

Management should also provide the following:

• Complete control should be left to the team for the entire development
• Feedback, review, and proper compensation to the team as a team
• Support for change and new ways of doing things
• Patience with slower progress or lower productivity in the learning stages 

Team Agreement
Everyone that is a part of the XP team must be committed to it and agree to implement it. If they are resistant, it is very likely that XP will not run smoothly and will not work. The practice of XP relies heavily on the good faith and best efforts of its team members, and there is really no way to successfully force someone to practice XP. The best-case scenario is that he or she will quit or leave the team, and the worst-case scenario is that he or she will slow down progress and use passive aggressive means to sabotage the project.

There is a fine line between those who adamantly oppose XP and those who are just on the fence. If someone is not familiar with XP or just not that comfortable with it, but they are willing to participate anyway, then it can work out for the team. You never know, they may end up liking it and learning something new, and if it does not work out, you can always adjust the game plan later to suit the entire team.

Team Size
For new XP teams, there should be no more than 8 people per team, and there should be an even number of programmers so that they can work in pairs. As a general rule of thumb, though, you should not have fewer than four programmers, because there will not be enough diverse knowledge between them and they’ll have issues using pair programming. Teams larger than this are not recommended with inexperienced teams, though more experienced teams can handle larger team size better. 

Working With A New Code
The goal of XP is to have easy to change code. The team should put their effort in to creating code that is clean and easy to change with each release. It is very easy to maintain clean, easy to change code if you are working with a new code base, but if you are working with an existing one, it can be more difficult. Even if your existing code is very good, it will not have been developed in the simple way that XP produces code and requires it to be produced. 

An experienced team may be able to work with existing code, but for a new team it defeats the purpose of XP. These emerging teams need to have the experience of seeing just how everything comes together with XP and see the power behind its practices. They need to see how wonderful it is to make big improvements with small changes, and that just won’t happen with pre-built code. 

An Experienced Technical Coach
In XP teams, it is best to have a flat management structure, without predefined hierarchy. In fact, it relies on the team being self-organizing. Leaders will emerge, and the team will decide who to follow, though the roles are generally kept informal, and the leaders can change from moment to moment depending on the task at hand and the strengths of the team members. 

New teams, however, do need the guidance of an experienced, helpful and respectful coach who can help them through the process, without taking command of the situation. They need someone to help them to stick to the XP practices, so they can learn how to use them in the future.

It is most useful to have a coach who is also an experienced programmer, because programmers have the hardest practices to learn. The most helpful coach will be someone who can be respected by the team and who will respect them, without intervening or interfering too much in the process. 

Conclusion
When implementing XP, like many other Agile development practices, patience and support of the teams is the most important thing, along with the proper guidance. Remember, if your team used to use a document-centered production approach, XP may seem very loose and chaotic at first. Alternatively, if you had no process, XP may seem very disciplined. The team needs time to get used to the process and to start experiencing success with it. When this happens, and everything falls into place, everyone will reap the benefits of sticking with XP.