My new boss wasn’t being a jerk, but it seemed like it at the time. We were writing new software for use in the company’s high-volume call centers. Instead of the 12 months I told him we’d probably need, he had agreed to give me 4 months. We wouldn’t necessarily start using the new software in 4 months, but from that point on, all my boss could give me was 30 days’ notice of a go-live date. After the first 4 months, I would have to keep the software within 30 days of releasable. My boss understood that not all functionality would be there after 4 months. He just wanted as much as he could get, as fast as he could get it. I needed to find a process that would let us do this. I scoured everything I could find on software development processes, which led me to Scrum and to Ken Schwaber’s early writings on it.

In the years since my first Scrum project, I have used Scrum on commercial products, software for internal use, consulting projects, projects with ISO 9001 requirements, and others. Each of these projects was unique, but what they had in common was urgency and criticality. Scrum excels on urgent projects that are critical to an organization. Scrum excels when requirements are unknown, unknowable, or changing. Scrum excels by helping teams excel.

In this book, Ken Schwaber correctly points out that Scrum is hard. It’s not hard because of the things you do; it’s hard because of the things you don’t do. If you’re a project manager, you might find some of your conventional tools missing. There are no Gantt charts in Scrum, there’s no time reporting, and you don’t assign tasks to programmers. Instead you’ll learn the few simple rules of Scrum and how to use its frequent inspect-and-adapt cycles to create more valuable software faster.

Ken was there at the beginning of Scrum. Ken, along with Jeff Sutherland, was the original creator of Scrum and has always been its most vocal proponent. In this book, we get to read about many of the Scrum projects Ken has participated in. Ken is a frequent and popular speaker at industry conferences, and if you’ve ever heard him speak, you know he doesn’t pull any punches. This book is the same way: Ken presents both the successes and the failures of past Scrum projects. His goal is to teach us how to make our projects successful, and so he presents examples we can emulate and counterexamples for us to avoid.

This book clearly reflects Ken’s experience mentoring Scrum Teams and teaching Certified ScrumMaster courses around the world. Through the many stories in this book, Ken shares with us dozens of the lessons he’s learned. This book is an excellent guide for anyone looking to improve how he or she delivers software, and I recommend it highly.