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.

In Clean Code, Martin doesn’t just name the best practices we should all be following. He explains the reasoning behind each one and gives names to the concepts. Just as the idea of software design patterns revolutionized the way we think and talk about software architecture, Martin’s exploration of day-to-day coding habits gives us a smarter way to think and talk about that.

Case in point: Clean Code kicks off with the practice of giving your objects meaningful names. One aspect of this is that good names do not require anyone who might read your code in the future to have to perform any “mental mappings.” Here’s an example of this that I came across just the other day.

var ld = new LoginData();

Look carefully, that’s a lower-case L. At first glance, it looks like a capital I, as in “ID,” as in “identifier.” I don’t know how long I spent confused about how a class constructor could be returning an identifier when reading through this code for first time. Maybe ten or fifteen seconds? Time in which I was completely distracted from understanding the rest of the code, having pushed that problem onto the stack, as it were, in order to first solve this mini-problem.

Even without the I vs. L confusion, using an abbreviated variable name meant that whenever I came across it, I had to keep reminding myself that it stood for an instance of LoginData. That may not seem like a big deal, but we humans only have so much stack space before we run out of short-term memory. When a program is full of one- and two-letter variable names that must be continually translated mentally, it leaves no room for thinking about the actual problem that the program is trying to solve.

All of this could have been avoided if the name was spelled out to begin with, so I changed it (using the automated rename refactoring tool in my IDE):

var loginData = new LoginData();

“One difference between a smart programmer and a professional programmer is that the professional programmer understands that clarity is king. Professionals use their powers for good and write code that others can understand.” ~ Robert (Uncle Bob) Martin

Martin could have just said, “don’t use abbreviations in variables names, because you’ll make the reader translate it in his head every time he reads it,” and that would have been terrific advice alone. But what he really gives you is a deep understanding of the key principles involved, so that you won’t need to memorize a bunch of arbitrary coding standards in order to write cleaner code. Instead, you’ll be armed with a few simple, understandable principles to guide you, with clean code being the natural outcome.

Clean Code is a must-read for everyone in the software profession — from college freshmen on up to CTOs — especially anyone who finds himself out of work in this economy (or worried about the possibility). Learning to write clean code, and thus to write more valuable code, is probably the single most effective thing you can do for yourself. Programmers are expensive resources. The work we produce is costly. It’s up to us to treat it with the respect it deserves, to try and make it as valuable as possible, and to maintain that value as long as possible.

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.

1. Maintain a written glossary of domain terminology. It’s amazing how often the developers and the customers think they’re talking the same language, but they’re not. Misunderstandings like this are a common source of “assumption errors,” which are a leading cause of wasted effort.

2. Maintain a written “Scope In/Out” sheet. Be explicit about what’s in scope for this project (for this phase of the project) and what’s out of scope.  Jealously guard the scope.  Do it in writing.

3. Make sure everybody who generates and consumes time estimate numbers looks at them the same way. Don’t let an optimistic estimate be taken for realistic or pessimistic one. Beware of using +/- ranges. They are meaningless when talking about software development. Much better is to use degrees of resolution (No confidence/WAG -> Low confidence -> Med confidence -> High confidence). Do a work-breakdown analysis on any large task, recursively, until it is the sum of 2-day or smaller chunks. Any estimate that’s longer than 2-days without a breakdown to back it up cannot be trusted.

4. Create written Use-Cases/Scenarios to communicate user-interaction requirements — especially when it comes to describing exceptions to the rule (things like handling the sale of alcohol or tobacco, processing returned merchandise that’s saleable vs. damaged, the difference between 50% off vs. buy-one-get-one-free, etc.). The Use Case is an amazingly powerful tool for eliciting requirements from a non-technical customer. To start, you have to write the scenarios yourself and get the customers to sign-off, but once they see where you’re going with them, they’ll start writing their own in the first place.

5. Hold daily scrums (stand-up meetings). Each team member should cover three things: (1) What they did since the previous stand-up meeting, (2) What they plan to do before the next stand-up meeting, (3) Any perceived impediments to getting it done.