Better Together — XP and Scrum
Something that I have found vexing for quite some time is how common it is for many in the industry to use terms like “Scrum but …” in a pejorative sense, implying that teams should only be following the small set of practices that are part of Scrum. The reality is that for any Agile team to be able to repeatedly deliver working software over any significant length of time, Scrum by itself is not enough. Whether they realize it or not, the vast majority of teams that call themselves Scrum teams are operating as a Scrum-XP hybrid, or a Scrum-Kanban-XP hybrid, where they employ at least a subset of the technical practices that originated with XP.
Let me go on the record and say that teams that are only following the Scrum practices are unlikely to be successful over the long term, because at least a subset of the XP technical practices are a must for ongoing success as an Agile delivery team.
What’s the difference between Scrum and XP?
I have observed that there are not enough people who understand what Scrum does and does not include, so let’s start there.
What Scrum is — a set of management practices
Scrum is the application of empirical process control, which is a fancy way of saying that we should be making decisions based on experience, not based on some hypothetical set of assumptions that are not grounded in reality.
Simply stated, Scrum consists of a small set of management practices that are intended to help teams collaborate effectively and deliver work in an iterative fashion (let me emphasize once again — there are zero technical practices in Scrum).
To briefly summarize the contents of the Scrum Guide:
- There is a Scrum Team, which is composed of Developers, the Product Owner, and the Scrum Master.
- There are Scrum Events, which consist of the Sprint, Sprint Planning, the Daily Scrum (aka Daily Standup, in XP), Sprint Review, and Sprint Retrospective.
- There are Scrum Artifacts, which consist of the Product Backlog, the Sprint Backlog, and the Increment, where an Increment exists as soon as one item from the Sprint Backlog meets the Definition of Done.
- There is a Definition of Done, where any Scrum Team has a shared understanding of what “done” means for any Product Backlog Item. Note that in contrast to Acceptance Criteria, the Definition of Done is globally applied, while Acceptance Criteria are specific to individual Product Backlog Items.
What Scrum is not
Contrary to popular belief, none of the following things are part of Scrum:
- User stories. The work items in any given Scrum team’s Product Backlog or Sprint Backlog are written as user stories (often in the format “As a <persona/role>, I want <goal>, so that <desired outcome>”), but Scrum does not mandate any particular construct or format. Note that user stories are part of XP.
- Estimation. Even though the vast majority of Scrum teams do perform estimation at some level, the practice of estimation is not part of Scrum.
- Velocity. Velocity is not part of Scrum either; the notion of project velocity is part of XP.
- Technical practices. As noted above, there is no notion of technical practices (CI, CD, pair programming, TDD, etc.) in Scrum. The vast majority of the technical practices that teams typically follow originated with XP.
What is Extreme Programming?
It has been more than two decades since the first Extreme Programming (XP) team was formed, where they worked on a project called Chrysler Comprehensive Compensation (C3). The methods that team employed originated to a significant extent in the 1980s, when Kent Beck and many others were experimenting with better ways to develop software, i.e., an alternative to the “waterfall” approach that had become dominant by that time.
Making work visual has always been an important way of informing how Agile teams work. Therefore, as an introduction to XP, I recommend that anyone wanting to learn more would be well served by starting with these diagrams:
- Extreme Programming Project (end-to-end diagram)
- Iteration (diagram focusing on what goes on inside an iteration; note that what XP calls an iteration is conceptually similar to what Scrum calls a Sprint)
- Development (diagram focusing on development interactions and activities)
- Collective Code Ownership (diagram focusing on the core technical practices)
Note: For a visual that combines many of the elements from the diagrams above on one page, see Bill Wake’s Extreme Programming Overview.
Additional Reading about XP
If the visuals above intrigue you enough to want to read more about XP, see the following sources of information, which are listed more or less in order of shortest to read > longest to read:
- Don Wells, Extreme Programming: a gentle introduction
- Martin Fowler, BeckDesignRules (see also Xp Simplicity Rules)
- Kent Beck, Ward Cunningham, et al., Extreme Programming Core Practices (aka the 12 XpXtudes)
- Don Wells, The Rules of Extreme Programming
- Ward Cunningham, et al.,Extreme Programming (aka the WikiWikiWeb)
- Ron Jeffries, What is Extreme Programming?
- Kent Beck & Cynthia Andres, Extreme Programming Explained: Embrace Change (2nd Ed.)
Additional References
All references in this section are from Don Wells’ XP website, unless otherwise noted.
- Agile Models are Paintings, not Photographs (all models are wrong; some are useful)
- Agile Process Proverbs (words for any team to live by)
- Bill Wake, Arrange, Act, Assert (pattern for writing unit tests)
- Bill Wake, Sudoku Solver (interesting variation on TDD)
- Bill Wake, Tests from a Hat (a creative approach toward writing unit tests)
- Honest Plans (what estimation looks like in practice)
- Manage Your Goals Instead of Activities (main differences between Waterfall and Agile development)
- The Values of Extreme Programming (Simplicity, Communication, Feedback, Respect, Courage)
- XP and Databases (a pattern based on gold > silver > bronze databases [gold matches production db; silver is migrated gold db; developers have a bronze db migrated from silver db])
