Extreme Programming, the underrated Agile Framework
Juan Andrés Ochoa
Juan Andrés Ochoa
Fundador y CEO de Castor Evolución digital. Autor, podcaster, speaker, músico, navegante y filósofo novato.
XP el subvalorado Framework ágil, XP the underrated Agile Framework

Today Scrum is the king of agile Frameworks while XP is underrated

The 14th agility status report says that 58% of the people that filled the survey use Scrum and only 1% use Extreme Programming –or XP. But XP also contributes to the creation of software. Let’s see:

Main advantages of XP:

  • XP focuses on the timely delivery of final products.        
  • XP Programming teams save a lot of money because they don’t use much documentation. They usually solve problems through discussions within the team.      
  • Simplicity is one more advantage of XP projects. Developers who prefer to use this methodology create straightforward code that can improve at any time.      
  • The whole process in XP is visible and accountable. Developers compromise what they are going to achieve and show progress.      
  • Constant feedback is also the strong side. You need to listen and make the necessary changes in time.

XP the underrated Agile Framework

Not that the advantages of XP are disadvantages of Scrum. Rather, Scrum and XP are aligned and complement each other.

If you are in a team that works with Scrum, you may find it difficult to differentiate between Scrum and XP, and probably, as was the case with me, you attribute the methods and tools entirely to Scrum. And it is not like that.

Scrum emphasizes mindset, methods, and tools for team self-management and thus generates value and well-being. On the other hand, XP emphasizes technical and practical elements for incremental software creation with technical excellence.

Some rules[1] that raise XP[2] are:

Scope Rules
  • Create User stories
  • Create and execute Release plans
  • Work with small and frequent releases
  • The whole team works together in an open space.
  • Measure the speed of the project
  • Fix the method when it “breaks.”
  • Simplicity, simplicity, simplicity
  • Use Metaphors to name system components
  • Create Spikes (small programs to validate hypotheses)
  • No functionality is added before needed
  • Refactor and refactor whenever possible.
  • The client is with the programmer
  • The client is available
  • Always code with standards, Test Driven Development, pair programming, continuous integration
  • Everything must have unit tests.
  • All code must pass unit tests before being deployed.
  • When people find errors, create tests.

Extreme Programming and Scrum, which is better?

I see no reason to choose between using one or the other definitely. If a Scrum team knows and practices the XP rules, it can offer more value to customers and more well-being to its team members.

Do you dare to explore Extreme Programming with us? Please write to us!

Reference sources:





[1] I wouldn’t say I like the word “Rules,” but that’s how they put it on the XP documentation

[2] For a more in-depth approach, you can see: http://www.extremeprogramming.org/

The cover image was taken from: Technology vector created by freepik – www.freepik.com

We invite you to follow us on our social networks: LinkedIn, Twitter y Facebook.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *