Discover the Right Methodology – Another Perspective on XP

Introduction

Successfully choosing a methodology that would fit well a team with a certain level of expertise and a given software project could be challenging. Picking the inappropriate practices for a given situation could aggravate the development process and result in the team not being able to capture customers’ requirements accurately, or to deliver a quality product within time and budget. In this article, I will discuss the “Extreme Programming” agile methodology which some advocate for its high speed software development and some of its good practices. I will revise its paradigms and attempt to fit them to the methodologies I experienced as a part of a team over an internship programme. I will explain which of them worked very well by accelerating the software development process and by benefiting me as a new team member. I will also discuss which practices present challenges for a team in the context of a larger organisation and attempt to explain how they can be altered to fit this particular scenario. Through these examples I will illustrate the importance for choosing the right practices for the success of the software project.

Extreme Programming

XP is an agile methodology suitable for dynamic and fast-paced environments of teams with fewer than 10 members which produce software prone to quick requirements’ changes. The activities of the XP life cycle are well defined through four fundamental values:

  • constant communication with clients and fellow team members

  • constant feedback thanks to customer communication and extensive testing

  • simple design which aims to solve the current problem rather than focus on potential future problems

  • being proactive when dealing with problems [2]

While some of these XP practices could be identified as good practice in software development, others are difficult to implement for certain team projects due to various circumstances. Some expert suggest that even though practices could be closely interleaved with each other, adopting them consecutively would be a more smooth process which helps developers keep their focus and deliver software. [2] Therefore, striking the right balance is essential when choosing the appropriate methodology, and plenty of factors could influence this decision. I will give examples of such circumstances, those which influenced my team over my internship.

The Case Study – My Team

The team I joined over my internship for a period of 10 weeks was a 8-people team, part of a bigger unit within a software house. Over that period, it was functioning as a core team, meaning that it was developing and maintaining strategic system which developers from other teams would use as platforms to build their applications on. Communication with other teams and clear documentation in order to facilitate others’ work were essential in that context; however, software development was done independently and autonomously. Team members did not have rigid roles which can potentially aggravate the agility of the process. The manager was extremely technical with plenty of experience, so he provided advanced technical advice when needed and he served as a mediator between the team and the organization. The structure of the team could greatly influence the application of agile methodologies; however, it faced the challenges of functioning as part of a larger organisation. [3] Thus, while some XP practices were religiously followed within my team, other were thoroughly reconsidered for that different  context,

The XP Practices

Agile development is difficult to adopt for larger teams; however, 8-people could easily accommodate the methodology. [1] However, as the team was global (2 people were based in NYC), location did play a role. For example, as a newcomer, I could ask questions and work in close collaboration with my teammates sitting beside me. However, when I had issues with the colleagues in NYC, I had to put down my thoughts in an email or wait until it is an appropriate time to call. I could understand how locations plays a role and aggravate decision making, design discussions, or problem solving. This could potentially increase the need for creating valid documentation or adhering to common coding standards.

 Practices thoroughly followed by my team were the ideas of extensive testing and continuous integration. Test-driven development and automated regression testing were encouraged; suitable test suites allow testing when any changes of the system are implemented; furthermore, as many other people were working with my team’s code, prepared test suites greatly facilitated their work in case they decided to adopt it for their needs. Furthermore, releases were performed every two weeks, in order to ensure that any bugs are fixed, requirements implemented or issues addressed, and feedback collected. Pair programming was encouraged when necessary, work stations were being provided.

XP puts emphasis on always implementing solutions to the immediate problem first.[2] The precept “You Aren’t Going to Need It” advocates that the architecture must be as simple as possible and not adhering to future changes. [1] However, as a core team, my team had a dual role of implementing requirements expressed from other teams but still preserving ownership of their projects, improving the architecture and keeping it strategic so that changes could be easily accommodated. Also, delivering solutions is highly prioritised compared to keeping the documentation of the design extensive and up-to-date. This job is considered a waste of effort as the system might change rapidly. However, having accurate documentation was essential for my team as many other teams based their code on the work of the ‘core’.  Additionally, the company encouraged internal mobility, which meant that it was likely for a new member to join (such as myself). Thus I believe that more emphasis should be put on proper documentation, at least at certain times. Sometimes change in human resource is inevitable, and even though practices such as collective ownership helps everyone to be up to speed, documentation can certainly help. I conclude that the necessity of documentation is brought by the nature of the work of the team, but can also be related to the challenge the team faces by being part of a larger company.

When it comes to interaction with the customers, my team had great experience. As customers were also employees of the firm, they were dedicated to the problem, as collaborative as possible, and knowledgeable about the software development process. The “Customer Involvement in XP” workshop reached the conclusion that such customers would best fit the agile methodology [1]. However, geographical location greatly influenced the work process.

The Challenge

My team deviated from the XP paradigm by establishing a sense of “institutionalization.” It was inevitable; being a part of larger body can always be a challenge when adopting agile practices. Even though the team was autonomous itself, sometimes it was necessary to take into consideration the company’s ‘good practice.’ However, as some practices represented challenge for the agile process, some cultural concepts that the organisation encourages, such as teamwork and extensive communication, could bring good vibe in an agile atmosphere. Therefore, when implementing XP within a unit of a company, it is important to deeply evaluate the context of the environment. Using certain methodologies could introduce challenges but also certainly refresh the development process.

Conclusion

By using some of the XP practices, my team could greatly improve its dynamics and delivery. However, other aspects of the XP paradigm could not be extended to all aspects due to understandable challenges. Therefore, in order to bring in the right methodology, it is important to consider how it will benefit the team, or what problems it might raise. Over the course of my internship, I witnessed how my team took advantage of good XP practices while keeping itself in the loop of the corporation.

References

[1]Boehm, B., “Get ready for agile methods, with care,” Computer , vol.35, no.1, pp.64,69, Jan 2002

 

[2]Paulk, M.C., “Extreme programming from a CMM perspective,” Software, IEEE , vol.18, no.6, pp.19,26, Nov/Dec 2001

[3] Boehm, B.; Turner, R., “Management challenges to implementing agile processes in traditional development organizations,” Software, IEEE , vol.22, no.5, pp.30,39, Sept.-Oct. 2005