The following are the prerequisites for adopting XP:
- Team agreement
- A collocated team
- On-site customers
- The right team size
- Use all XP practices
The team’s agreement to use XP is as important as management support. If team members do not want to use XP, it’s not likely to work. XP assumes that each team member’s willingness to adopt it. It is not a good practice to force the process on somebody who is resisting it.
XP relies on high-frequency and high-speed communication for most of its practices. To achieve that communication, the team members must sit together in the same room. (Source: Reproduced from Schuh, P .(2003). Integrating Agile Development in the Real World, 1st ed. USA: Charles River Media, Inc. p 280) The seating arrangement of a collocated team is based on a ’caves and
commons’ approach. The objective of this approach is to provide people access to ’commons’ where they can interact together, and ’caves’ where they can work alone.
On-site customers are essential to the success of an XP team. They, led by the product manager, decide which features the team will develop. These decisions impact the value of the software. Therefore, the customer is part of the development environment. Having an on-site customer is the best way to get immediate feedback. When the customers are on-site they can
answer queries immediately. When both customer and developers are guided by a reflective mode of thinking, they can improve their understanding of the software or application being developed. For example, when after some problem is corrected, the customer and the developers can reflect on their current understanding of the software or application and compare it with the understanding that preceded it. XP encourages short release cycles. Consider the problems when the customer only sees new releases of the software every few months. If there is considerable time in between feature releases, the customers cannot give
real-time feedback to the programming team. Months of hard work may go waste if customers change their minds, or if the programmers do not deliver what is expected by the customer.
The right team size
According to the proponents of XP, certain factors make some projects well suited for this methodology. The first major issue is the size of the team. In general, XP is most effective in cases where small teams, of usually two to 12 programmers, are involved. Small teams are more flexible, and better able to adapt to changes than 50 or 100-person programming giant teams. An XP team cannot just have one member. It needs an even number of programmers due to the XP concept of pair programming. To use this approach, pair the team. Each pair must share a single computer and each person in the pair must focus on a different angle of the problem. While one developer types and actually applies and implements the code, the second
developer must check for syntax and spelling errors. The other developer must understand how the current module that is being developed fits into the whole work. The two developers in the pair alternate their roles as required and brainstorm on the best approach a particular problem.
Teams with less than four programmers may not have the intellectual diversity needed. They will also have difficulty using pair programming, which is a significant support mechanism in XP. However, large teams face challenges of coordination. Although experienced teams can handle those challenges efficiently, a new XP team may experience difficulties in the beginning.
Use all XP practices
XP utilizes all the resources of the project efficiently. It also ensures that every practice directly contributes to the development of valuable software.
- answered 6 years ago
- Gul Hafiz