Delving into Extreme Programming: An In-depth Review of ‘Extreme Programming Explained’ (2nd Edition)

17 min readFeb 18, 2024

Extreme programming (XP) is a methodology focused on the technical and social aspects of software development. It focuses on two main pillars: response to change and technical excellence.

Technical excellence is the structure that allows teams to be agile. On the other hand SCRUM is the methodology that got traction and is the most adopted by the industry as a means to “be agile”. Therefore, as already explored by Martin Fowler SCRUM has a place in the party, but is not the main course.

Kent Beck popularized different technical practices on writing XP and this post aims to go over the book and his contribution with the industry about software development. XP is the glue between the practices SCRUM and the technical side, XP fills in the gaps that SCRUM left behind. Alongside of this post, there is a mind map as well, that can be explored here.

The following canvas is an updated version of what was developed with mindomo:

Mindmap built with Obsidian with the book content. Elaborated by the author.

Chapter 1

First chapter starts defining in a nutshell what eXtreme Programming through values and practices, in the first section, this is what defined XP:

A philosophy of software development
A body of practices proven to improve the software development
Techniques to translate values into practice
A community that shares many values and the same practices

Exploring eXtreme programming

Chapter 2

In this second edition Kent Beck starts with an analogy of learning to drive and the change that occurs in software development.

At first it seems that there is no relationship between driving and coding until the moment comes and oneself realises that both are related to adapting to change — Beck describes that as: Stay aware. Adapt. Change.

Customers are the ones that drive the system content — as the customer don’t know how to deal with software development she is the one in charge of pointing the right direction.

As the dynamic improves and the team starts work together and elabora on their practices, each practice is an experiment to improve: effectiveness, communication, confidence, and productivity.

Values are a key point to a extreme programming team.

Practices are clear. Everyone knows if I’ve attended the morning standup meetings. Whether I really value communication is fuzzy.

It is possible to relate the quote above with the daily stand-up meeting that any scrum team does, therefore, the argument of values is the one that sticks. The values are what we do and the values is what are what we do without prescription.

VALUES ---------|------------|--------- PRACTICES
                |            |
                | PRINCIPLES |

Bridging the gap between values and practices are principles.

Chapter 3

Practices are the things you do day-to-day, specifying practices is useful because they are clear and objective.

Even with the best practices in place it does not mean that one can be the best one in class, practices alone lack a key part in the process. Kent does this analogy with a gardener.

The values are the glue that one can develop between the practice and the objective of becoming a profesional. Values are the large-scale criteria we use to judge what we see, think and do. In other words, reading XP won’t make anyone a better programmer.

Chapter 4

This chapter is all about the values that a XP team embraces, let’s go over the key areas that Kent shared along some personal notes on the matter:

Communication is what matter the most for a software development team
Simplicity is hard work. This is not to think simple, rather, it is focused on eliminating wasted complexity
— Simplicity is dependent on the context
— This value becomes even clearer in the practice of Test Driven Development which deescalate the complexity one might start to implement software
— Improving communication helps achieve simplicity.
— Simplicity also comes from experience as the career progresses experienced developers tend to find simpler solutions over complicated ones.
Feedback is eminente in an environment that changes.
— We might not know how to do it right.
— What is right for today might be wrong for tomorrow.
— Being satisfied with improvement rather than expecting perfection.
— XP teams generate as much feedback as quick as possible — watch out for too much feedback.
Courage is effective action in the face of fear, courage can manifest itself sometimes with action and sometimes with patience
Respect is the act of caring about others.
— Software development has a equal value as a human being.
— The contribution of each person on the team need to be respected.

Chapter 5

Humanity

Software development doesn’t meet human needs
What people need to be a good developer?
— Basic safety and freedom
— Accomplishment
— Belonging
— Growth
— The ability to understand and be understood
XP meets business and personal needs

Economics

Make sure what you are doing, meets business goals and serves business goals.
Software development is more valuable when it earns more money sooner and spends money later.
Do not invest in speculative flexibility.

Mutual benefits

Extensive documentation violates mutual benefits
XP uses the following to give mutual benefits:
— Automated tests that helps to design and implement better today
— Carefully refactor
— Chose names that are coherent and explicitly sets of metaphors
Resolve more problems that create new ones

Self-similarity

When nature finds a shape that works, she uses it everywhere she can. The same apply to software development
Just copying one thing to another context doesn’t mean it will work
Having the system-level tests before you begin implementation simplifies design, reduces stress, and improves feedback

Improvement

There is no perfect process.
Don’t wait for perfection in order to begin. Put improvement to work by not waiting perfection.
Start activity right away and refine the results over time.

Diversity

A team where everyone is alike is not effective
Programmers should work together and value each other opinion
Brings new perspectives, a variety of skills are needed to think about a problem and a solution

Reflection

Good teams take a step back to think about how they are working and why they are working.
Feelings tempered by the intellect are a source of insight.
Learning is action reflected.

Flow

XP practices are biased towards a continuous flow of activities.
Teams have suffered of big bang integration — everything at once instead of continuous flow of delivery.
Resolve the problems that disrupts the flow.

Opportunity

Problems are opportunities for learning.

Redundancy

Defects corrode trust, you cannot solve the defect problem with a single practice.
Having a testing phase after development should be redundant.

Failure

Fail and learn.
Failure is not a waste. Fail instead of talk.

Quality

Sacrificing quality is not effective as means of control. Projects don’t go faster by accepting lower quality.
Time and cost are most often fixed. XP chooses scope as the primary means of planning. Scope is never know precisely.
Do the job the best way you can.

Baby steps

Are expressed in practices like test-first-programming and continuous integration.

Accepted responsibility

Responsibility cannot be assigned only accepted.
The person responsible for the story is responsible for the design, implementation and testing of the story.

Chapter 6

The goal for practices in the XP is to make progress towards an ideal state of effective development. The primary practices are useful independent of what else you are doing. The corollary practices are likely to be difficult without first mastering the primary practices.

Chapter 7

Two kinds of approaches but it might vary based on the context:

People that need planning because they don’t know what needs to be done
People that need quality-related practices because they are creating too many defects

Sit Together

develop in a space big enough for the whole team.
the team was spending time in a cold and drafty room but they were successful.
the problem is always a people problem.
sit together to communicate with all our senses together.
sit together even if it means traveling.

Whole team

we belong.
we support each other’s work, growth and learning.
add and remove people from the team on-demand
150 people more and it is not possible to recognize people to build trust and trust is needed for collaboration

Informative workspace

Make your workspace about your work. An interested observer should be able to walk into the team space and get a general idea of how the project is going in fifteen seconds.

informative charts
private and public space to work is needed.

Energized work

Software development is about insights and insights come to the rested mind.
do not overwork, keep track of when one might not be as productive as it can and stop for the day.

Pair programming

Two people sitting at one machine.
Clarify ideas.
Take initiative if the partner is stuck.
Hold each one accountable for the practices in the team.
Rotate frequently.
Be aware of cultural differences, personal space means different things for different people.
Hygiene and health are important.
Emotions at work should be about work.
If you are not comfortable pairing with someone in the team talk about it.

Other things related to pairing:

Stories

Early estimation is a key difference between stories and other requirements.
short names for stories
This idea of stories was later credited by Jeff Patron and Peter Economy in the book “User story mapping: discover the whole story, build the right product”

Weekly cycles

Plan work a week at a time
— review progress
— discuss priorities and pick the most important ones for the business
— break stories down into tasks
working on weekends is not sustainable.

Quarterly cycles

Focus on:

Identify bottlenecks.
Initiate repairs.
Plan the theme for the quarter.
Focus on the big picture.

Slack

80/20
programmer chosen task
geek week

Ten-Minute build

Keep the build under ten minutes
Automated views without requiring manual intervention

Continuous integration

Integrate things in no more than a couple of hours.
integrate work after a pair session

There is a section dedicated to this Continuous Delivery — Foundation, Configuration Management, Continuous Integration, Implementing a test strategy, build and deployment scripting, and the commit stage.

Test-First programming

Another things related to test first:

Start anything with a failing test.

Another things related to test first:

- TDD: From Katas to Production Code
- My path to Test Driven Development — TDD

Incremental design

invest in the design of the system every day.
Bring improvements gradually and not everything upfront.
XP teams are confident in their ability to adapt the design to future requirements.

Chapter 8

It is interesting how Beck’s starts the chapter 8 talking about getting started with XP practices, he follows the conversation exploring the idea of change. Changing too fas can be risky, on the other hand change is needed to accomplish results.

Looking at what you want to achieve might be a good way to start, as Becks’s says: Look at what you want to achieve. Then, start using one of the practices: “Automate the build”, “Test first all day”. Another scenario that might help is to focus on the task at hand, for example, there is an integration that is coming up and I am feeling nervous regarding the code and design. Pair programming is the practice that addresses technical collaboration.

It is interesting how Beck’s chapter starts about changing and before jumping into the next section he elaborates on the difficulty of change. Anyways, change always starts at home.

“Dictating practices to a team destroys trust and creates resentment”.
“Software development is capable of much, much more than it is currently delivering”.

I do agree with the sentences that Beck shared regarding software development. What I am writing down now is more than twenty years later the release of XP explained and still, software development, is not showing all value it has to offer.

Some of those values are also expressed in the lack of communication between parties as well as the popularity that SCRUM has that put less effort in the values and principles presented by XP trying to give a more formal definition of work for software development teams.

Chapter 9

Be mindful of implementing the changes before doing the preliminary work to address the needs, otherwise you will have a disaster on your hands.

Real customer involvement

Customer should be part of the team.
Proxy customer leads to waste of time.
Customer won’t trust us if he knew how software development is.
Waste time covering up.

Incremental deployment

Beck’s is explicit on big release up front or the D-Day as it is called in the book, his personal experience depicts a disaster on trying to migrate a legacy system of contracts to a new one, failing to reproduce the new behavior, leading to his lost of the bonus he would received for that change.

The big bang release brings difficulties to people and get them too much nervous trying to achieve everything that is needed for the D-Day. If on the D-Day everything works fine the problem is with the people, they will be exhausted to be productive again.

Team continuity

Basically keep people that are doing great together, do not avoid the human aspect of it, but it does not mean static teams.

Developers working on a XP team can join and leave a team and get productive after a month.

Shrinking Teams

Too many people on a team brings also challenges, too few members in different teams calls for merging them.

Root-Cause Analysis

“Every time a defect is found after development, eliminate the defect and its cause.”

Write an automated system-level test that reproduces the defect.
Write a unit test with the smallest possible scope that also reproduces the defect.
Fix the system, so the unit test works. Repeat till it works.
Once the defect is fixed, figure out why the defect was created.

For the last one ask the five whys(This is inspired by Taiichi Ohno on the five whys).

This will lead to potentially the people’s problems lying around as the root cause. Regression testing is an alternative to prevent the problem to come again.

Anyone in the team can improve the code any time.

Until the team has developed a sense of collective responsibility, no one is responsible and quality will deteriorate.

Pair programming help teams to demonstrate their commitment to quality.

Continuous integration is also an important part of collective ownership.

Code and tests

Only the source code and the tests are permanent artificats.

Customers pay for what the system does today and what it will do tomorrow.

The better the team is with incremental design the fewer design decisions it has to make up front.

Single code base

You can develop in a branch but never let it live longer than a few hours.

There are some valid reasons to have different version of the same code base (like other branches), therefore, it can lead to overhad of working having to apply a fix from a branch into another branch and retrofit the work already done.

Instead of creating many verions of the code base, fix first the underlying design problem.

Daily deployment

Everything that is on the programmer’s desk and what is in production is a risk.

Deploy every night.

There are some barriers for deploying frequently, some of them are technical and others are social, for example, the deployment process is so stressful that no one want to deploy.

Chapter 10

eXtreme Programming is not about programming. It is about building software.

The chapter goes over a feel roles on the team, for example: testers, designers, architects, project managers, product managers, executives, technical writers, users, programmers and human resources.

The collaboration needed in XP scream at us.

Testers amplify the communication in extreme scenarios beyond happy path
Designers clarify and write stories
Architects look for refactoring, system level tests and implement stories
Project managers facilitate communication
Product managers encourage communication between customers and programmers

Hand written notes. Elaborated by the author.

Executives support the team and encourage the team
Technical writers early feedback and value for users
Users write stories and make domain decisions
Programmers estimate tasks, break stories into tasks, write tests, write code, automate, improve design system
Human resources emphasis on team work and social skills

Chapter 11

Improve, find opportunities
Theory of constraints, solve one to create another
pull model versus push model — xp pulls and waterfall push
XP is not meant to fix business problems
Be prepared for change
Sponsorship is crucial

Chapter 12

Planning makes goals and directions explicit.
In XP planning is like going to buy croceries.
— the price are the estimates
— the budget the time available
Planning decides what to do next
— Estimates and cost are uncertain
Planning is a daily activity and quarterly activity
Plans are not prediction of the future

Manage the project by three variable: speed, quality and price. Usually speed and price are set outside of the project leaving only quality.

Scope is left out of the model, bringing it in we will have:

we can adapt
we can negotiate

Everyone on the team needs to be heard the team only commits to needs.

planning is something we do together
it is an exercise of listening, speaking and aligning goals for specific time period
some teams bring over the customer to the planning
estimates improve along the time, it is normal to start widly wrong and improving over time
XP first edition had estimates in points but in the second edition it was shifted to hours it makes the communication as clear and explicit as possible
— Inacurate estimates are a failure of information not values and principles

There are some related material with estimation and story points:

Escape velocity, better metrics for agile teams — Review (Lead time, Delivery frequency, Cycle time, Cumulative Flow Diagram, Code quality, Team joy and Forecasting)

Chapter 13

A dilema in software development:

test increase costs but leads to less defects
defects increase costs

Chapter 14

Design as a tool for improvement leads to different aproches. In the world of software development the cost to change is not set in stone.

In the physical world, incremental change in the real world cost too much the steps in between add too little value.

Incremental design in software is valuable because often we are writing applications for the first time. Reversing a change when constructing a building is costly one day a change can cost $ 500 and in the next day the same change can cost $ 10,000. In software reversing a day of work istrivial.

There is no option to not designm because unconsious design will lead to failure. The most powerful design heuristic is to have is “once and only once” a data, or logic should exists only in one place.

Quote extracted from the book around page 151 or so:

Most often, I didn’t improve the design because I was focused too narrowly on the problem of adding one more feature to the system. I didn’t try to balance the whole team’s productivity with today’s task. I didn’t think about how bad I felt jamming one more feature in where it didn’t belong. I didn’t think about how much motivation and satisfaction there is in doing a really good job.

For big systems that are legacy do not try to take everything at once, the key is to improve bit by bit. Part of incremental design is to find balance between delivering features and improving system design.

In XP design decisions are deferred until it can be made in the light of experience. XP teams prefer simple solutions where possible.

Chapter 15

Often people relates to scaling as a human only factor, in other words, scaling is adding more people.

Therefore Kent arguments other things to take into account while scaling:

People
Investiment
size of the organization
time
problem complexity
solution complexiy
cnsequence of failure

Kent applies the “divide and conquer” to tackle the scalability issue:

Check if smaller team solve the issue
if not, split the work among teams

Regarding investment, traditional accounting won’t work in software, it will create distortions. Find an ally in the finance that can help you with that — Each company seems to account software in a different manner.

The challenge is to get everyone working together. XP is suited to close cooperation with specialists.

Problem complexity

Month after month the goal is to improve and become helpful in an way that the work done is much better than if it was done in a corner.

Solution complexity

It is difficult to keep going when a team fixes an issue and create three more.
if you are fixing a defect in a area, clean up while you are there.

Consequence of failure

If we make mistakes, babies die. More than XP is needed in life critical situations.

Chapter 16

Skipped — interview

Philosophy of XP

This section explores how other disciplines are connected to XP.

Chapter 17

Chrisley project case, project in trouble (also known as the XP story):

it started with a phone call, someone was concern about the payroll system performance — Kent Beck wrote a lecture on Smalltalk performance
A project in trouble
— two months away from production
— listening to who was listening before answering
people were tired

Three options was given to the project CIO:

The last option was chose.

Ron Jeffries was the first full-time XP coach

How will the project work:

Three weeks iteration
The customer has control over the prorities and which stories goes first
implement stories
estimate stories
figure how many fit

The project got delayed three months (April) and it was live for 3 years after Chysler decided to decommission the project.

Chapter 18

Frederick Taylor industrial engineer. Taylorism assumptions.

Echoes of Taylorism can be heard in software development every time a person in authority changes an estimation from someone else.
Taylorism also appears when someone creates a department of quality apart from development

Chapter 19

Toyota Production System (TPS) eliminates the rigid stratification found in the Taylorism factories.

Mary and Tom Poppendieck write extensively about the importance of product development part, like deliverying value through software.

workers are accountable for the quality
software development is full of waste of overproduction

Chapter 20

Applying XP and see dramatic results takes a while more like years than weeks
starting with XP is more like getting into a poll than adopting a child
XP teams work differently and it can have negative social and political effects
leading by example is powerful
expecting others to do what you are not willing to try yourself is disrespectful
learning is not a straight line
Chose a coach: a good coach should encourage independence not dependence

DO NOT USE XP if an organization values are: secrecy, isolation, complexity, timidity and disrespect.

Chapter 21

Chapter 22 and Chapter 23

Chapter 24

Chapter 25

References

[1]K. Beck and C. Andres, Extreme Programming Explained: Embrace Change (The XP Series). Addison-Wesley Professional, 2004.
[2]J. Patton and P. Economy, User story mapping: discover the whole story, build the right product. “ O’Reilly Media, Inc.”, 2014.