Extreme programming is one of the Agile methods. It is different as it is

• Lightweight
• Reduces risk
• Efficient
• Supple,
• Anticipated
• Easy

& most importantly, it’s an exciting and fun way to develop software.

Extreme Programming

• What is eXtreme Programming: We will take a look at eXtreme Programming (XP) definition.
• Why is it called eXtreme: We will start by explaining to you how the improvisation of the functionalities and practices helps in increasing the efficiency and making it extreme.
• Values, Principles, and Practices: Here, we will discuss all five principles and values in detail, along with a detailed description of all the 12 practices.
• XP artifacts: Discussion of the three most important artifacts and others happens here.
• What are the different activities of Extreme Programming? Here we will talk about all the activities performed in the Extreme programming. We will explain them in detail with the help of a diagram.
• Extreme Roles and Responsibilities: Discussion on all roles, including the two most significant roles, i.e., customer and developer roles, along with their set of responsibilities and the skills required, happens here in detail.
• Phases of eXtreme programming:  This section includes a description of complete process flow and all the steps in software development using extreme programming with the help of a process diagram.
• Differences between Extreme Programming and Scrum: Here, we will explain the significant differences between the two main Agile methods.
• Why eXtreme may fail: This section explains what the disadvantages of eXtreme Programming are and why it may fail. It tells us what measures should we take to avoid the failure.

What is eXtreme Programming?

As per Wikipedia - Extreme programming (XP) is a Software Development Methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Why is it called “Extreme?”

Because it increases efficiency and likewise ensures the application of principles and values in an extremely effective manner. It is done by

• Firstly, reviewing the code at every step in every iteration to make it more effective
• Secondly, by doing Regression testing at every stage of development to make testing more effective.
• In addition to the above, daily re-using of codes makes the design more effective.
• Moreover, short iterations make delivery more effective.

The below figure shows us how the typical software development phases and values, have been pushed to their extreme level in this method of development.

Kent Beck originally defined extreme Programming (XP) in 1996; however, its second version had an explanation of the principles, which got released in 1999. The main focus of extreme programming is customer satisfaction, and their development teams achieve it by organizing itself. They develop features when the customer needs them. In addition to that, Extreme programming takes the best practices of the development process to an extreme level. In today's rapidly changing market, it uses the iteration method to adapt to the new requirements quickly. It’s a highly disciplined way of continually delivering high-quality software faster. Moreover, the customer is actively involved with the team to perform continued planning, testing, and rapid feedback to provide working software frequently.

XP is one of the most popular methods. It is lightweight because

• Firstly, it concentrates on getting more feedback, rather than asking customers upfront about what he wants.
• Secondly, it delivers value to the customer in small iterations (1 or 2 weeks).
• It encourages change. In other words, it tries to accommodate all the changes suggested by the customer feedback, then redesigns it, recodes it and retests it.
• Moreover, it tries to eliminate defects at the early stages, therefore reducing rework and cost.
• Keeps the customer involved throughout the project.

When to use Extreme Programming:

• Extreme programming application happens in the projects where the requirements keep on changing.
• In some critical projects, even before starting the project, the timelines are decided. It is referred to as project risk as it is challenging to meet those timelines. Therefore, Extreme programming also addresses the project risk by frequent and shorter development cycles and consequently enabling early feedback.
• XP gets applied where we have a small group of programmers, not more than 12.

Values, Principles, and Practices:

Values

There are five values of Extreme programming

1. Communication:

Communication is the most crucial part of any project. Proper communication is needed to fill the gaps between what the developer is making and the customer requirement. It will help in reducing rework if we know the exact condition. In addition to that, proper communication within the team (the developers) is also needed to ensure that they all are on the same page.

For instance, let's say in a restaurant if a customer tells the waiter specifically that he wants his dish to be

• Less oily
• Mildly spicy
• Less salty due to medical reasons.

But the waiter tells the chef to make the dish less spicy. After that, when the meal arrives, it gets rejected by the customer, the reason being; it had oil and the usual amount of salt too. And the chef had to cook it again. All because there was no proper communication between the waiter and the chef.

2. Simplicity:

We need to start developing the most straightforward features first, and then later, we should move to the problematic and extra functionalities. It should be simple, and we should work on the need at the moment. In addition to the above, we must not worry about future requirements and should not make it complicated, assuming that this feature might be needed later. The developers and testers will easily understand simple code and design.

For instance, when the chef has multiple orders, then he always starts with whatever he finds comfortable and is confident that he can cook well.

*Like, during exams, we were always suggested by our seniors to start with whatever is the simplest. *

3. Feedback:

Continuous feedback helps you understand how great you are doing. It works as a catalyst for the project. In extreme programming, feedback can come from different sources like

• Customer: After each iteration, one function will get delivered to the customer who will perform the Acceptance test. Based on acceptance test results, the developers get the feedback and work on it subsequently.
• System: The main reason for performing the Unit test is to get feedback. When writing the Unit test or performing an Iteration test, they get to know from the state of the system if there are any flaws in the coding.
• Within the team: The purpose of forming a team is to help each other and work as one. Whenever the customer comes with a new requirement, the team can provide feedback about estimating the time required & setting up an expectation with them based on their previous experiences.

For instance, developers are like chefs in a restaurant. They should be ready to accept feedback from all the sources in the same vein as a chef can get feedback from the customer, his senior chef, the waiter, or the management.

4. Courage:

In Software development, courage means:

• Firstly, to provide confidence to the developers to take brave decisions by understanding all the aspects involved.
• Secondly, it gives the programmer confidence and enables the programmer to refactor (re-use) the used code, as and when needed. In other words, the developer reviews the current code and changes or modifies it to fit for future purposes.
• In addition to the above, it supports lead developers in deciding to make the rest of the developers work more efficiently. For example, when a programmer gets trapped in a difficult problem for an entire day, he may prefer to take a break and solve it quickly the next day. However, it will be possible only if he is persistent.

For instance, in a restaurant, the chef is responsible for deciding the ingredients, the time of cooking, and the spice. It is the kind of faith that the team shows in the chef and gives him the courage to make his own decisions.

5. Respect:

In Extreme programming, everyone respects each other.

• Respect is the base of all four values.
• We can gain respect by adopting above for values in the system.
• Moreover, this value is more about teamwork.
• To sum up, this value is dependent on the above four values.

For example, in a restaurant, everyone has their specific roles and other values. A chef will respect and value whatever the waiter says; the chef will never go back and check with the customer if the waiter is right or not? Similarly, the waiter, while serving, will never ask the chef about the dish. The waiter will respect the chef's experience and skill.

Principles:

The below principles get applied during the entire procedure of Extreme Programming:-

1. Rapid feedback:

Rapid feedback means the time between receiving feedback and implementing it in the system should be minimal.

• Developers design, implement, and test the functions. Consequently, the feedback is shared immediately and gets applied with no delay.
• In addition to this, the code is reviewed with the system, too, and the feedback gets shared instantly.

2. Assume Simplicity:

This principle suggests that the developers should try to handle every problem with simplicity like,

• A developed code should easily refactor (re-use after some modifications) to do additional tests by performing unit tests.
• Try to keep the code simple and follow the rule of “you are not going to need it”. In other words, it means if we don’t need it now, we should not keep it.
• "Do not repeat yourself", the developers follow this principle. That is to say; you should not keep multiple copies of the same document, code, task, or anything.

3. Incremental change:

Incremental changes mean the “changes in small steps”. Extreme programming supports incremental changes. It means at a time only very:

• Small changes in the plan
• Minute changes in a team
• Small changes in the design

4. Embracing change:

It is the approach that talks about adopting and considering most of the changes, while the actual problem is getting solved simultaneously. Therefore, embracing change talks about

• The ability to accept the changes in your current work.
• Adapting those changes without harming your work.
• Providing the same performance under the implementation of those changes as well.

5. Quality work:

Providing the best quality product is the main motive. To clarify, the team needs to

• Work as a team
• Enjoy their roles
• Should be supportive
• Should feel good and focused on delivering a quality product

Practices:

Extreme Programming has the following practices areas -

• Fine-scale feedback
• Continuous process
• Shared understanding
• Programmer’s welfare

The 12 practices of Extreme Programming achieve the Extreme Programming purpose. The weakness of any one of the methods is made up by the strength of other practices.

There were 24 practices of XP, which were later drilled down by Kent Beck to primary 12 practices:

1. The Planning game (user stories)
2. Small releases
3. Metaphor
4. Simple design
5. Testing
6. Refactoring
7. Pair programming
8. Collective ownership
9. Continuous Integration
10. 40-Hours workweek
11. On-site customer
12. Coding

The four areas into which the practices of Extreme Programming fall are:

1. Fine-scale Feedback −

• Testing:

  • What it is - This includes all types of testing

    • Unit testing

    • First design testing

    • Various kinds of Automated testing

    • Advantages:

  • Firstly, Unit testing is the final testing before user testing. It indicates that no further design or coding is required.

    • Secondly, refactoring of the code happens using the results of Unit testing. It will reduce the work as the code gets re-used again.
    • Thirdly, the unit testing indicates that the design is clear, and no further modifications are required. Therefore, the developer gets to know his goals as per the design and knows what he has to develop.
    • Moreover, automation gives a series of regression tests that confirm that the tested feature/function is working fine, and there is no adverse effect of it.

• On-site customer

  • What is it?

  • One who has in-depth knowledge of the project.

  • Plays significant roles during the “Steer phase (the phase where all the changes are done, discussed in detail later in this article)” of the project.

  • It provides fast, on point, and continuous feedback to the development team.

  • Advantages:

    • Firstly, all questions get answered then and there; without any need for email or approvals.

    • Secondly, the customers can ensure the product is shaping up as per their requirements.

    • Moreover, they can re-prioritize requirements.

• Pair Programming

  • What is it?
    • Two developers share one workstation.
    • They use their brains to figure out how to do the coding and how others will code.
    • Consequently, they can switch roles, as and when needed.
  • Advantages:

    • Firstly, two brains always think better than one.

    • Secondly, they work with better concentration.

    • Moreover, two people can brainstorm and answer below questions in a better way

      • Is there a way to perform the task more simply?

      • Is this coding as a whole going to work?

      • What are the test cases that may not work, and why?

2. Continuous Process −

• Continuous Integration

  • What is it?

    • Adding new features or changes into the system with no delay.

    • Moreover, the application of small integrations (additional features) to the functionalities happens.

    • To clarify, one developer will be taking a copy of the current base code and will work on that to make a code for some different features. Similarly, another developer will be working with the same code base to do coding for another function. That is how the code gets improvised (integrated) if it gets used for more than one day.

  • Advantages:

    • Firstly, it makes the process less lengthy.

    • In addition to this, it enables small project releases.

• Refactoring

  • What is it?
    • Process of changing the software system to improve its internal structure without altering the external behavior of code.
    • Re-use old code (after Unit testing) for coding some other functionality.
  • Advantages:
    • Firstly, it helps the developer in improving the product.
    • Secondly, it allows brainstorming for finding different ways, and therefore,  promotes team building.
    • In addition to that, it increases the programmer’s knowledge about the system.

• Short Releases

  • What is it?
    • Functionalities delivered in small portions.
    • Lesser the features, quicker the release.
    • Support “Planning game”.
  • Advantages:
    • Firstly, it promotes faster and frequent release.
    • Secondly, it's easy to track progress.
    • Thirdly, it reduces the chances of big mistakes.
    • In addition to the above, it reduces rework.

3. Shared Understanding −

• The Planning Game

  • What is it?
    • Learn User Stories for planning.
    • Plan what will get delivered in the next iteration.
    • A Technical and knowledgeable person will estimate the cost and time.
    • The Planning game shows the bonding between the developer and the customer.
  • Advantages:
    • Firstly, it prevents time wastage on developing unnecessary features.
    • Secondly, it's a planned approach, so no guesswork.
    • In addition to that, everyone is aware of the progress.

• Simple Design

  • What is it?
    • Keeping the design as simple as we can.
    • In addition to the above, doing as little as sufficient to deliver value to the system.
  • Advantages:
    • Firstly it's time-saving because no additional features get worked upon.
    • Secondly, it's easy to understand.
    • Finally, it's about collective ownership and therefore, the refactoring will be easy.

• Metaphor

  • What is it?
    • The verbal architecture of the whole system. In other words, metaphor defines the entire system in its technical terms, and it is understandable by only those who are a part of the system.
    • It uses a standard set of conditions.
    • Metaphors are commanding teaching tools. That is to say; they get used in a vast number of areas. Moreover, a metaphor aims to create a bridge of understanding between two or more parties.
  • Advantages:
    • Firstly, it inspires common terminologies.
    • Secondly, it reduces the use of technical jargon.
    • In addition to that, it is a fast and straightforward fix to understand the system.

• Collective Ownership
  • What is it?
    • Talks about making developers accountable for what they are doing.
    • In other words, all developers in the team own all of the code.
    • Refactoring happens.
  • Advantages:
    • Firstly, there is no fear of anyone leaving the team as everyone in the team knows the code thoroughly.
    • Moreover, it makes each developer responsible for every code in the system.
    • In addition to that, it makes the developer responsible for the system as a whole, and therefore, not being just a part of the system.

• Coding Standards
  • What is it?
    • All code should follow the same standards of coding, which is a mutual decision of the Lead Developer and the client at the time of planning.
    • Moreover, only the leader should know who has designed which code so that the team works as a team and not as individuals.
  • Advantages:
    • Firstly, it keeps everyone on the same page as everyone will be following the same predefined coding standards.
    • Secondly, it will be easy to find loopholes (if any) as anything that is not meeting standard coding rules will not fit.
  • Moreover, it decreases the time the developer will take to do coding, as he knows the set of rules that are to follow.
  • Finally, the coding will be clear and unmistakable.

4. Developer/Programmer Welfare −

• 40-Hour Week
  • What is it?
    • Limitation of Working hours to 40 hours in a week.
    • No overtime promoted because it’s a symptom of a problem.
    • Moreover, working more than 40 hours a week will not be suitable for the long term.
  • Advantages:
    • Firstly, fewer working hours keep the developer active.
    • At the same time, they work more efficiently.
    • In addition to that, it keeps the developer stress-free and healthy .

The above figure shows the application of the practices in Extreme programming. It shows

• How using normal terminologies and the underlying system structure (metaphor), the on-site customer creates the stories.
• How these stories are passed to developers, and furthermore, the developer creates a Planning game based on the user stories and finally, starts the development of all the functionalities in small iterations.
• Features start getting a release in small iterations.
• The dark green color represents all the processes that each iteration goes through. That is to say, Each functionality, in every iteration, goes through the Acceptance test.
• Continuous Integration uses the data from Acceptance tests. Along with that, the metaphor also uses these results for requirement clarification.
• Continuous Integration and coding standards emphasize collective ownership. In other words, if anyone is absent or is not available, the work shouldn’t stop.
• Because of precise requirements and easy language in metaphor, the design is simple.
• The same design can be refactored for any other function too.
• Unit testing is performed after design completion.
• Unit test results get used for Continuous Integration. Moreover, if any bugs are there, then pair programming can be done to sort it out.
• The solution from pair programming can be documented for future reference in order to make the designing simple.
• In addition to that, the results get used in defining the coding standard too, so that the same issue, in the same situation doesn’t occur again.
• Coding standard and metaphor collectively tell us about the standards and organization structure based on the previous practices and results. And according to that in the software industry, one should not work more than 40 hours a week to work efficiently.
• Collective ownership

XP Artifacts

Two major artifacts in XP are-

• Story Cards
• Task Cards

Other important Extreme Programming artifacts are as follows −

• Acceptance tests
• Estimates
  • Release plan
  • Iteration plan
• Design
• Unit test cases
• Communication records

Story Cards

A User Story is nothing but the document that describes the user’s requirement. The structures of User Story cards have the following features-

• Customer designs or writes a user card.
• It describes the system from the customer’s point of view.
• A user card is simple and not much technical language. In other words, the customer uses his terms to explain the requirement.
• A user card should be detailed enough so that the developer can estimate how long it will take for a particular story to get designed, tested, and implemented.
• One feature description requires one user card in the system. In other words, one user card for each requirement.
• The estimates for the feature delivery are done using the user story cards.

Task Cards

A Task Card is created by the Development team to implement the task in an organized manner. It will have the following task details against a particular user story-

• The list of tasks required for the implementation of a User Story is called a Task Card.
• Moreover, only one task card gets designed and issued against one user story.
• In addition to that, the Task cards work as the base for task assignments and providing an estimate to complete a task.

Acceptance Tests:

Performance of acceptance tests happens to ensure that all the User stories are appropriately understood and implemented. The team of testers does these tests.

Estimates:

There are two phases, where task evaluation, time estimation, and effort estimation happens.

Below are the Two Phases of Estimation and their planning-

• Release Planning– In this phase, the decision of each feature(iteration) of the "Release plan" takes place along with the estimation of delivery duration and number of people/efforts required. Following are the reasons for this estimation:-
  • First, to find out the complete project target release date, executed in the exploration phase.
  • Second, to figure out if any time or workforce adjustments get planned in the steering phase.
• Release Plan -  Release plan is the documented plan which will have the details of −
  • The user stories that have been selected by the development team for release.
  • Estimates of the time required and the efforts needed.
  • The date that has been committed as the release date.
• Estimates – Iteration Planning – In the same vein as Release planning, here in this phase, the evaluation of the estimates of the tasks related to effort and duration happens. Moreover, this evaluation gets used for assigning the tasks in iteration planning and balancing a load of work per resource in the commitment phase.
• Iteration Plan - The project gets divided into small iterations, and each iteration will have the iteration plans. Iteration plan has the following details:
  • The user stories selected for that particular iteration.
  • Assigned tasks and the details of the person to whom it is assigned.
  • An Estimate, by when the task gets completed.

Design:

The developer develops the design by referring to the user story. The developer requires this design for the implementation of the user story.

Unit Test Cases

After designing, the developer does the coding, followed by unit testing.

For unit testing –the Unit test case is prepared by the developer to make sure that the particular feature (unit) is working as expected. The unit test is a developer written test for any specific functionality. Moreover, the Unit test case leads to coding and unit testing for any task. To sum up, it is the very first step in the level of testing and done before Integration testing.

Customer and Developer Communication Records:

All the activities are basis the Stories.

• The User Story is the communication from the user to a developer.
• Task card is the communication within the team.

So, both stories are documented based on the communication between customers and developers or within the team.

Since XP doesn’t support unnecessary documentation, thereby-

• If not needed - the communication can be verbal.
• If needed - the documentation can happen subsequently.

What are the different activities of Extreme Programming?

There are four primary activities of Extreme programming. They are:

• Coding
• Testing
• Listening
• *Designing

Coding:

Before coding, it is all about collecting the requirements and designing as per requirement. However, once the design and testing happen, coding starts.

A team of developers or programmers will do coding.

Testing:

Testing is of two types, namely, Manual and Automated. Here in this method, manual testing gets done.

The team of testers performs manual testing, and subsequently, test results will be published.

• If the test results are positive, we can go ahead with the release process.
• However, if not, then the tester needs to raise defect, get it sorted and then again test it.

Listening:

How would the developer know what is to be coded by him and tested by the tester? Listening enables you to understand your job.

Tester and developers are a critical part of the system. Therefore, both have to be an active listener to understand the current progress and the next steps.

Designing:

To keep all the three activities on one-page designing happens. In other words, it brings all three activities under one umbrella.

Phases of Programming:

The performance of All the above activities happens in different phases of development. These different phases of programming are −

• Release Planning
• Iteration Planning
• Implementation

Release Planning:

In this phase, we plan for the next release. The user stories and the subsequent release date design this. Release planning will be done by the customer and developers mutually in three phases.

• Exploration Phase
• Commitment Phase
• Steering Phase

Release Planning – Exploration Phase:

Firstly, the Exploration phase is the phase of gathering requirement and finding out the impact of that requirement on the project and thereupon framing them to a user story. Following are the steps for that:

• Create a story:

Customers face some issues and approach the developer with a problem and explain their question to the developer*.

• Thereafter, the customer and the developer both discuss the problem and understand the technical aspects of it.
• Additionally, the developer must help customers understand the technical terms and should not influence the customer requirements.
• Finally, customers document the problem and provide a formally documented story card for their question.
• The User story card has to be documented by the customer only, and thereafter, the developer gets it.
• To sum up, in the user story card, customers will call out their exact requirements and terms.
• Estimate a story: The developers will do this part. They will estimate how long it will take to implement the work mentioned in the User story card. Moreover, they can analyze and prepare a layout to solve the problem so that everyone gets a clear idea about the problem and its solution. This solution should not have any influence on the business requirement or "User story card".
• Divide a story: Before moving to the next phase, which is “Iteration Planning”, we need to design critical complexities first. If the developer is not able to estimate the user story, then the customer has to split it further and write/explain again.

Roles used in this phase: Customer and Developer

Artifacts used: User story card

Important: Active Listening is crucial in this phase so as to:

• Get the customer’s requirement properly
• Understand the User Story card
• Explain a story card to the development team
• Gain clarity
• Avoid uncertainty
• Express yourself clearly in the case of understanding breaks.

Release Planning – Commitment Phase:

The second phase is known as the commitment phase because this phase involves the resolution of:

• Desired Functionalities
• Estimated cost
• Impact on business
• Profit and
• Release date

The customer and developer will sort it out based on four components:

• Sort by value: The customer will be sorting out the user stories as per business values by the customer.
• By speed: The developers try to find out at what speed can they perform and deliver the project.
• Sort by risk: The developer will be sorting out the stories based on risk.
• Choosing scope: Finally, User stories with a release date will be picked up first to ensure they get delivered in time. In other words, the user stories which finish first in the next release will get picked up early.

Roles used in this phase: Customer and Developer

Artifacts used: User story card

Important: Active listening is essential here as well because of the following reasons−

• First, the developer has to have a clear understanding of the functionality required in the current release.
• Moreover, it's essential to estimate the efforts and duration needed for the delivery of this functionality.
• In addition to that, the customer and the developer both will be able to understand and decide whether it is possible to meet the committed release date committed or not.

Release Planning – Steering Phase:

Finally, the Steering phase comes, which is also known as a phase of change. The requirements of any new changes happen in this phase.  In other words, everything happens in this phase, like adding a new feature, removing or changing an existing feature, etc.

In Steering phase, the customer can ask the developer to "steer" the process −

• Like, bring changes in the user stories.
• To prioritize the stories of different users (changing the priority).
• Adjust the release plan in case of incorrectly established estimates.
• To accommodate the user suggested changes.

Roles used in this phase: Customer and Developer

Artifacts used: User story card

Important: Like every phase, Active listening is essential in this phase too. It's important to:

• Understand the addition of the new requirements.
• Comprehend changes required for the current needs.
• Analyze what needs to get removed and the subsequent impact of removal on the existing system.
• To know the work done so far.

Iteration Planning:

In this phase, there is no customer involvement. That is to say; the developers will be planning the activities and tasks for iteration.

Iteration Planning has three phases −

• Exploration phase.
• Commitment phase.
• Steering phase.

Iteration Planning – Exploration Phase:

In the Exploration phase,

• Various tasks get the interpretation of the requirements.
• The task card records all the tasks.
• In addition to the above, the developer will give an estimate of the implementation time of the task.
• Finally, too small or too big jobs are combined/split to get an estimate.

Roles: Developers

Artifacts: Task card

Iteration Planning - Commitment Phase:

In the Commitment phase,

• The developer gets the tasks.
• The developer acknowledges the accountability of the assigned task.
• Moreover, the developer gives an estimate of the time required for the completion of the task.
• Finally, the estimated time and the work comparison occurs once the entire load (work) distribution happens among programmers.

Roles:  Developers

Artifacts: Task card

Iteration Planning – Steering Phase:

In the Steering phase,

• The developer understands the task card for the task performed.
• The developer’s team executes the task by using the techniques of Pair programming.

Roles:  Developers

Artifact: Task Card

Implementation:

The implementation happens during the steering phase of iteration. The activities that come under this are-

• Design the task: Developer starts working on the job written on the task card and thereafter, starts designing as per card.
• Write a unit test: The programmer first writes an automated test known as unit testing, before actual coding.
• Write the code: The programmer starts coding.
• Run test:  The Unit Tests are run for code checking.
• Refactoring: This means reusing the code with some minor changes.
• Run functional tests: Integrated testing and user acceptance testing comes under this.

Role: Developers

Extreme Roles and Responsibilities:

In Extreme programming, three roles are very critical and vital. Likewise, there are other roles, too, but they work under them. These major roles are-

Customer:

The customer is the one who decides and conveys the entire requirement. In Extreme programming, the customer has to be in continuous touch with developers. Additionally, the customer can be

• A specific community
• A group of stakeholders
  • A team with the member that includes
  • Product managers
  • Sales and marketing members
  • End users and managers
  • Business Analyst
  • Operations

Customer will be responsible for the following-

• Writing user stories
• Testing final functions delivered by developers and write a functional test
• Setting priorities
• Explaining stories to the developer
• Deciding if it fits the end-user requirement
• Deciding questions about the stories

Programmer:

Developer or programmer should be an effective communicator because he is the only channel of communication between the development team, testing team, and customer. A developer will be the one with the rights to do the following-

• Gather Requirement Knowledge
• Produce quality work
• Approach management for help, which includes both his hieratical supervisors and the customer
• Develop and alter the provided estimates
• Be accountable

Major responsibilities of a programmer are

• First, to understand and estimate user stories.
• Second, to define and estimate tasks based on the user story.
• Third, to write a unit test.
• Additionally, to write code to pass the unit test.
• Thereafter, to perform the unit test.
• Refactor
• Finally, to Integrate and try to improve continuously.

Coach:

The role of a Coach is significant in Extreme programming. A coach ensures that everyone is working towards making programming to extreme programming. Coach should have

• Subtle behavior to be a coach, even if everyone else is panicking
• Excellent knowledge of Extreme programming
• Helpful nature because he has to observe everyone and consequently assist.

Responsibilities of a Coach include-

• Watching all the activities and making sure that the entire project remains on track.
• He will be helping the team with anything related to the project.
• Responsible for figuring out the extreme programming practices that help resolve any issues in the project.
• In addition to the above, he ensures that the team is self-sufficient.
• He will be observing all the teams silently.
• If any problem arises, he can involve or make any team meant to help.

Some other roles are:

Tester:

The tester will be the one who will be doing testing after coding. Responsibilities of a tester include -

• Implementing all functional tests (except Unit test)
• Graphing all the results
• Informing both customer and developer when the test results are not possible

Tracker:

The tracker will be the person who will ensure that everyone is doing their work correctly, including the developer. Responsibilities of a Tracker include -

• Arranging developer’s meetings with customers as and when needed.
• Monitoring developer’s progress.
• Additionally, setting up a team meeting and taking action if things are not going as committed.
• Reach out to the coach or the programmer for help (if needed).

Doomsayer:

As the name suggests, doomsayer will be the one who will be keeping an eye on any disaster. These disasters can be like not meeting timelines, a bug due to some small mistake, infrastructural issues, or something that can impact the project in any manner. In other words, doomsayer will try that nothing goes wrong. Doomsayer’s responsibilities include:

• To predict the risk if any
• To ensure that everyone involved in the projects knows the risk involved
• Maintaining transparency of any evil news
• Ensure that everyone is aware of the impact, urgency, and factors/activities which will get affected.

Manager:

The Manager is the one who will be passing the reports and trackers for process progress. He will be answerable to the Gold owner in case of any issues (The Gold owner is someone who will be funding the project from the customer’s side). Responsibilities of a manager are as follows-

• Firstly, to ensure that the Development team, as well as the customer, know the Planning Game explanation adequately.
• Secondly, to observe Planning Game and modify rules, as and when required.
• Thirdly, to ensure the identification & tracking of the defects.
• Moreover, to ascertain the tracking of the resolution time and the time taken by each team on the defect.
• In addition to that, obtain all the information without disturbing the team’s current work.
• Finally, to attend client meetings and keep track of all the useful information discussed in the meeting.

Phases of eXtreme Programming:

This figure tells us about the flow of Extreme programming, in extreme programming first-

• At first, User requirements are collected on the user story card.
• Thereafter, the user story card does Iteration planning. Time and effort estimations happen in Iteration planning.
• The iteration wise development process starts after planning.
• Further, the incorporation of any new requirements happens during development.
• In addition to that, any changes required during iteration Testing are included at this stage only. Moreover, the addition of New user requirements also happens at this stage only.
• After successful iteration testing, it will go for UAT (User Acceptance Test).
• Thereafter, if Defects will raise, in case of bugs; it will go back in the development phase.
• Finally, if there are no bugs - Final release, User Training finishes, and Product Support provided.

It was an Extreme programming flow. This brings us to the question of how many phases are there in extreme programming workflow? There are 6 phases in the process flow of Extreme Programming.

These 6 phases are as follows:

Planning:

• Identifying of investors
• Recognizing infrastructure needs
• Establishing security needs
• Signing Service level agreement ( i. e. a formal document which talks about the provision of various services) with all the constraints.

Analysis

• Getting user stories from the customer
• Analyzing user stories
• Prioritizing stories
• Scrubbing stories for estimations
• Defining iteration, for instance, which iteration delivers what all functionalities.
• Planning for testing and Development teams

Design:

• Design for the first iteration
• Preparing a test case for each task
• Regression Automation Framework

Execution

• The developer will do coding.
• After coding finishes, QA performs Unit Testing.
• Thereafter, Manual testing happens.
• Defect Report generates (if defects raise).
• Conversion of the Manual to Automation regression test cases happens.
• Mid-iteration review
• End of iteration review

Wrapping:

• Iteration release happens
• Regression Testing occurs
• The customer gets the demos and reviews it
• Thereafter, if needed, the customer develops a new story after testing.
• Finally, after the iteration review, improvement plans will be prepared based on the feedback.

Closure:

• Training to the end-user given
• Production Launch happens
• Additionally, the performance of various checks happens if the developer met the SLA.
• Finally, Production Support gets provided for the developed product.

Now that we have understood Extreme programming, let’s analyze the key differences between Extreme programming and Scrum.

Differences between Extreme Programming and Scrum

Extreme Programming	Scrum
One sprint gets completed in 2-10 days	One sprint takes two weeks to 6 weeks to complete
Extreme programming allows changes in the sprint at any stage of development	On the other hand, in Scrum, once the sprint planning meeting finishes and the delivery happens, no changes can happen in the sprint.
Developers start working as per the priority is given by the users.	Developers decide the priority and thereafter, start developing.
XP has practices like TDD, Pair Programming, refactoring, etc., which are mandatory to follow	Does not recommend any engineering Practices

Why Extreme may fail-

• In Extreme programming, code gets importance over design. However, it is the design that sells the application and not the code. When the programmers focus on code and design differs even a little then the end product may leave the customer dissatisfied. Therefore, to avoid this, developers need to concentrate on design as well as code.
• Extreme programming accepts change at any stage. On the other hand, these changes don't get appropriately documented. For instance, if there are any failures in implementation, then finding its reason will be extremely difficult because of the lack of documentation. Therefore, it is imperative to have proper documentation for every change in order to avoid errors.
• Additionally, Extreme programming limits the range of projects because it requires face-to-face interaction with XP projects. This is further challenging to implement if the customer sits away from the development site.

Conclusion

To conclude, Extreme programming is an agile software development framework. It improves software quality and responsiveness to the ever-changing requirements of the customer. Additionally, it favors frequent "releases" to improve productivity.