Rediscovering Agile with Extreme Programming

Extreme Programming (XP), created by Kent Beck in 1996, is often overshadowed by other agile methodologies. However, its principles and practices remain incredibly relevant. Everyone is doing Agile with Scrum, Kanban, Scrumban, SAFe… you name it. But at its core, Extreme Programming is dedicated to development. You can do any task other than development with Scrum or Kanban, such as moving to a different flat, organizing an event, etc., but XP is specific to development.

The latest data that I was able to find was from the 14th State of Agile Report from 2020, which says that only %1 are using XP but in this article, I will try to remember/introduce XP, then talk about cons, how it can get along with other practices and in the last part talk a little about how I would apply XP in my next project/startup…

via 14th Annual State of Agile Report

Firstly, Back to Basics. What was the original agile manifesto?

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more...

Scrum, Kanban, and others have different definitions that depend on these values but Extreme Programming says that it’s specific to development.

Sure every process will and should change for different companies, it depends on context, teams, and in the end people but XP has 5 main principles that we might have forgotten and my take and checklist on each one is as follows in a more modern ( for who? me… ) way :

(via https://www.collidu.com/)

1. Communication:

• Do you have a clear communication with your team? Can everyone access any information? Is it all written so that they are easily accessible?
• Do you have a clear communication with business? Can you feel the same pain points? Can you feel the same opportunities? Are you trying to reach the same goals together?
• Do you any have barriers within the team, Does everyone trust each other and can easily talk?
• Do you have conflicts within the team/company? As you should have some conflicts in a healthy, open environment; do you resolve those conflicts peacefully and constructively?
• Do you have a pair programming matrix to see who communicates whom and if it’s well spread within the team/company?

2. Simplicity:

• Do you break down tasks into the very smallest tasks? Do we deliver value as quickly as possible in the simplest way?
• Do we deliver in small batches? Do we deliver minimum viable product or value like version 0.1 instead of big-scoped ones?
• Do we keep everything simple and stupid ( kiss ) and regularly check if we are gonna need it ( yagni ) or not?
• Do we remove/delete unused code, and unnecessary complexity from time to time? Do we review our architecture, and process to make it as simple as possible?
• Do we avoid over-engineering?
• Do we communicate in simple terms? Are we trying to talk in simple terms or explain anything in simple terms so that it is easy to understand?

3. Feedback:

( This is the one I love most, the most valuable one I think )

• Do we do TDD? Do we actually do TDD? Do we actually, really write tests before even writing any code?
• Do we have tests that give instant and meaningful feedback?
• Do we have a fast ( under 10 min ), reliable automated CI/CD pipeline that we can deliver value as robust, and quickly as possible?
• Do we do Code Reviews? Do we have direct but constructive feedback on that?
• Do you have short development cycles like 1 week?
• Do we do retrospectives? Do we track/measure retrospectives to see progress? Do we have open/’bloody’ retrospectives that we can talk about anything?
• Do we receive instant customer feedback? Do we have a process for getting these ones constantly to see if we can fulfill their needs?
• Do we do pair programming to receive feedback from our colleagues? Do we rotate pairs regularly? Do we regularly make sure that we ensure diverse feedback and knowledge sharing?
• Do we practice open and honest communication, even when discussing difficult or uncomfortable topics?

4. Courage:

• Are we brave enough to make the necessary changes? Are we comfortable to change anything in the code? Do we feel very comfortable with refactoring anything without breaking stuff?
• Do we identify technical debts in a proactive way? Do we allocate time for that? Do we seek potential issues proactively?
• Do we encourage experiments, spikes with new techniques, and ideas in the codebase? Do we feel safe to try out new things even if we fail?
• Do we take ownership of our code, work, and decisions in good and bad?
• Do we feel empowered to make decisions and take responsibility?
• Do we feel comfortable to fail?

5. Respect:

• Do we feel respectful for our work, our friends, our outcomes, our customers, or our working environment?
• Do we have an inclusive environment? Do we feel valued, and respected regardless of whom we are and our background?
• Do we have processes for feedback, 1–1s, and mentorships?
• Do we recognize and celebrate achievements? Do we thank each other?
• Do we give feedback in a constructive/respectful way?
• Do we have a knowledge-sharing environment? Do we avoid a competitive environment?
• Do we respect our colleagues and listen to them? Do we care about their ideas, concerns, and suggestions?
• Do we respect each other’s work-life balance or their personal time and life? Do we help others to avoid burnout?

These values are the core part of Extreme Programming. It also has some rules that can be summarized here :

http://www.extremeprogramming.org/rules.html

See this one as a checklist, how many do you apply in your daily routine? When Planning do you use user stories or divide your project into iterations?

When Managing, do you have a pace, and monitor your velocity and quality? Do you customize XP for your own needs?

When Designing, do you aim for simplicity? Do you do spikes? Do you refactor often enough?

When Coding, do you do TDD, do you pair programming? Do you have standards, to get feedback instantly?

When Testing, do you have high but meaningful coverage? When there is a bug do you create a test first and reproduce the problem and fix it later?

Don’t forget that all those idioms, values, and rules were created nearly 30 years ago; no microservices back then, no K8s, golang, scale challenges, no AWS etc etc… So the good thing and the best thing about XP is, you can modify; customize XP values, rules based on your needs…

Key Practices play an important role in XP also;

Coding standard — Agreed set of rules are applied everywhere, no exceptions
Collective ownership — Everyone owns and is responsible for all the codes
Continuous integration — We integrate our code changes very frequently.
Metaphor — Everyone knows everything and talks in the same way, developers to customers…
Onsite customer — We have a customer that we can reach anytime.
Pair programming — We do code together, and learn from each other.
Refactoring — We improve our design all the time, proactively.
Simple design — We carve for simplicity all the time
Small releases — We do frequent small releases
Testing — TDD is our main coding practice, we test first all the time.
The planning game — In each iteration, we plan our release and iterations with some rules.
40-hour week — The work-life balance is very crucial, no overtime but work in a full concentrated way; no distractors including unnecessary meetings…

Iterations are the heartbeats in XP, which depend on practices and rules as follows :

So you will have User Stories and then you can do Spikes if needed. After that you can do a Release plan; based on the plan; you can plan iterations. Please refer to Release Planning for further details on how to iterate the project.

XP has cons, by the way, nothing is a silver bullet. XP might not be the best fit for a company/team, if :

• Teams are not ready for the practices and rules
• The teams are not highly disciplined
• You have a huge team
• The project has many regulatory rules.

But in the end, it depends. It depends on how you configure and adopt XP based on your needs.

Real World Example/Checklist

OK, Long story short, how would I use XP in real life in my next project/startup/company? Here are the rules and principles that I would write these on a wall and try to make sure that we obey them :

No build is longer than 10 min.
We do Trunk Based Development
The customer ( or PO ) is onsite with the team
The team is together at the same office or at the same video conference in the initial phase for at least 5–6 hours per day.
No working more than 40 hours.
Drink coffee together, dinner together, and work together…
Every decision is talked & simply documented
Each code is tested
TDD is how we develop code, all the time.
Form and be a team first, everyone should trust each other and should be open
We pair program every task in the initial phase…
We do one-week iterations and deliver value as quickly as possible
Refactorings are done all the time, with no tech debt.
If there is a tech debt, we fix it.
If there is a bug, we write the test first and then fix it.

And does this seem complicated to you? It’s sure not. I had an absolute chance to try and see XP in action in two big projects that were delivered on time, with good quality, and every single one of us was having hell of a fun. So, don’t be afraid to create your own version or use the original version.

XP vs Scrum/Kanban…

I think the best part of XP is that it can and should integrate easily with other agile methodologies. There is no “versus” here, to be honest. You can still use Scrum and apply XP alongside it.

You can check the scrum.org blog on Scrum & XP for details but as a summary, you can get the best of both worlds. You can plan your sprints and have Product Owners and Scrum Masters (similar to Agile Coaches in XP). As I favor using the good, necessary, and applicable parts from Scrum, you can combine it with XP. XP requires a one-week sprint, and Scrum accommodates that.

Thanks to my friend Onur, who made me remember a very nice article on this by Martin Fowler; Flaccid Scrum also outlines the same concept which is surprisingly from 2009 ( 15 years ago ! ). From the article:

Scrum seems to be particularly common as the nominative process the team is following. For many people, this situation is exacerbated by Scrum because Scrum is process that’s centered on project management techniques and deliberately omits any technical practices, in contrast to (for example) Extreme Programming.

You can make those practices get along easily. In the end, they are (should) based on the Agile Manifesto. The following image may help you to see how those two interact.

Were you able to make it until this point? Congrats… Let’s wrap it up… While Extreme Programming might seem like a relic from the past, its principles and practices are incredibly relevant and beneficial for modern development teams. XP focuses on your codebase health, developer experience, work-life balance, and delivering value and it’s always more focused on the development side, which is something we seem to have forgotten in the last few years.

By rediscovering and incorporating XP into your workflow, you can create a more effective, cohesive, and resilient team ready to tackle any challenge. You can choose some principles, and rules from above and be as XP as you can, but you can have your way and be agile in terms of development not by doing some meaningless standups in the mornings…