---
title: "Why XP’s influence is more effective than Scrum"
url: "https://www.5whys.com/articles/why-xps-influence-is-more-effective-than-scrum.md"
canonical: "https://www.5whys.com/articles/why-xps-influence-is-more-effective-than-scrum.html"
published: "2009-12-09T23:31:06+00:00"
updated: "2011-04-04T22:49:54.025000+00:00"
tags: ["Influence", "Ri", "Self-Leading Phase"]
author: "Roy Osherove"
description: "Why XP practices like TDD, pair programming and continuous integration change team behavior better than Scrum alone, seen through six forces of influence."
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Why XP’s influence is more effective than Scrum

in [a previous post i explained what are the six forces](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html) that influence behavior. based on this, we can now begin to understand why some development methodologies are more effective when applying them at an organization or team level.

for example, [Scrum](http://en.wikipedia.org/wiki/Scrum_\(development\)), is a process that only deals with the behavior of the customer, the scrum master and the team at the beginning and end of each sprint (getting requirements, managing backlog, estimation..)

but Scrum _does not_ address any of the team activities _inside_ an iteration like XP does (_pair programming, test driven development, continuous integration and automated builds, single room..)_

but the fact is that it is precisely those things that [XP advocates](http://www.extremeprogramming.org/) that have to do with the 5th and 6th forces (physical environment and rewards) that make the biggest difference in teams. XP really deals with _all_ the forces that shape human behavior, thus _influencing change_ during its application.

Scrum is a process that only uses a few of the forces and thus is [harder to achieve as a standalone process](http://www.netobjectives.com/blogs/Is-Scrum-Failing-Us). that’s why scrum and XP together (or XP alone) will always trump in terms of adoption (when done right) over bear Scrum.

> can you guess which forces Scrum does _not_ use to influence human behavior?

The funny thing is, Scrum is easier to adopt for management. I think this is specifically because there are less behavioral changes in Scrum (or at least appear to be). The truth is most if not all Scrum practitioners soon realize there is no Scrum possible without automated tests, Continuous integration, team in the same room and the other XP practices. but these are then introduced quietly into the process, or the process fails.

Why would it fail without them? because a team cannot be expected to product software on a weekly or biweekly basis without automated tests that help it overcome frequent change. it’s just reality. as a force it’s force #2  and #6 (“persona ability – can i do it?” and “structural ability = does the environment support my behavior”).

## Read next

- [The 3 maturity stages of a software team and how scrum fails to identify them](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html): The chaotic, mid-life and mature stages of a software team, the leadership each one needs, from dictator to coach, and why Scrum Masters miss them.
- [How to plan and influence change at your company](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html): How the six sources of influence from the book Influencer explain why change efforts like adopting TDD fail, and how to find the vital behaviors to change.
- [How to influence others](https://www.5whys.com/articles/how-to-influence-others.html): Two books for team leaders who want to drive change: How to Win Friends and Influence People for one-on-one influence, and Influencer for the macro level.

## Topic

- [Scrum Master](https://www.5whys.com/topics/scrum-master)


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/
