<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>XP eXtreme Programming | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/xp-extreme-programming/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Mon, 30 Mar 2026 16:28:20 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	

<image>
	<url>https://www.scrumexpert.com/wp-content/uploads/favicon.png</url>
	<title>XP eXtreme Programming | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Resources for Code and Database Refactoring</title>
		<link>https://www.scrumexpert.com/resources/code-and-database-refactoring/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 25 Feb 2026 17:49:12 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Resources]]></category>
		<category><![CDATA[technical debt]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8585</guid>

					<description><![CDATA[Martin Fowler defined refactoring as a &#8221; disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior&#8221;. In the days of Agile development where code is delivered after one or two-week cycles, you start quickly to deal with &#8220;legacy&#8221; code, what was known as &#8220;maintenance&#8221; for projects that had longer delivery time frames. To limit your technical debt, code refactoring should be an ongoing activity in Agile teams. Even if refactoring is mostly linked to code, the term is also widely used for every restructuring effort: database definition code, testing scripts, software architecture or development process. In the core principles and best practices of refactoring, you will have to keep behavior unchanged as you verify with tests before and after refactoring. You work in small, incremental steps: make tiny, reversible changes and run tests frequently. It is important to automate tests and CI. A solid test suite and continuous integration are prerequisites to code refactoring. In addition, you need to improve readability of your code first with prefer clear names, single-responsibility functions, and consistent style. Finally, you need to refactor for intent: you have to change the structure so the code expresses why it exists, not just how. I am sure to forget some precious resources in this overview, so do not hesitate to add some pointer in the comments (no commercial tools, thank you). Some of these resources are language specific (Java, Ruby, .Net, Python, PHP and even Fortran) but you <a class="mh-excerpt-more" href="https://www.scrumexpert.com/resources/code-and-database-refactoring/" title="Resources for Code and Database Refactoring">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Agile Engineering Practices Are Essential to Achieve Agility</title>
		<link>https://www.scrumexpert.com/videos/agile-engineering-practices-are-essential-to-achieve-agility/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 27 Jan 2025 18:53:09 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8219</guid>

					<description><![CDATA[Without good agile engineering practices in place, a Scrum team&#8217;s ability to continue to be productive degrades over time. This presentation explores the difference between a change of &#8220;direction of speed&#8221; versus true agility, and why agile engineering practices are essential to achieve agility. Scrum can be used without any agile engineering practices. After all, Scrum is just a framework. Yet, a Scrum team developing software cannot progress very far unless it embraces good engineering practices and seeks technical excellence. Agile engineering practices are crucial for attaining agility because they facilitate quicker validation cycles and enable early feedback. For example, validation and feedback in real-time on quality when pairing, or that comes with proper Continuous Integration being in place. Many consider agile engineering practices to be difficult and expensive to implement, potentially interfering with timely delivery. Nevertheless, I believe that committing resources to engineering practices that improve quality and enable automation will support sustainable development in the future. Investing in agile engineering methodologies might give the impression of a temporary slowdown in operations; however, the primary goal is to ensure sustained or improved speed moving forward, all while maintaining flexibility for future adjustments. Video producer: https://devdays.lt/]]></description>
		
		
		
			</item>
		<item>
		<title>Putting XP in Scrum</title>
		<link>https://www.scrumexpert.com/videos/putting-xp-in-scrum/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 03 Aug 2022 15:27:41 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7152</guid>

					<description><![CDATA[XP (eXtreme Programming) Engineering Practices such as Continuous Integration, User Stories, Pair Programming and Test Driven Development can mean the difference for a Scrum team between saying that you&#8217;re agile and actually being able to be competitive in the market and maintain high quality and confidence in your code. This presentation proposes an open and honest conversation on the process of transforming your Scrum team or Agile organization towards a more continuous delivery, pipeline driven organization, and the software engineering practices you will need along the way. Video producer: https://gotocon.com/]]></description>
		
		
		
			</item>
		<item>
		<title>You Must Be Crazy To Do Pair Programming</title>
		<link>https://www.scrumexpert.com/videos/you-must-be-crazy-to-do-pair-programming/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 14 Mar 2022 22:25:07 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[pair programming]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6962</guid>

					<description><![CDATA[Pair Programming is probably considered to be the most extreme &#8216;Extreme Programming&#8217; practice, and a powerful technique for unlocking learning in a software development team. This video looks at this cultural practice that supports our ability to create better software faster in continuous delivery and DevOps teams. The presentation from Dave Farley provides pair programming examples, describes some pair programming best practices, and challenges some thinking about pair programming patterns and antipatterns. When Kent Beck wrote about Extreme Programming (XP) he described Pair Programming as one of the technical and cultural disciplines that helped to improve the quality and efficiency of software engineering. Few teams that practice it would go back to working without it. Video producer: https://gotocon.com/]]></description>
		
		
		
			</item>
		<item>
		<title>Technical Agile Coaching with the Samman Method</title>
		<link>https://www.scrumexpert.com/knowledge/technical-agile-coaching-with-the-samman-method/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 19 Jan 2021 10:07:07 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Books]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[coaching Agile]]></category>
		<category><![CDATA[people]]></category>
		<category><![CDATA[scrum team]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6521</guid>

					<description><![CDATA[If today many people equal Agile with Scrum, the Agile approach is also deeply rooted in software engineering practices, like pair programming or refactoring, promoted by the eXtreme Programming (XP) movement. In this book, Emily Bache presents the Samman Technical Coaching approach. It is a method for helping software development teams to become more agile and raise the quality of their work. As Emily Bache writes it “Software development these days is a team sport and it doesn’t work to only train individuals”. You need to develop collaborative teams and “Samman” is a Swedish word that means “together”. The approach promoted by this book is based on the Mob Programming approach proposed by Woody Zuill. The book describes the two main “tools” of Samman Technical Coaching: ensemble working and learning hours with examples. A section is also dedicated to pitching the idea of Agile technical coaching to organizations and how to start doing it. The book is largely based on the Agile coaching experience of Emily Bache and contains many real-life situations and dialogues. It is easy to read and well-structured. I will recommend it not only to Agile coaches, but to every member of an Agile team that is interested in practical approaches for technical improvement and collaborative working. Reference: Technical Agile Coaching with the Samman Method, Emily Bache, https://leanpub.com/techagilecoach Quotes As with any new skills, the way to learn is through a combination of teaching and practice. The Samman method includes a series of short lessons called ‘learning <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/technical-agile-coaching-with-the-samman-method/" title="Technical Agile Coaching with the Samman Method">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>An Introduction to Evolutionary Design</title>
		<link>https://www.scrumexpert.com/videos/an-introduction-to-evolutionary-design/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 19 Oct 2020 06:27:16 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[software architecture]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6441</guid>

					<description><![CDATA[Modern software development inspired by Agile approaches welcomes changing requirements, even late in the process, but how can we write our software so that those changes don’t create a mess? Evolutionary design is the key. It is a technique that emerges from Extreme Programming (XP), the method that brought us test-driven development (TDD), merciless refactoring, and continuous integration (CI). In this presentation, James Shore shares what he has learned about agile software design and architecture through in-depth animations of real software development projects. You will see how designs evolve over time and you will learn how and when to use evolutionary design for your own Scrum projects. https://www.youtube.com/watch?v=QJRAeoOHewo Video producer: https://yowconference.com.au/]]></description>
		
		
		
			</item>
		<item>
		<title>5 Steps to Build High Performance Agile Teams</title>
		<link>https://www.scrumexpert.com/knowledge/5-steps-to-build-high-performance-agile-teams/</link>
					<comments>https://www.scrumexpert.com/knowledge/5-steps-to-build-high-performance-agile-teams/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 04 Sep 2017 14:11:14 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[scrum team]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4562</guid>

					<description><![CDATA[The concept of team is at the heart of Agile software development and frameworks like Scrum. Forming high performance Agile teams is however not obvious. In this article, Debbie Madden suggests five steps that could bring your software development teams beyond the basic principles of Agile. Author: Debbie Madden Stride, https://www.stridenyc.com/ Agile software development is not just a series of principles or procedures: it is a mindset that every team must foster in their own way. Let’s run through some key strategies to building that culture in an organic way, ones that will stick with your team for the long-run. Agile development comes with its own vocabulary and set of processes that everyone on your team must learn if you hope to implement it. But no matter how familiar your team is with the principles of Agile, it will not be able to execute them without a culture that values teamwork at every step of the development process. We have listed some steps you can take to go beyond the basics of Agile to facilitate and encourage the habits that lead to high performance in Agile development teams. 1. Encourage a Culture of Psychological Safety When Google set out to identify the qualities that made for successful teams and companies, it came to a surprising discovery: more so than teams with a few “all-stars” in their field, teams in which people felt a sense of “psychological safety” performed best at their respective tasks. People generally succeed when they feel free <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/5-steps-to-build-high-performance-agile-teams/" title="5 Steps to Build High Performance Agile Teams">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/5-steps-to-build-high-performance-agile-teams/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Managing Technical Stories and Bugs</title>
		<link>https://www.scrumexpert.com/knowledge/managing-technical-stories-and-bugs/</link>
					<comments>https://www.scrumexpert.com/knowledge/managing-technical-stories-and-bugs/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 06 Jan 2016 16:02:01 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3023</guid>

					<description><![CDATA[If delivering business value should be the main goal of a software development project, not all the developers&#8217; activities are contributing to this objective. In his book &#8221; Scrum Shortcuts without Cutting Corners&#8221;, Ilan Goldstein discusses how you should deal with bugs and the technical aspects of your software project. I like Henrik Kniberg’s straightforward definition of technical stories from his book Lean from the Trenches (2011): &#8220;Technical stories are things that need to get done but that are uninteresting to the customer, such as upgrading a database, cleaning out unused code, refactoring a messy design, or catching up on test automation for old features.&#8221; I hear two common questions when it comes to technical stories: * How can we write technical stories when user stories are supposed to be user-centric? * How can we represent technical stories using the typical user story format? My answer to the first question is that, wherever possible, instead of writing independent technical stories, try to represent the technical requirement as tasks within one of the functional user stories that is reliant on this technical work. Remember to ensure that if more than one functional story relies on the technical work, you factor in the tasks only once and in the story that has the highest priority. I like the option of including technical work within functional stories (rather than as separate technical stories), primarily to ensure that they don’t get ignored by the product owner simply because they might be “uninteresting to the <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/managing-technical-stories-and-bugs/" title="Managing Technical Stories and Bugs">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/managing-technical-stories-and-bugs/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Pair Programming for Remote Teams</title>
		<link>https://www.scrumexpert.com/knowledge/pair-programming-for-remote-teams/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 26 Oct 2015 16:37:21 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[distributed teams]]></category>
		<category><![CDATA[pair programming]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=2899</guid>

					<description><![CDATA[Pair programming is one of the original practice of eXtreme programming, but it is also one of the least used by Agile software development teams. In his blog post, Alisdair McDiarmid explains how Customer.io uses pair programming with remote teams. Customer.io has been growing rapidly and its teams work in different location. Pairing has been used to allow people in different teams to work together virtually. Even if the technical aspects of pairing might be tedious, the practice has bring many benefits that include improved collaboration, quicker bug fixing and faster feedback. The blog post explains all the benefits of having two brains focusing on certain tasks. The most important benefit is that participants are learning quicker. Alisdair McDiarmid wrote &#8220;For me, whether remote or in person, the most important reason for pairing is an obvious one: learning. I’ve already learned a ton of things from my new colleagues, and I’ve been able to teach them a little of what I know too. This can be something as simple as a neat Vim trick, or as involved as the history of a collection of software components. Every time I pair with someone, I get a little better as a software engineer, and those tiny improvements add up to create a more effective engineering team.&#8221; Read the full blog post on http://customer.io/is-open/How-Pairing-Powers-Remote-Teams.html]]></description>
		
		
		
			</item>
		<item>
		<title>Book Review: Essential Skills for the Agile Developer by Alan Shalloway</title>
		<link>https://www.scrumexpert.com/knowledge/essential-skills-for-the-agile-developer-by-alan-shalloway/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 25 Sep 2012 11:01:10 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Books]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[people]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1226</guid>

					<description><![CDATA[If Scrum provides the project management framework used in a majority of Agile projects, eXtreme Programming (XP) is the main source of technical practices for Agile software development. This book written by Alan Shalloway, Scott Bain, Ken Pugh and Amir Kolsky is focused on these technical aspects. The first part deal with the coding and testing activities, and the second part discusses how to handle the software design activity with an Agile perspective. I have found particularly insightful the part that deal with software design. It presents guidelines to navigate between the dangers of either overdesign or not having enough design. This book is recommended to every software developers who want to write good code that is easy to test and easy to change, whether it is in an Agile context or not. Quotes Reducing Complexity: Overbuilding systems is one of the greatest causes of waste in software development. A function that isn’t used doesn’t just waste the time it took to write it, it makes the system more complex. This makes adding other functionality or fixing existing errors much more time-consuming, not to mention that the system is likely to have more errors in it. By clarifying the scope of work in a clearer way, we can help avoid this. Acceptance tests and requirements are linked. You can’t have one without the other. The tests clarify and amplify the requirements. A test that fails shows that the system does not properly implement a requirement. A test that passes is <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/essential-skills-for-the-agile-developer-by-alan-shalloway/" title="Book Review: Essential Skills for the Agile Developer by Alan Shalloway">[...]</a>]]></description>
		
		
		
			</item>
	</channel>
</rss>
