The Elastic Leadership Book



        RSS Feed

Latest Entries


Why XP’s influence is more effective than Scrum

in a previous post i explained what are the six forces 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, 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 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. 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”).

« How to plan and influence change at your company | Main | The Five Dysfunctions of a Team »

Reader Comments (3)

Scrum was designed to be a generic process. Not only development teams can use Scrum. I've head that there is a photographers team here in Brazil which use scrum in their job.

As a generic process, it needs to be adapted and incremented to fit some teams needs. There is where XP comes in. XP brings some practices that's missing in Scrum for development teams.

December 10, 2009 | Unregistered CommenterHerberth Amaral


I'm not sure I agree with you. Scrum was developed as a process around software development. It was never meant to be generic. I can't see Scrum efficient or even relevant outside the software industry realm.


I've published an article lately on Kanban: ( ) which highlights the current limitations in Scrum and how Kanban is able to overcome those limitiations. The post has gathered some interesting comments from both sides.

December 12, 2009 | Unregistered CommenterPM Hut

A base idea of Scrum is that it is an empirical iterative process, and can be used for anything that is developed in an iterative manner, not just software development.

Google "the new new product development game", its a 1986 Harvard Business Review article explaining Scrum origins and not necessarily for software development.

December 21, 2009 | Unregistered CommenterPaul

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>