The Rules of Extreme Programming

Scrum is considered one of the most popular Agile methods (or frameworks) in the world and Kanban may be the second.  However, there are a few projects that follows Extreme Programming because of that I would like to remember about the rules of it.

The following rules are explained in the website of extremming programming :

extreme programming 1






Indeed, this website is plenty of helpful and very interesting knowledge about this controversial approach.


User stories are written.
Release planning creates the release schedule.
Make frequent small releases.
The project is divided into iterations.
Iteration planning starts each iteration.

About Planning you can find that most Scrum teams write user stories, the project is divided into iterations (most of them last two weeks) but a few of them make frequent small releases which is an excellent practice.


Give the team a dedicated open work space.
Set a sustainable pace.
A stand up meeting starts each day.
The Project Velocity is measured.
Move people around.
Fix XP when it breaks.

I considered the first item as one of the most important, company has to provide an open work space so everybody can be in touch easily. Unfortunately, many companies prefer to keep the old structure of offices which use cubicles so everybody is separated and it gets worse when the Product Owner (most of the time former managers) have their own office.


The customer is always available.
Code must be written to agreed standards.
Code the unit test first.
All production code is pair programmed.
Only one pair integrates code at a time.
Integrate often.
Set up a dedicated integration computer.
Use collective ownership.

About coding rules, there is one which is very hard to implement: pair programming. However, it is very helpful when you have juniors developers on your team or if you need to transfer knowledge (you hired new developers). Other topic to take into account is code the unit test first (or the famous Testing Driven Development) which is a very effective way to improve the quality of source code.


Choose a system metaphor.
Use CRC cards for design sessions.
Create spike solutions to reduce risk.
No functionality is added early.
Refactor whenever and wherever possible.

Regarding the rules to design refactoring is the top item here and it is very important when your software is too old and you have to invest a lot of time fixing bugs.


All code must have unit tests.
All code must pass all unit tests before it  can
be released.
When a bug is found tests are created.
Acceptance tests are run often and the score
is published.

Testing is a key concept because if you want to make release very often you have to be sure not to damage your existing source code.

To conclude, extreme programming is a great Agile approach but your team has to start with Kanban that is easier to implement and adopt it.

Mario Lucero

Mario Lucero

I am all about helping companies to adopt agile as methodology in Chile. Why? I believe many organizations think that agile is not for Chilean companies because of Chilean culture is totally different from i.e. USA culture but I worked with Chilean professionals who after using agile realized it is feasible to implement it. Agile works in small and large projects and there are many evidences which demonstrate this.

Leave a Reply

CommentLuv badge