Extreme Programming in Agile – A Practical Guide for Project Managers

We have received an awful lot of requests about extreme programming in waterfall — and that how one could benefit from it as a project manager. Just in case you didn’t know what extreme programming is, it is a form of agile framework where PMs get the best out of available resources in a software development environment.

Extreme Programming (XP) In Agile SDLC Environment

Extreme Programming (XP), an Agile software development framework, is specifically designed for improving the quality of the software, the work process for the development team and increased customer satisfaction.

It is a method devised for a smoother and efficient software development life cycle (SDLC) for your projects, and it was first implemented on a project on March 6, 1996.

Why XP?

Extreme Programming works towards providing iterative and recurrent software releases throughout the project; instead of everything together after a single, long project development lifecycle.

These short iterative cycles help both team members and customers to assess and review the project’s progress throughout its development.

What Is XP Made Of?

The Values

XP incorporates the following five values:

• Communication: Software Development projects or projects in any industry rely heavily on communication. XP focuses on effective communication between the team and the customer.
• Simplicity: XP looks for the simplest ways to get things done. This means to do what is essential thereby reducing waste, address only the known issues and keeping the design simple for effective creation and maintenance.
• Feedback: Feedback plays an important role in project improvement. XP encourages instantaneous feedback. This helps the team identify room for improvement and revise practices.
• Respect: The team must respect each other both personally and professionally, to achieve goals.
• Courage: XP endorses courage at all levels. This can include speaking up against what does not work and anything that affects the project’s effectiveness, or accept feedback and improve methodologies.

The Practices

The core of XP is an interconnected set of software development practices. While it is possible to implement these practices in isolation, many teams have found that some practices reinforce the others and should be done in conjunction. This can enable fully eliminating the risks you often face in software development.

The original twelve practices for XP comprise:

• The Planning Game

• Small Releases

• Metaphor

• Simple Design

• Testing

• Refactoring

• Pair Programming

• Collective Ownership

• Continuous Integration

• 40-hour week

• On-site Customer, and

• Coding Standard.

Over the years, teams have found that some practices reinforce the others. To eliminate risks, these should be unified. The following descriptions include some of the refinements based on various teams’ experiences —

Whole Team: Teams should comprise cross-functional groups of people with different skills. In this way, they can complement each other to accomplish a specific outcome.

Sit Together: Most people agree that face to face conversations are the best form of communication. Teams should sit together without barriers to communication e.g. cubicle walls.

Informative Workspace: Teams should be arranged to sit in a way to make the team’s work transparent to each other and the affiliated people outside the team.

Energized Work: This means making sure that a person is mentally and physically healthy to focus on work. This also implies there should be no over-work and respect teams to support their mental and physical health as well.

Pair Programming: The idea behind this practice is that two brains are better than one. Pair Programming refers to software production through two people sitting at the same machine. By this, there is a continuous work review and problems receive a faster response. This method has been shown to improve quality and stay more focused.

Stories: Stories define the features that the product should have that would be meaningful to customers and users. These stories are used for planning and also serve as reminders for further conversations.

Weekly Cycle: The first day of every week, the team meets to reflect on the progress to date. The stories that should be delivered in the week are selected by the customer. The team determines how to approach those stories. The goal behind this is to achieve a running, verifiable feature by the end of the week. The fixed period allows for the production of a feature that can be shown to the customer for feedback.

Quarterly Cycle: The purpose of the quarterly cycle is to check the detailed work of each weekly cycle in the context of the overall project. The customer provides the overall plan for the team within a particular quarter. This not only gives the team a view of the project but also helps the customer to work with other stakeholders involved.

Slack: This implies adding a few, low priority tasks or stories in the weekly and quarterly cycles. If the team is lagging on more important tasks, these can be dropped. Else, these will also be completed, increasing the chances of meeting the estimated schedules.

Ten-Minute Build: The entire system and all of the tests should be run within ten minutes. If the time exceeds this limit, multiple reruns will cost larger periods between errors. This practice encourages automation of the build process, making it feasible regularly, to run all of your tests.

Continuous Integration: This practice encourages immediate testing of new code to the existing larger codebase. This helps catch and fix integration issues sooner. This practice requires discipline and depends on the practices of Ten Minute Build and Test First Development.

Test-First Programming: Instead of following the regular way i.e.,

Develop Code -> Write Tests -> Run Tests

the practice of Test-First Programming takes the path of:

Write Failing Automated Test -> Run Failing Test -> Develop Code to Make Test Pass -> Run Test -> Repeat

This practice, too, reduces the feedback cycle for issue identification and resolution. This results in a reduction in the number of bugs that get introduced into production.

Incremental Design: This practice portrays doing a certain amount of work upfront to understand the breadth-wise perspective of the system design. After that, work further on the details of a particular aspect of the design when specific features are delivered. This approach reduces the cost of changes and allows you to make design decisions when necessary based on the most current information available.

Roles

XP incorporated particular practices for your team to follow and does not establish specific roles for the team members; however, according to the requirement, the four most common roles are:

The Customer: The XP Customer is expected to actively participate in the project. The Customer makes all of the business decisions regarding the project such as:

· What should the system do? This refers to the features that are included and what they accomplish

· When is the system done? This implies the acceptance criteria

· How much should be spent? Which means the budget for the project, and

· What should be done next? The order ins which the features are delivered.

The Developer: Developers realize the stories identified by the Customer, which means deliver a project with decided features.

The Tracker: The tracker is an optional role and depends if the team requires one. This is carried out by one of the developers that keeps track of relevant metrics. This is important for progress tracking and identification of key areas for improvement. Some of these metrics may include the amount of time worked, the amount of overtime, the passing and failing tests, velocity, and reasons for variations to velocity.

The Coach: This role is helpful particularly if the team is just starting up. The Coach can be an outside consultant who has used XP before and can help mentor the team on the XP Practices as well as self-discipline. Employing the Coach helps avoid potential mistakes that new teams may make, expediting the project.

The XP Lifecycle

The XP lifecycle can be explained concerning the Weekly Cycle and Quarterly Cycle.

To begin with, the customer defines the set of stories. The team estimates the size of each story, which along with relative benefit as estimated by the customer, indicate the relative value used to prioritize the stories.

In case, some stories cannot be estimated by the team due to unclear technical considerations involved, they can introduce a Spike. Spikes are referred to as short, time frames for research and may occur before regular iterations start or along with ongoing iterations.

Next comes the release plan: The release plan covers the stories that will be delivered in a particular quarter or release.

At this point, the weekly cycles begin. The start of each weekly cycle involves the team and the customer meeting up to decide the set of stories to be realized that week. Those stories are then broken into tasks to be completed within that week.

The weekends with a review of the progress to date between the team and the customer. This leads to the decision if the project should continue or if sufficient value has been delivered.

Case Studies for Extreme Programming (XP)

XP for Krizp System

The Problem

Krizp Solution was a startup, web-based development company in India. Their business plan encompassed the creation of web portals for other small companies or educational institutions. The company began as a part-time business, employing people that were already working for other major IT organizations. The plan was to continue full-time only if the startup ventured into a success. There was no framework for their software development processes as it was just a startup company with not many projects and a few employees.

The company lacked a structured approach to software development. With initial requirements jotted down on paper, further information and clarifications were received from the customer via phone calls. Usually, the major changes in requirements did not come about until the customer review, which was after the solution was developed.

Other than for bug fixing, the developers had little or no communication with each other. They worked separately on different features. This led to becoming a barrier for discussions regarding improvement in working methods.

Moreover, the projects were not documented. There was no project manager to track the projects or to make sure that the requirements laid out by the customer were being met. The developers worked only on what was asked to be done.

The Journey

The team at Krizp System was introduced to the concepts behind the different Agile frameworks. The XP method was employed over a span of one month and the results were assessed.

The CEO of the company took on two roles: the customer representative and the tracker. For his first role, he prioritized user stories, delegating them to the development team and had regular communication with the customer. As the tracker, he kept track of the time to complete specific tasks. The CEO also initiated the planning game every week (or at least once in four days), as the project was small and developers could complete tasks in one user-story faster. The customer was available for direct communication only twice per month and the rest of the time he was in contact through phone calls and e-mail.

The Paired Programming technique was adopted whereby both the developers worked together. After task completion, both of the developers reviewed the code with the CEO.

Customer tests were introduced and the team worked on continuous design improvements, which were about 12-15 per month.

Summary

The XP approach seemed to have a good impact on the software development cycle for the company. Some of the positive changes included:

1. Better team collaboration, communication, and feedback

2. Better task and time management, and

3. Increased CEO involvement without technical contribution.

Extreme Programming for IBM and Sabre Airlines

The Problem

To assess the practical applications of Waterfall vs. Extreme Programming, a research study was conducted through two case studies: one at IBM and the other at Sabre Airlines. Each case study compared the waterfall approach to the XP approach.

The Journey

In the first case study, at IBM, the researchers wanted to study the impact of adopting the XP approach on productivity, quality, and customer satisfaction. A year-long study was conducted on a team of 7 – 11 members regarding the adoption of XP practices. The team was responsible for developing Servlet/XML applications for a toolkit utilized by other IBM teams to create products for external customers. The case study analyzed two approaches on consecutive releases of the same product. The first one was the traditional waterfall approach and the second was XP.

In the second case study, at Sabre Airline Solutions, the same method was used i.e. comparing two approaches through different releases of the same product. The team worked on developing a scriptable GUI environment for external customers to develop customized end-user and business applications. The team comprised of 6-10 members. The old release was finished 3 years prior (spanning 18 months) using the waterfall method whereas the new release was completed recently (spanning 3.5 months), using XP.

The first step was to establish an Extreme Programming Evaluation Framework (XP-EF), which comprised three parts: XP Context Factors (XP-cf), XP Adherence Metrics (XP-am) and XP Outcome Measures (XP-om).

XP Context Factors (XP-cf): XP-cf was used to record important information related to the project. These factors included team size, project size, criticality, and staff experience.

XP Adherence Metrics (XP-am): Through XP-am, the extent to which the team uses the XP practices were expressed. The XP-am also helped in investigating the interactions and dependencies amid the XP practices as well as the degree to which the practices can be detached or removed.

XP Outcome Measures (XP-om): XP-cm enabled assessment of business-related results i.e. productivity, quality, etc.

In addition to the framework, interviews were conducted with team members and customers to help understand incorporating XP by the team for the customer’s satisfaction.

Summary

At IBM, the XP method seemed more productive compared to the waterfall method by the following measures:

Test Defects: for pre-release, the defects were 50% lesser and for post-release, the defects were about 40% lesser in the release through the XP approach.

Productivity: There was a significant increase in staff productivity using the XP approach than in the waterfall method.

Customer Satisfaction: Customer satisfaction was noted to be high in XP and documented as N/A for the waterfall.

Morale: The morale of the stakeholders was recorded as high in XP and documented as N/A for the waterfall.

At Sabre Airlines, similar results were noticed:

Defect Collection Period: As the first release was created over 18 months, the defect collection period was also longer in the waterfall-based approach. It was significantly shorter in XP based release. accordingly

Test Defects: for pre-release, the defects were 65% lesser and for post-release, the defects were about 46% lesser in the release through the XP approach.

Productivity: Staff productivity using the XP approach was about 46% higher than in the waterfall method.

Customer Satisfaction: Customer satisfaction was noted to be high in XP and documented as N/A for the waterfall.

Morale: The morale of the stakeholders was about 68% XP and documented as N/A for the waterfall.

Use Cases and Application

Use Case One: Web Development

Problem Statement: The company website needs to be redesigned.

Actors: Customer, Developers, Tracker

Regular Flow of Events:

1. The customer informs of initial requirements.

2. The development team starts programming.

3. The QA team tests for bugs and informs the programming team

4. The customer has more requirements

5. The cycle repeats.

Using XP:

1. Face to face meeting is called involving the customer and developers.

2. The customer defines requirements, the budget and the timeline in the form of a story.

3. The Project Manager becomes the Tracker and tracks project progress.

4. Development team starts working in pairs. The code is written and debugged at the same time.

5. Each week a meeting is held to discuss the progress. The customer can define new requirements.

6. Every quarter a meeting is held to discuss the status of the stories.

7. After old stories are completed, a new set of stories are formed (requirements for the next quarter)

Use Case Two: Game Development

Problem Statement: A client requires a game to be developed from scratch.

Actors: Customer, Developers, Tracker

Regular Flow of Events:

1. The customer gives requirements, the time and budget.

2. The developers start programming.

3. The QA team tests the game modules.

4. The customer has more requirements.

5. The cycle repeats.

Using XP:

1. Face to face meeting is called involving the customer and developers.

2. The customer defines requirements, the budget and the timeline in the form of a story (game modules).

3. The Project Manager becomes the Tracker and tracks the game development progress.

4. Development team starts working in pairs. The code for different modules is written and debugged at the same time.

5. Each week a meeting is held to discuss the progress. The customer can define new requirements.

6. Every quarter a meeting is held to discuss the status of the stories.

7. After old stories are completed i.e. high priority modules are finished, a new set of stories are formed (requirements for the next quarter)

Did you find this overview helpful? Did I leave anything out? Comment below and let me know!