3 books that should be in every Scrum Master’s library

The Scrum Field Guide, Mitch Lacey.
Although it’s subtitled “Practical Advice for Your First Year,” Mitch Lacey has loaded his book with so much good advice that even veteran Scrum Masters will find themselves reaching for it from time to time, especially when creating new teams or joining a new organization.

Succeeding with Agile, Mike Cohn.
Another excellent resource for Scrum Masters introducing Scrum to a new organization, including lots of advice on how to start from scratch in companies that have never been Agile.

Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland
Jeff Sutherland helped create Scrum, and his recent book explains not just what Scrum is and how it works, but how and why it was designed the way it was. Any Scrum Master who has been stumped by questions about why a Scrum ceremony or artifact is important will find the answer here.

Scrum and Quality

As a Scrum Master at my last job, I often interviewed developer candidates to judge their experience with and appreciation for Scrum. Almost all had some experience with it, and opinions were mixed. Many were non-committal. Others rhapsodized about it. And one told me she hated Scrum, because “It’s a waste of time.”

Of all the complaints I’d heard about Scrum, this was a first. Scrum a waste of time? I asked her to elaborate.

“You have a two week Sprint, and deliver the code, and then you wait around doing nothing for two weeks while QA tests it and tells you whether it was accepted or not.”

I assured her that what she described was not good Scrum practice. The Scrum Guide states that, “A new Sprint starts immediately after the conclusion of the previous Sprint.” She didn’t see how that was possible. How, she wanted to know, could code be considered complete before QA had blessed it? How does Quality Assurance fit into the Scrum development cycle?

“Scrum recognizes no titles for Development Team members other than Developer,” states the Scrum Guide, and Scrum also does not recognize sub-teams. The team should be cross-functional, and can accomplish its work without relying on people who aren’t part of the team. Does that mean that a Scrum can’t have testers? Of course not. Scrum recognizes that “Individual Development team members may have specialized skills and areas of focus,” including testing. It just means that testers have to be fully part of the development team, and code should be tested throughout the development process, not at the end of a project. What this woman had endured wasn’t Scrum—it was miniature Waterfall with a two week development phase. No wonder she was turned off by it.