Scrum vs. XP

I have worked on both XP (extreme programming) and Scrum projects. There has been a lot written about the differences between Scrum and XP. Here are my personal observations.

First off, XP follows a simple set of rules and practices which can be summarized in a single page whereas Scrum is so complicated that there is a ScrumMaster certification.

There is a perception that XP does not scale well to large projects. XP projects should have one team maintaining a single code base, because "collective ownership" is one of the XP rules. Scrum projects, on the other hand, may have multiple teams working on a single application with several simultaneous branches working towards different releases. Developers are then only allowed to work on the branch that their team has been assigned.

I have found that in such large projects people are afraid to make changes for fear of creating new problems. So, opportunities for improvement are ignored. Although Scrum may scale to a larger team, it will not fix this problem. It should be obvious that a large team will be less agile no matter what methodolgy is being followed.

Scrum does not require TDD (test driven development) or pair programming. In point of fact, many developers don't want to do TDD or pair programming and will resist doing so even after they've been told to. The larger a team/project gets, the more trouble you are going to have convincing people to change the way they work.

I feel that TDD and pair programming should go hand-in-hand. Developers who don't want to write their tests first will not do so unless they are paired up with other developers who are in the habit.

Developers who aren't doing TDD will resent having to write unit tests, because it is an added task which makes it harder for them to get their work done on time. So, they will not put much effort into them. Without pair programming, nobody will know the difference until somebody later has to maintain code with crappy unit tests.

Developers who do TDD will be testing and coding simultaneously and finish both at the same time. So, the testing just becomes part of the process and is not an added step.

In addition to helping to encourage TDD, pair programming eliminates the need for separate peer code review since the peer review is happening simultaneous to coding. By contrast, formal peer code review meetings tend to nit-pick and make the developer feel that she is under the microscope intead of the code.

Unfortunately, most developers will resist pair programming as much as they resist TDD. One reason is that they may not like having two people crammed into a cubicle designed to fit one person. The ideal pair programming workstation will have two monitors and two sets of keyboards and mice. Another reason is that they cannot check their e-mails and such when they are at another person's desk.

So, TDD and pair programming require a real cultural shift and encouragement from the top down. Usually the project managers and architects will have to force the issue.

However, most people do not understand the benefits of these XP practices and the tendency of managers is to think pair programming will require twice the number of programmers to accomplish the same amount of work. I would simply counter that if pair programming requires more developers, why is it that XP projects usually have less devlopers as per the argument that it doesn't scale well to large projects?

The fact that XP requires team members to work more closely together should not be a cause for concern. The word "scrum" is a term borrowed from the sport of Rugby. Unfortunately, the way software development usually works with the Scrum methodology is that team members get together for the daily scrum, sprint planning meeting, etc. However, then they are sent out to work independently on their assigned tasks as if they are not part of a team. The result is that the success or failure of the iteration becomes dependent upon the weakest link.

I believe that XP teams can accomplish much more with far fewer people with less risk, and it is entirely possible to do both Scrum and XP so that you receive the benefits of both. Companies could save a lot of money if they would really embrace the XP practices, but in all honesty it is not the easiest path.