Extreme Programming to go for another level

Felipe Emídio
6 min readJan 28, 2023


The Extreme Go Horse bulletproof guide

Agile methodology has significantly increased its presence in companies led by the IT sector.

The main reason is its capacity to deal with changes in the middle of a project.

If you know something about agile methodology then you have heard of Scrum, the primary method chosen by the market. Maybe you even consider Scrum and agile methodology as synonyms.

Let me introduce you to another great one that you should be aware of. The Extreme Programming method.


Source: Wikipedia

Extreme programming or XP for the closest is a bunch of good practices that you should apply in your company.

Pretty close to what is The Extreme Go Horse (XGH) guide, but the XP put you in the opposite direction. And as its name suggests this methodology focuses on software development teams.

It was created by Kent Beck, who is one of the 17 original signatories of the Agile Manifesto.

The 5 Principles

Five principles of XP


The XP is recommended for teams between 2 to 10 members. Teamwork is important and is required.

Low centralization of information. Questions and problems are solved more quickly when spread. Encouraging interaction between people is a good thing and leads to productivity.


  • Watch out for overengineering
  • Focus on the problem
  • Work on them in baby steps.
  • Do just what is asked for

Aren’t these some common advice that we hear when we are juniors? =)


This kind emphasizes the communication principle. Hear the most, work much and talk little.


Say “no” to changes are as important as saying “yes”. Pointing problems, changing the project's direction, disagreeing when necessary… hard things, but necessary.


This is the basic, without it we even couldn’t be called professionals.

The Practices

Extreme Programmers implement most of these practices. Note that some of them can’t be directly applied to remote jobs.

Implementing all of them is not required.

Developing proccess steps
Source: powerslides.com

The practices can be divided by the steps of the delivery process.

  • Panning
  • Managing
  • Designing
  • Coding
  • Testing


This is our guy Kent Beck | Source: javadesde0.com

User Stories

User Stories are detailed content about a given task. All user stories should be written e published on a common field where everyone can see them.


Like most agile methodologies, work on an iteration model, these iteration also can be called sprints. Small iteration for 1 to 3 weeks between each delivery.

Planning Iterations

At the beginning of each sprint, the team needs to make the “planning game” which is brainstorming with the client that results in the user stories.

After that, the team estimates the cost and time to implement each feature.

Finally, the client prioritizes the tasks. With all that we create or update the project’s backlog.

Release schedule

Plan how the releases gonna work, when they will be publicized, and which feature has in each release.

Small Releases

Releases are better managed when small. That leads to quickly found errors and accurate feedback.


Stand-up meeting | Source: hugo.team/blog

Open workspace

Create an environment that encourages communication, and lets the work office be comfortable and without barriers between the desks. Give the team a whiteboard to express themselves.

Stand-up Meeting

Keep communicating but make it quick. In a meeting let everyone stand up so they will want it to end fast. About 10 to 15 minutes is ideal.

Sustainable Pace

There’s nothing like “let’s speed up the project now…”. From the beginning, create a sustainable routine for the team.

Something like 8 hours of work per day is great. Programming and communicating are hard tasks, we need rest to keep focused.

Project velocity

Keep the track of the project’s velocity. It can be measured by the number of tasks delivered.

Sometimes the team will ask for more tasks because they will end up the iteration tasks faster than expected, and sometimes tasks will be not done in time.

Move people around

Changing the acting areas of each member avoids the centralization of knowledge and improves communication.

Fix XP

Do not hesitate to change things when they do not work well. Have retrospective meetings to find what is not working.


CRC model | Source: agilemodeling.com

Use CRC Cards

Class-responsibility-collaboration (CRC) cards tools to design software that helps people to have more object-oriented thinking.

Simple Design

Simplicity principle. Always start with the most simple version each system features.


The client can have no technical knowledge, so be prepared, and use metaphors if necessary.

Have empathy! “Fast” and “safe” can have different meanings for a lawyer and a programmer.

Spike solutions

A spike solution, or spike, are quick sets of experimental tests to find the cause of a giving problem.

No extra features

Focus on what the project needs, It’s tempting to improve a feature that you like, but most of the time it will not be used. So focus on following the planning.


Pair programming illustration | Source: tuple.app

Customer Always Available

Customers are an important resource of information. Let them know that they will create the product with us. Questions and feedbacks are quite usual.

Pair Programming

The team is divided into pairs, usually someone with more experience and a newbie. Each pair will work on a user story.

This practice encourages communication, decentralization of information, and the leveling of technical knowledge.

Coding Standards

The code needs rules! Create an environment where each dev member can easily understand the friend’s code.

Integrate Often

As soon as a new feature is ready, submit a merge with the base code. Keep everything updated! This can avoid unnecessary code conflicts.

Integrate one code per time

New tasks can contain conflict code with each other, because of this just one team deliver the task at a time, and the next team must guarantee a working code with the last merge.

Dedicated integration computer

Just one computer to deploy the release. It works as a flag to everyone know that a release is been published and who is releasing it.

Collective Ownership

Everyone has editing access to the code. This practice is to make everyone aware of the code’s state. But do not forget to review the changes submitted.


Always that is possible, try to improve the code quality. Continuous improvement of the system. Nothing is so good that can’t be better. Easier to say than make. Changing a working feature requires courage and professionalism!


TDD flow | Source: dev.to

Acceptance Tests

Create tests that guarantee each delivered feature. The client is fundamental to designing these tests. This will help us to keep the software’s quality assurance.

Test Driven Development (TDD)

Work driven by the tests. This means creating the tests before the feature implementation. This will help us to think before acting.

Unit tests

All code must have unit tests for it. Code without tests should not be released.

Tests for bugs

Where you find a bug, a test is created. This will assure that it won’t come back.


Extreme Programming is a cluster of practices that a software development team should consider adopting.

It’s not exclusive to other agile methodologies. For instance, can be integrated with Scrum and Kanban.

Some of the practices like TDD and Pair Programming are hard to use and it's recommended to have an extreme programmer by your side when implementing them.

Are you interested in agile methodologies? Check out my article about the 5 most common mistakes for agile teams.

If you want to read more of my thoughts and programming tips, then check out my articles and follow me for upcoming content.



Felipe Emídio

Front-end developer searching for a better version of my code.