Extreme Programming (XP) Practices

The most underrated agile framework isn't Scrum or Kanban. Let me break down XP framework through SWOT analysis - something every PM should know about XP before implementing it: 💪 STRENGTHS - High code quality through TDD and pair programming - Rapid feedback loops - catch issues within hours, not weeks - Strong team collaboration via daily standups - Customer-centric with Planning Game - Enhanced flexibility for changing requirements 🎯 WEAKNESSES - Demanding for junior developers - Resource-intensive (pair programming takes more time) - Can cause burnout if not managed well - Not ideal for large teams (20+ people) - Requires high technical discipline ✨ OPPORTUNITIES - Perfect for complex projects with uncertain requirements - Growing demand in fintech and healthcare industries - Great for upskilling your development team - Can blend smoothly with Scrum practices - Improves team's technical excellence ⚠️ THREATS - Resistance to pair programming in traditional teams - Heavy dependence on skilled developers - Risk of overhead with constant refactoring - Challenging to implement in fixed-schedule organisations Want better code quality, faster delivery, and happier developers? XP might be your answer. Start small, but start today. What's stopping you from trying XP? Let's solve it together 👇

When you're used to XP ways of working and then find yourself in a situation where these principles are not applied, things you previously didn't even realise were things begin to frustrate you. Before working in this way, I thought it was normal that pull requests would take a long time to review. I thought it was normal to see big merge conflicts, and for developers to throw finished code over a wall to testers to test their code. Context switching was normal - I've put my work into a PR now, that'll take a few days of back and forth, so while I'm working on something new I need to keep going back to this PR. The people reviewing my PR have to context switch themselves to review my PR - sometimes they'd ask for big changes and there's lots of async back and forth. All of this stuff I thought was normal for a significant amount of time in my career. After embracing XP, which involves things like pair programming, test driven development, trunk based development and continuous integration, I now see: * Traditional pull requests are mostly wasteful * Any ticket stuck in a "review" column for anything more than just a few minutes starts to frustrate me * Trust your automated tests; in 99% or more of circumstances, manual testing isn't necessary * We build better things faster when we collaborate and pair * Things move quickly, stress is low, everything is in a working state all the time * Complicated merges are not even a thing, merge conflicts are always tiny and easy to deal with * Life is better this way

Domenico Luciani has practiced XP for almost 10 years. Working for Tanzu Labs and Thoughtworks, he was responsible for introducing clients to pairing, TDD, and other XP practices in addition to committing code. Clients weren’t always excited about the change. Domenico’s secret to making it work? 1) Keep it casual. The term pair programming comes with baggage. Instead of asking to *pair* or *mob*, he starts by asking for a meeting, usually with the whole team, to understand the start to finish process of how software makes it from problem to production. Does this look like formal pairing or mobbing? Of course not, but it gives him a chance to introduce some of the practices and start building trust. 2) Start small. In the next standup, he looks for a task to tackle. The smaller the better. Because he’s new, Domenico asks a senior developer for help and schedules a 2 hour session for the next day. He doesn’t call it pairing. He doesn’t schedule a full-day session. Pairing can be exhausting and senior devs are busy, so he keeps the request small. 3) Make it fun. Domenico prepares well for these meetings and shows up with thoughtful questions. He doesn’t let the senior developer to think it’s a waste of time and he wants to give them a chance to flex their knowledge. When they show up, he suggests they use a pomodoro timer because it helps remind him to take breaks (and prevents the session from feeling like a slog). As the session wraps up, he’ll point out all of the things that went well. They usually made a bunch of progress, started a personal connection, and the senior had a chance to show their stuff. People aren’t always won over right away, but by keeping it casual, starting small, and making it fun, he's helped countless clients adopt XP practices in a simple and practical way.