Friday, November 2, 2007


Working in an XP environment, I've come to notice some of the hidden dependencies, and noticed in particular how symbiotic XP can be with SCRUM.

First, a bit of background. XP is a development process that uses the idea of very rapid iterations. The point of XP, in a nutshell, is that code will change, so your development process should be designed to accomodate code change, large and small. See my earlier blog post for more.

SCRUM is a project management process. It tells you nothing about how to write code; it only attempts to describe how to set up an environment around the activity of development such that you can ship. I wrote a blog post about this before.

I've started to notice that the terminology and ideas behind XP show up in SCRUM as well. For example:
  • Iterations (XP) = Sprints (SCRUM)
  • Force-ranked development cards (XP) = Product backlog (SCRUM)
  • Velocity (XP) = Velocity (SCRUM)
  • Stories (XP) = Product backlog items (SCRUM)
But it goes even deeper than terms. There are a fair number of similar goals, as well, that are somewhat isolated to these two processes:
  • Shippable product. Sure, every software development process has a shippable product as its goal. SCRUM and XP are more specific and call for a shippable product at the end of every iteration/sprint.
  • Development periodicity. In an ideal SCRUM and XP world, there is very little "crunch time". A given iteration/sprint is short enough and well-understood before it begins, so there should be few surprises and therefore little crunch time. It should be a steady pace throughout. In reality there are crunches, but they tend to be short - a few days instead of several weeks.
  • Small tasks. Because of the shortness of durations and the emphasis placed on estimation, tasks tend to be small - no more than a development week or so. There may be many tasks to accomplish a large feature, but each task is itself fairly short. This is what ensures that tasks can fit into an iteration/sprint.
  • Client emphasis. Both SCRUM and XP emphasize the power of the customer. Whether it's the customer himself (as is ideal in XP) or some proxy (usually product management, and more normal in the real world), the client is the source of all requirements, and requirements are specified in terms the customer can understand.
So, what does all this mean or imply?

The only real conclusion I can draw is that if you're in an XP environment, you should strongly consider SCRUM for your project management process. It will help bring the entire company into the same way of thinking, and lead to fewer process-based clashes.

* Disclaimer: I make no statements about which came first, or which is better. I'm merely noticing similarities.

No comments:

Post a Comment