Schwaber’s first book, Agile Software Development with Scrum, is more of a reference book than a how-to. It describes what Scrum is, but not so much the nuances of how to use it. The second book includes a reference section in the back that pretty much recaps the first book. So, start there. If a pass through the reference section makes sense to you, then proceed directly with the second book. Otherwise, pick up the first book as well and use it to get up to speed.

If you are not yet up to speed on XP, the quintessential tome, Extreme Programming Explained: Embrace Change (2nd Edition) by Kent Beck, is still the best starting place. I’d recommend reading that before reading up on Scrum. As you do, just keep in mind that Scrum essentially replaces and expands upon the XP “planning game.” Don’t skip reading about the planning game. Just understand that if you have questions about how the planning game works in the real world, hold those questions until you get to Scrum.

It’s taking best practices to the extreme…

• Long iterations become short iterations with early experience
• Long, irregular meetings become frequent stand up meetings
• Back-end testing becomes unit testing
• Specification artifacts become stories and a full-time customer (proxy)
• Enforced deadlines become developer-derived estimates
• Code reviews become pair programming

The XP Values

• Communication
• Feedback
• Simplicity
• Courage

The Tenets of Extreme Programming & Refactoring

• Establish a guiding vision, or “metaphor,” and then design as you go, with no big, up-front design.
• Do the simplest thing that works, at first, and then refactor as needed.
• No “Spec Gen” (speculative generality). Rely on refactoring to add features only as they actually become required.
• No speculative performance tuning. Rely on refactoring to introduce performance tuning later.
• Code in small iterations and fast release cycles.
• Put unit and functional testing at the core of the project goal posts, not as an optional add-on. In fact, write the tests before you write the code to be tested. You cannot rely on refactoring without a complete baseline of unit tests.
• Do not refactor and add functionality at the same time. Alternate between them.
• Coding standards should have buy-in by all team members and call for the least amount of work possible.
• Work directly with an on-site customer and/or user and make them a part of the programming team.
• The customer determines the priorities, not the developers.
• Developers provide the estimates, not the customer.
• “Spikes” are written when preliminary research is required to provide a confident estimate.
• The entire development team has collective ownership of the entire project. It is not portioned-out code to individual experts.
• Program in pairs to assure quality and stay on track.
• Use stand-up meetings to stay on track.
• Stick to a 40-hour workweek, sleep well and lead a balanced, healthy lifestyle.

Getting Started

1. Kent Beck’s “Extreme Programming Explained” (second edition) is the seminal work in the field. It’s an easy read and it paints a good overall picture.
2. Martin Fowler’s “Refactoring: Improving the Design of Existing Code” is a must-read. The first 100 pages describes refactoring (and a bit about test-driven development). The remaining pages are a catalog of refactorings — essentially a cookbook of step-by-step recipes.
3. Robert Martin’s “Agile Software Development” has also been recommended as a good starting point, though it’s not primarily about XP.