Extreme Programming Case Study

Zia

1 Follower

Follow

May 27, 2024

-

1 sec read

145

0

0

0

Case Study

WDSGlobal is the leading global provider of knowledge-based services to mobile operators, manufacturers, application providers, and sales channels. In 2004, WDSGlobal brought together three independent development regions to form a development team that operates around the clock. This case study describes the challenges faced by the team in this environment, the lessons learned, and how issues such as global continuous integration, conflicting priorities, and cultural differences were resolved across regions.

1. Background:

WDS Global has ten years of experience in the mobile marketplace. Each step in the mobile product life cycle is aided by the services provided by WDS Global. It includes settling any problems at the pre-launch stage to assisting with specialized customer support. All the efforts that are put into the development environment are dedicated to the refinement of WDSGlobal's mobile configuration platform, which is used on the Sony Ericsson, Nokia, Siemens, and Vodafone Websites. As the mobile industry innovates frequently, the demand for WDSGlobal services has reached a markable level, placing a heavy burden on development teams.

2. One global team:

The company created three regions - the Americas, Asia, and Europe - to meet the requirements of its customers across the globe. It was discovered that the regions had some very different requirements. The company had to locate its developers to meet a market's specific requirements of a particular region and then share the knowledge appropriately.

Till the end of 2003, Web-based tools were developed and deployed using XP and Java, as Application Programming Interfaces (APIs) by the UK team. In each region, a non-XP team uses these internal APIs to deliver localized requirements with the help of non-Java technologies. This process created a lot of unnecessary duplication on the Websites and led to costly maintenance for the different technologies used in each region.

At the beginning of 2004, it was proposed to combine all the development teams into one global team that uses XP and Java. This global team was to share the same code base to minimize duplication and reduce maintenance costs.

3. Hurdles:

The location of the development team led to several challenges. One of these was that the teams did not have frequent communication with each other previously. There were also differences in time zone, culture, and technical backgrounds.

• Time Zone: There was a minimum overlapping of time between the working hours of the three regions. Communication with each other outside their normal working hours impacted personal schedules and family commitments.
  
  
• Cultural Differences: Even though the members of all regions spoke English, many misunderstandings arose because the groups did not share a high-level common language. There were also several issues caused by unrecognized cultural differences which frequently led to confusion and disagreements between regions.
  
  
• Technical Background: The programming styles varied greatly among the regions. For example, the members of the UK team had a background in object-oriented programming and had some experience with Extreme Programming. The U.S. and Singapore developers preferred working in an academically correct manner. They did not have any experience with unit testing or refactoring. On the other hand, some other members were not familiar with the XP process or object-oriented programming. They focused on getting work done quickly and learned new tools and techniques when required.
  
  
  

1. Transition to XP

WDSGlobal faced several technical, ownership, and training-related challenges during the transition to a global team.

The Source Control System (CVS) used by the UK team was not practically feasible for remote use. It took up to 40 minutes to synchronize any changes from a remote region. This led to the selection of Perforce, a new source control system. Local proxies had to be installed to deal with performance problems. Two more build machines had to be created as the UK build machine was not sufficient enough for all regions. There were no pairing machines in the U.S. and Singapore regions, so new pairing machines and desks were purchased and installed according to the same specifications as those in the UK. To accommodate the cube-free structure and pairing stations, both regions had to restructure their office space.

Given that the UK team had created the original core back-end segment of the system, they had difficulty sharing ownership with the other regions. While the new processes and technologies were welcomed by some of the U.S. and Singapore developers, others were overwhelmed and could not adapt to the large shared code base and the new XP practices.

Some of the changes done were as follows:

• Regional Coaches: An XP coach was hired in each region as the non-XP regions did not have any Prior experience with Agile methodologies or Object-Oriented Programming(OOP). The coaches trained the local team in XP and object-oriented programming with Java. The coaches also helped local business units adjust to the new development process. In due course, the coaches recruited more people with Agile and OOP experience in the region. They also conducted weekly coach meetings which helped bring the teams together.
  
  
• Boot Camp: To develop mutual trust, the original UK XP team and developers from the non-UK region spent several weeks working together in the UK office. By working alongside each other, the developers were able to build initial trust relationships and share common work practices. This helped a great deal in focusing their energies as a team towards solving problems and producing innovative solutions.
  
  
• Rotating Guru: The non-UK regions required help setting up infrastructure, initial training, and mentoring. To assist with this, a senior member of the original XP team was sent to those particular regions. This provided the UK developers, an opportunity to identify and analyze the difficulties the other teams dealt with in developing remotely from the UK servers.
  
  
  

2. Problems Faced During Transition

• Preparing the Business: Although WDSGlobal trained the developers in XP methodologies, it did not adequately prepare the business in each region for a dramatic change in the process. WDSGlobal did not have the necessary resources to train business units and developers.
  
  
• Switchover: In April 2004, all the development teams were using XP as the development process and Java as the technical platform and were virtually one team. The non-UK regions had the most trouble during the switchover as they had no prior exposure to XP and 0OP. As a result, some were not able to make the transition. It would have been a better approach to have a more gradual transition by formally training the non-UK regional developers on Java and OOP, pairing them with Java developers for three months, and then teaching them XP practices.
  
  
• Inadequate infrastructure: The new distributed development environment was too large for the current global infrastructure to cope with. The network bandwidth did not support the large amounts of data and traffic through the network between the regions. The U.S. and Singapore developers experienced long delays during file copies. Continuous integration builds across servers located in different regions were a time-consuming process. These concerns were addressed in a step-by-step manner - by using Perforce and its caching proxies as the source control system and increasing the network bandwidth.
  
  
• Continuous distributed development: The standardization of values and principles across the board leads to the success of an XP team. This includes a shared knowledge of refactoring, coding standards, and test-driven development. However, the interpretation of the particulars of these principles and values differs from person to person. In a non-distributed XP team, common ground is achieved through individual adjustments and communication among team members. In a distributed team environment. As team members are located in different countries and time zones and come from different cultural backgrounds, they do not enjoy constant communication.
  
  
  

3. Solution to Problems

The global team found it difficult to maintain a common process vision and values. Everyone on the team had to trust each other as equal team members to share the same code base and system. Without proximity, the trust relationship worsened over time.

In a non-distributed XP team, when new ideas and technologies are introduced, the team agrees to the team proceeding. With the virtually combined, yet distributed team. It was tough to introduce new technologies or architectural changes.

• Daily handovers: Communication within the team is crucial to XP. In a distributed team, communication is of the utmost importance. Daily handovers took place when one workday ended and another began, among the three regions. Using Seattle time as a base. The handovers were done in the following manner:
  
  9 a.m. - The UK region hands over the system to the U.S.
  5 p.m. - The U.S. region hands over to Singapore.
  The Singapore region then hands over to the UK at the end of their workday.
  
  Initially, the daily handovers were mainly daily status updates. The objectives of the handovers gradually improved toward sharing daily learnings, collectively developing design ideas, and identifying and addressing. Cross-regional issues.
  
  
• Face-to-face Communication: The use of video conferencing for daily handovers and customer requirement gathering sessions as face-to-face communication is considered much more effective than e-mail or phone conversations.
  
  
• Shared Common Environment: In the distributed team, all pairing machines are installed in the same way to help minimize configuration and adjustment time when development pairs rotate on different machines. The configurations are checked into the shared source control system, so all developers receive configuration changes automatically when they synchronize with the system as they begin each workday.
  
  
• Remote Pairing: The close interaction within a non-distributed XP team often allows the team to form a group mind. These happen not just through pairing session experiences, but also through informal discussions at coffee breaks or lunches. This shared context based on prior knowledge and experience helps each team member understand the others better when a complex idea or design is being discussed. This is much more difficult to achieve in a distributed team. Frequent remote pairing sessions where two developers from different regions would pair using Virtual Network Computing (VNC), teleconferencing, and the Integrated Development Environment (IDE) were introduced to help create a group mind across regions. This often helped improve collaboration and sharing, avoid misunderstandings, and encourage shared memory between the pairs and, through them, the teams.
  
  
• Round-the-World Program: Specific local market conditions influence the decisions made by a team within a region. These decisions may not be understood by other regions. The trust relationship across regions eventually breaks down if misunderstandings are not sorted out, and collaboration becomes impossible. The round-the-world program which rotates members to another region for several weeks was introduced as a solution to this problem. Longer visits of four to six weeks are most effective, though this may not always be possible due to personal constraints or funding limitations.
  
  
• Shared Stories: The regions were encouraged to work together in an around-the-clock manner on stories that applied across all regions. This encouraged conversation and cooperation which in turn helped build common values and mutual trust and improved the relationship between the regions.
  
  
• Putting Out Fires: If in case an emergency production issue could not be addressed during one region's working hours, it was handed over to the next region until it was fixed. This approach forced the regions to communicate detailed designs and strengthened the trust level.
  
  
• Coach-to-Coach-Level Communication: It was essential for the coaches to maintain a constant level of communication and synchronization. Coaches talked to each other after the daily handovers and all coaches met weekly through teleconference to ensure that any general or cross-regional issues were addressed and resolved. The coaches met in person every quarter, for two weeks to address more complex issues and conduct long-term planning for the quarter.
  
  
• XP Principles and Practices: XP principles and practices helped the distributed team maintain a certain level of common values and knowledge. As XP encouraged open communication and collaboration, it increased communication across all regions. The XP core principles, such as refactoring and Test-Driven Development (TDD), allow the team to share a common language. However, as these principles and practices may not always be understood in the way across regions, regular discussions are required to cultivate a common understanding.
  
  
  
  
  

4. Outcomes of the Adopted Solution

• Balancing the Teams: In the distributed team environment, the region that had the most number of developers contributed more to the architecture and design of the project, and the other regions were forced to accept. This deterred cooperation between the teams. It was important for each region to have the same number of developers and skill levels.
  
  
• Introducing Process Changes: Rules and predefined processes ensure that team members know what to expect from each other. When one region introduced high-level process changes without discussing them with the other regions, it confused. The collaboration and trust relationship between regions would suffer if these kinds of incidents were left unresolved. The team decided that prior agreement from all coaches was required to introduce a major process change.
  
  
• Introducing Innovation: Introducing architecture changes or new technologies was the most difficult part of the distributed team structure. Usually, this is introduced in one region and then brought into the code base, where the other regions support it. A lack of consensus made integration difficult. Getting feedback and approval from the whole team was tough and required time. Unfortunately, the team still has no perfect solution to this problem.
  
  
• Allowing Process Flexibility: Each region requires a certain amount of process flexibility due to its unique culture. This flexibility is needed to balance the requirement for a global process and local adaptation.
  
  
• Outside Forces: The teams were managed by their local offices and were treated as local resources before they were combined into a global team. Most of the team members did not follow a formal development process. After becoming a global team, regional offices had to be involved in planning and global story prioritization. As this called for an uninterrupted weekly plan, it was not well received by the local teams who worked in an ad-hoc fashion. The company gradually developed a process for building a consolidated monthly product backlog, known as the Company Program Plan.
  
  
• Including the Business: At the beginning of each week, the business managers worked with the team to plan and prioritize stories. Following a fixed plan for a whole week was initially tough for the team to accept as they were used to making changes daily. During the iteration, the coaches and business managers worked on planning and prioritizing new stories based on new business requirements.
  
  
• Incorporating QA: Before using XP, the team did not use automated user tests, and in some cases, the new software was even released without customer signoff. As quality assurance is an essential part of the XP process, the team adopted a user acceptance testing framework, Selenium by Thought Works, and trained a non-technical business team to work with customers to automate user acceptance tests. This effort is still in its initial phase, but the team is already seeing positive results.
  
  
  

5. Conclusion

After a year, the company considers the transition to a globally distributed XP team to be successful. The team has proved that XP works for a globally scattered group developing around the clock with a shared codebase. With distributed XP, the company enjoys the advantages of an Agile process: the developers have direct contact with regional customers, and the business can accommodate changes in the local and global markets while producing and delivering quality products. Even though there is still much scope for improvement, the team is already on the right track to success.