This is a presentation that I gave at Shanghai Scrum Gathering in 2010.
It’s one about using Scrum in conjunction with Extreme Programming. Scrum
There are some myths surrounding Scrum and Extreme Programming and I’d like
to talk about some of those myths. The very first one I’d like to talk
about is the notion that Scrum is just merely a management process. Simply
a management process that can be wrapped around some technical expertise
and then everything will be good. Scrum is much more than this. Scrum is
systemic change to how we deliver software. The next myth that I’d like to
talk about is also that Scrum is simply XP without the technical practices.
In other words, XP is a superset of Scrum. And again, Scrum brings far more
to the table than just simply being Extreme Programming without the
technical practices. The third myth is that Scrum and Extreme Programming
are mutually exclusive. And again, that’s not true. We can certainly
combine Scrum with elements of Extreme Programming to make a process that
is much more effective.
Before we go too far looking into these myths, what I’d like to do is start
by talking about both Scrum and Extreme Programming so that we all have a
common understanding. Scrum is often described by its attributes and these
are the Scrum Roles, Timeboxes or meetings, and Artifacts. Then we talk
about Scrum by describing the process flow. This diagram that you see here
is one of the more typical diagrams that you would see. This is one of the
original diagrams taken from one of Ken’s presentations.
What you can see here are the Artifacts, the Product Backlog and the Sprint
Backlog. You can also see the process flow. So you can see the Product
Backlog being broken down to the Sprint Backlog. The team going away for
the duration of the Sprint, in this case, a 30-day Sprint. Every 24 hours,
in other words, everyday, the team has a daily send-up. At the end of the
Sprint, the team will have some increment of a potentially shippable
product. So this diagram very nicely calculates the whole Scrum flow and
the whole Scrum process.
Let’s talk very briefly about Extreme Programming. Part of the difficulty
about talking about Scrum versus Extreme Programming is that they’re
described in very different ways. Whereas Scrum was talked about as the
roles, the time-boxes and the artifacts. Extreme Programming details
several technical practices. There technical practices can be grouped under
common attributes. These common attributes include Feedback, Continuous
Process, Shared Understanding and, finally, Programmer Welfare. So really,
the Extreme Programming practices I talked about in a substantially
different way than we typically talk about Scrum.
To better explain some of the different Extreme Programming practices, I’ve
taken this diagram from XProgramming.com. It’s a diagram that was created
by Ron Jeffries. I think it’s a really excellent diagram. What you’re
actually looking at here is a frequency at which the different practices
are practiced and how they relate to each other. What you can see at the
very center of the diagram, indicated by the blue circle, are practices
that we would do very often, typically multiple times in a day. At a larger
level at a bigger timeframe, we would do the practices indicated by the
green circle. We would do these practices on a daily basis.
Finally, on the outer layer, these are things that we tend to do less
frequently. These are practices that we would do on an iteration-by-
iteration basis. What’s really interesting about this particular diagram is
that there is overlap with Scrum. The overlap occurs right here. Everything
outside of that ring, in other words, the bigger picture stuff is pretty
much addressed by Scrum. So Scrum does a very good job of addressing the
issues that typically come up outside of that ring. However, Extreme
Programming does a much job of describing the processes inside the red
Let’s talk about some of the differences between Scrum and Extreme
Programming. Scrum, itself, is agnostic with regard to its technical
practices. Scrum really doesn’t care. All Scrum says is that you need to do
some technical practices. And what we find is that by adopting Scrum those
teams are typically driven towards the Extreme Programming technical
practices. However, that’s a consequence of doing Scrum. Scrum, itself, is
very agnostic to the technical practices themselves. And so Scrum is not at
all descriptive in that regard.
The Scrum model for Roles and Responsibilities is far better defined than
anything you’ll find in Extreme Programming. Extreme Programming talks
about the Role of a customer which is the equivalent of a Scrum product
owner. However, there is no notion within Extreme Programming of the Role
of the Scrum master. In fact, it’s often quite confusing within Extreme
Programming trying to understand where the Roles and Responsibilities lie.
So Scrum tends to do a much better job to describe the three different
Roles and Responsibilities and how they’re interrelaced to each other.
The Scrum Timeboxes or the Scrum meetings are much better defined than
within Extreme Programming. Scrum specifically calls out the planning
meeting, the daily Scrum, the Sprint review and the retrospective. Not only
that, Scrum also talks about a timeframe when those should occur. For
example, the Sprint planning meeting occurs right at the very start of the
Sprint. The review and the retrospectives occur right at the very end of
the Sprint. Scrum tends to be far more disciplined about the Scrum meetings
and when they should occur.
Finally, Scrum explicitly lists some Scrum Artifacts. In particular, this
includes the Product Backlog and the Sprint Backlog. But it also often
includes elements such as the Release Burndown graph and the Sprint
The Extreme Programming model for technical practices is much better
defined than Scrum. The Extreme Programming model does have some
recommendations on what are some of the best practices to adopt. Whereas
Scrum, as I said earlier, is totally agnostic of those. So in that regard,
Scrum is superior because it explicitly helps teams understand what they
need to do in order to deliver good quality code. Extreme Programming has
the notion of a Continuous Process. This is totally lacking within Scrum.
Scrum really has very little in the way of discussion about Continuous
Finally, Extreme Programming introduce some concepts that make the Scrum
concept of “an increment of potentially shippable code” a reality. As an
example, Continuous Integration, producing some “increment of potentially
shippable code” without Continuous Integration, is almost impossible. I
would suggest that all teams that are building software with Scrum would
use Continuous Integration. That’s only one example.
So, Extreme Programming absolutely introduces some ideas and some concepts
that make it possible for software to really strictly delivery some
“increment of potentially shippable code” at the end of every single
Both approaches, both Scrum and Extreme Programming, have their strengths
and have their weaknesses. There’s an interesting thought experiment, what
would happen if we would combine Scrum and Extreme Programming? If we take
the best of Scrum and then also combine that with the best of Extreme
Programming, wouldn’t that make sense? Why hasn’t anyone done it before?
The answer is people have done it before. There are at least two different
examples of this. The very first example of this was known as XP@Scrum.
This was Ken Schwaber’s initial ideas of combining Scrum and Extreme
Not only that, Mike Beedle, Ken’s co-author on “Agile Software Development
with Scrum.” Mike Beedle also created his own approach of creating Scrum in
Extreme Programming and he called that XBreed. At some point, their
community decided that there really was only one version of Scrum and that
technical practices are outside of Scrum, so the Scrum framework, itself,
If you wish to, at some point, add elements of Extreme Programming
technical practices, then you are more than welcome to do that. However,
Scrum itself, is just really a very, very simple framework. So, how would
you do it? How would you, if you wanted to combine Scrum and Extreme
Programming, how would you actually do that? Here are my suggestions.
Firstly, try it all with Scrum. Adopt all of the Scrum framework,
everything that Scrum talks about. In other words, adopt the three Roles:
Product Owner, Scrum Master and Team. Adopt the Scrum meetings: Sprint
Planning Meeting, Daily Scrum, Sprint Review Retrospective and working with
Then, try adding some key Extreme Programming technical practices. The ones
that I would start off with include Continuous Integration, Test Driven
Development and Refactoring. I, personally, would start with that. In
particular, Continuous Integration tends to drive a lot of good practices.
So, I would strongly encourage you to adopt Continuous Integration. Then
once you’re comfortable with Continuous Integration, very shortly
thereafter, introduce some element of Test Driven Development and
Refactoring as you go along.
Once the team is comfortable with those initial Extreme Programming
technical practices, then add the more complex and the more philosophical
approaches that come from Extreme Programming. Once the team is comfortable
with Continuous Integration, Test Driven Development and Refactoring, only
then start to introduce some technical practices such as Simple Design,
Common Code Ownership and Small Releases.
There are a couple of things that I would absolutely avoid when trying to
combine Scrum and Extreme Programming. The very first thing that I would
avoid is mandating that all the technical practices be adopted. The
difficulty with this is that there are many technical practices in Extreme
Programming and some of them take a long time to adopt. By mandating that a
team must do all the Extreme technical processes right up front, by trying
to do that, you’re more than likely to overwhelm the team. Rather than try
and mandate all the technical practices, select a few key practices and
start with them and the provide education to the team on an ongoing basis
so that they can then start adopting new practices as they continue along.
The next point that I would like to make is please try to avoid unrealistic
expectations. Scrum and Extreme Programming are different paradigms in how
to write software. That difference in paradigm is often accompanied by
significant learning and also changes in behavior. The learning, the
changes and the behavior often take a great deal of time in order to do it
Don’t expect that this something that you’re going to do overnight. It is
something that teams will work at typically from anywhere between six
months to two to three years before they start actually understanding the
full depth of these different technical practices. So, it is a real change
for many teams. Please don’t expect that it will be something that will be
quick and easy. Any real substantial change is going to take time, but I
would also suggest that that is time well spent.
The final thing that I would like to suggest that you avoid is trying to
adopt Scrum without changing a deliver code. In other words, if what you’re
doing works in a wordful model and you decide to do Scrum, you should
expect that you will need to change how you’re delivering software. This
really does make sense if you think about it. If Scrum is such a paradigm
shift in how you deliver software, then shouldn’t you also expect that your
technical practices would have to change as well? And the answer is yes,
absolutely, that your teams will have to change their technical practices.
Adopting Scrum without addressing the technical side can be very
The final thing that I would like to talk about is why should we do this?
Why would a company or a team want to adopt, not only Scrum, but also the
Extreme Programming technical practices. Jeff Sutherland, the co-creator of
Scrum, often says that most high performing teams use both Scrum and
Extreme Programming together. And it’s really all about the performance of
the team. By using Extreme Programming technical practices in conjunction
with Scrum, we can deliver high quality software at the end of every single
Sprint. It’s only by delivering high quality software on a regular basis
that we can know the true performance at which the team can deliver
functionality to the business. Combining Scrum and Extreme Programming is a
powerful way to take your teams to the next level.
Thank you very much.
Scrum, Agile, Agile, Software, Project, Management, Agile, PM, Agile, Project, Management