The Agile World

Agile isn’t new. It has been around for years with different names.

Today’s Agile has matured. It’s mainstream. It isn’t rinky-dink — it scales. Big companies are using Agile methods. The two with greatest mindshare are Scrum and Extreme Programming (XP). Here’s a quick overview of both.

The Scrum process looks like this:

Here’s how the Scrum Alliance® website describes the framework in 30 seconds:

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum).
• Along the way, the Scrum Master keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which of these milestones marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends.

The XP process isn’t quite as easy to diagram because there’s more in it, but it looks something like this:

We’re programmers, so we can talk at length about XP. Kent Beck’s second edition of Extreme Programming Explained brings it more up to date with developer experience in the real world.

Since we’ve actually done it, and we found it enlightening and downright fun, it’s easy to wax poetic about it. But we’re also a practical guy, so we’ll let Don Wells sum it up:

XP is an informal iterative software development discipline based on values, principles and practices designed to keep a team humanely focused on delivering real software with real business value frequently and confidently, while addressing risk at all levels of the development process.

The XP practices work together to make that happen, like this:

• The team (meaning everyone: programmers, business people, testers, etc.) does release planning to create high-level stories representing big features.
• Programmers estimate those stories in weeks, and the business people choose which stories to include in the next release (ideally 3 months’ worth of stories).
• The team does iteration planning for the first one-week iteration to break down the big stories into smaller ones that can be worked on within a week.
• Business people choose which stories to work on in the first iteration, and the programmers estimate cost in points (we recommend a scale from 1-5 where 1=easy, 5=hard).
• The team puts enough stories in an iteration to match their velocity, or the number of points they completed in the previous iteration.
• Programmers take stories from the top of the stack of cards, and first work with business people and testers to create a failing story test for the feature.
• Programmers then write code to make that test pass, using a predictable rhythm: first write a failing unit test for each bit of business code, then write enough code to get the test to pass.
• Programmers continue that rhythm, periodically rotating pairs as they code stories, and integrating code as they complete stories by getting all the tests to pass.
• Every day during the iteration, the programmers and potentially others on the team have a standup meeting to review what they did yesterday, what they learned and what they’ll do today.
• When the week is done, the team has a retrospective to reflect on what they did, what worked and what didn’t.
• Then they repeat for each future iteration.

Scrum and XP aren’t so different. Before I talk about that more, though, let me explain what I think are the three big mind shifts of Agile development.

Scrum vs. XP

Ask people how Scrum and XP relate and you’ll probably get as many opinions as people.

It’s most common to hear people say that XP is a superset of Scrum. Scrum focuses on project management, which means you can use Scrum practices for any project, not just for software development. XP focuses on things developers do on software development projects.

Well, yes and no.

In a nutshell, Scrum doesn’t specify any practices for doing the work a team needs to do. It treats the work as a black box. You can plug XP in there if you’re developing software, or some other process if you’re doing something else. Oh, by the way, XP includes pretty much everything in Scrum.

Some would argue that XP does not contain everything in Scrum.[1] We think those debates are nitpicky.

Roy has personally written about all of the practices supposedly in Scrum but not in XP. He and rest of the XP world have assumed they are part of XP for years, at least in practice if not “officially.”

We’ll boldly assert that when XP does not contain all of Scrum, an XP team is doing XP wrong.

So, does XP fit inside Scrum, or is XP a superset of Scrum?

We think of it as the latter, because much of our direct experience as programmers is with XP practices. It really doesn’t matter. Names matter less than results.

XP is much better defined, certainly when it comes to what software developers should do every day, but XP and Scrum aren’t at war with each other.

Both describe how to manage and do projects, both use similar terminology and both are Agile. They’re pretty much interchangeable where they overlap. Here’s an example in terms of the language each uses:

Tomayto, tomahto if you ask us. Distinctions without differences. There are some differences worth noting, though[2]:

• Scrum tends toward a stronger customer focus, while XP tends toward a stronger developer focus. True, but a good XP Coach would say that you must have a customer focus during planning and programming if you want the team to deliver real business value, which is the entire point.
• Scrum is strong on management but doesn’t offer much to developers, while XP has both. True in my experience, although it’s also true that the original writing about XP didn’t talk too much about management, or large organizations, or scaling, etc.
• Scrum has a Product Owner to prioritize work to deliver business value, while XP lets the Customer choose what gets worked on first. True, but I’m not sure this difference matters much. Some argue the Product Owner increases project safety. I see the point, and it’s worth considering.
• Scrum sprints are often 2-4 weeks, while XP iterations are often 1-2 weeks. True, but this difference is fading as Scrum sprints get shorter. I’ve always recommended one-week iterations.
• Scrum doesn’t contain specific software development practices, while XP does. Big difference, and that’s what makes XP more useful for software development, in my opinion.
• Scrum is rigid about story order within a sprint, while XP is focused on getting them all done. I’ve actually seen both types of work with XP, so I see the rigidity of Scrum as an unnecessary constraint. If the business says, “Do feature X before feature Y,” that’s fine for an XP team.

This description of how XP and Scrum relate is pretty good:

Scrum helps XP scale. XP helps Scrum actually work for doing software development. And Scrum can be easier to sell without that pesky “extreme” in the name.

The state of the world right now is that most companies calling themselves Agile officially use Scrum. Most Agile companies doing software development use some combination of Scrum and XP. One size doesn’t fit all. Scrum and XP together should provide plenty of fodder.