Extreme Programming in Agile – A Practical Guide for Project Managers and nTaskers



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


Source: Udacity.com


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 Extreme Programming (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 Extreme Programming (XP) made of?


The Values


XP incorporates the following 5 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 doing 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


extreme programming


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.


Also Read:

How to Manage a Project like a Pro in today’s Work Environment?


Pair Programming:  The idea behind this practice is that 2 brains are better than one. Pair Programming refers to software production through 2 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 10 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.





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 4 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 for keeping track of relevant agile metrics, and it is essential for progress evaluation and identification of key areas for improvement. This is important for progress tracking and identification of key areas for improvement. Some of these metrics may include the amount of time worked, 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.


Advantages of Extreme Programming

  • Extreme programming allows the software developers to focus on coding and not worry about the unproductive activities related to the project
  • The most important benefit of extreme programming is that it allows the software companies to reduce the expenditure of resources like money and time on useless activities when they can be spent on activities like project realization and other brainstorming sessions
  • Extreme programming also reduces the risks of project failure or coding malfunction, ensuring that the client will get their desired product in the end
  • Extreme programming is an amazing methodology that doesn’t require the code to be complex and hard for everyone to understand and that shows in the code of the developers that use this methodology because whenever someone else takes over their position, they can understand the code very easily
  • One of the best things about XP is that everything is transparent and Infront of everyone which helps keep everyone and everything accountable
  • Constant feedback is also an incredible feature of extreme programming which allows the developers to code fearlessly and without the fear of judgment because they can always fix the minor mistakes, they make through the help of the feedback they receive
  • Regular testing of all of the elements of the software, bug detection for all of the code, and the use of customer validation tests ensure that the client gets a working prototype or the actual working software in less time than normal
  • Extreme Programming also helps companies in satisfying their customer and retaining their business for a longer time
  • In extreme programming methodology, everyone is an equal member of the herd and everyone must share the burden as their peers, which means that from the requirement to code, developers will work side by side so that no one feels unappreciated or forgotten


The Extreme Programming (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, indicates 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 Practices (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


extreme programming pert certification


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 2 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. However, 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.




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 Practices for IBM and Sabre Airlines


The Problem

To assess the practical applications of Waterfall vs. Extreme Programming, a research study was conducted through 2 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 2 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 2 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 application. 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.




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.
  • 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 1: Web Development


Problem Statement: The company website needs to be redesigned.

Actors: Customer, Developers, Tracker

  1. Regular Flow of Events:
  2. The customer informs of initial requirements.
  3. The development team starts programming.
  4. The QA team tests for bugs and informs the programming team
  5. The customer has more requirements
  6. 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. The 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 2: 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, 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)


nTask for Extreme Programming Practices (XP)



nTask is a Task Management System that supports the Agile method of Extreme Programming framework. It is an online task management application designed specifically for teamwork and project delivery. Regardless of the industry, nTask facilitates the XP methodology and contributes to effective project planning and process alignment.


The following are some of the ways nTask can help you plan and achieve your project goals better, all within the XP framework.


Meeting Scheduling


You can schedule your sit-ins, weekly meeting as well as quarterly meetings beforehand. The agenda and timings of the meetings can be specified. You may define a fixed time for the meeting or send out a suggested time to the team, to be finalized after team response.


This application also allows you to note down all the important points discussed in a meeting. The minutes can be then reviewed and published for the rest of the team.


Team Allocation


You may arrange your team and the roles they will undertake through the team allocation section. You can easily define roles for the developers, the trackers, and the customer.


Project Creation


The customer may create the project and specify the requirements. The customer can also define the budget and timeline.


Task Creation and Assignment


The customer can create stories by creating tasks within the project. The tasks will comprise a list of activities to complete under one story. These stories can then be assigned to the programmers.


If the stories are completed before time by some of the team members, the customer can assign them the “slack” tasks i.e. lower priority tasks within the remaining timeline. This saves time working faster towards project completion.


Also See:

Introducing nTask 2.0 – Our most awaited update yet


Project Flow


The Project Manager or Tracker can help keep track of the project flow through the Timesheet module. This module allows for effective monitoring and evaluation of project progress. It helps individually assess the timeline for different tasks as well and the milestones reached or pending.


Easy Collaboration


At times it is not possible to hold face to face meetings e.g. when a certain team is working on another site. In such cases, the automated updates on projects, tasks, and meetings can ensure timely and effective team collaboration and discussion. This avoids time being wasted in the manual arrangement of project and task follow up, communicating meeting of minutes, or project update.


Real-Time Comments provides an easy way to communicate with the team. Whether it is the exchange of information or new ideas, this makes it easy for the team to stay on the same page.


The interdependent tasks are highlighted and each team member can check the updates instantaneously as updated by the other team members. This keeps the team updated on the changing situations and in planning the next task, accordingly.


Moreover, the customer can directly collaborate with the team and update any change in requirements.




nTask gives a transparent view of all the projects and corresponding tasks and sub-tasks through its Taskboard. Any project created or modified is communicated to the team, immediately. There is no need for rechecking progress updates, meeting invitations or project reports.


The tasks updated, modified or deleted paves way for the entire team to be fully aware and know exactly what is being accomplished when.


With its Filter option, you can choose to see updates for selected projects based on priority or the task at hand. With the Status option, the status of the selected task can be seen whether it has started or not, completed or in progress.




This write-up details how you can benefit from XP as an Agile worker. In addition, nTask is created to perform such requirements within the domain of extreme programming and waterfall techniques. Therefore, do give it a read and don’t forget to share your thoughts through the comments section below. Alternatively, you can email us at fwilson@ntaskmanager.com.


Also Read: