Foreword
by Ron Jeffries
When Kenny asked me to write a foreword for Essential Scrum, I was thinking, “This will be quick and easy; it must be a short book going straight to a simple description of what Scrum is.” I knew Kenny’s work, so I knew it would be a good read, and short, too. What could be better!
Imagine my surprise and delight when I found that this book covers just about everything you’ll need to know about Scrum, on the first day or years into your use of Scrum. And Kenny doesn’t stop there. He starts with the central ideas, including the agile principles that underlie all the agile methods, and a quick view of the Scrum framework. Then he drills in, deeper and deeper. It’s still a good read, and it’s quite comprehensive as well.
Kenny covers planning in good detail, looking at requirements, stories, the backlog, estimation, velocity. Then he takes us deeper into the principles and helps us deal with all the levels of planning and all the time horizons. He describes how sprints are planned, executed, reviewed, and improved. And throughout, he gives us more than the basics, highlighting key issues that you may encounter as you go along.
My own focus in Scrum and agile is on the necessary developer skills to ensure that teams can deliver real, running, business-focused software, sprint after sprint. Kenny helps us understand how to use ideas like velocity and technical debt safely and well. Both of these are critical topics, and I commend them to your attention.
Velocity tells us how much the team is delivering over time. We can use it to get a sense of how much we’re getting done and whether we’re improving. Kenny warns us, however, that using velocity as a performance measure is damaging to our business results, and he helps us understand why.
Technical debt has become a very broad term, referring to almost everything that could go wrong in the code. Kenny helps us tease apart all the various meanings and helps us understand why we care about these seemingly technical details. In particular, I like his description of how putting a team under pressure will inevitably damage our prospects of getting a good product on time.
Scrum, like all agile methods, relies on an exploratory approach with rapid feedback. Kenny tells a story of his brief use of punch cards, and it reminded me of my earliest experience with computing, many years before Kenny saw his first punch card.
As a college student, I was lucky enough to get a job as a sort of intern at Strategic Air Command headquarters in Omaha. In those days all computing was on cards. My cards got sent down several floors underground at SAC HQ and run on the computer that would run the war, if we ever had one. I was lucky to get one or two runs a day.
As soon as my security clearance came through, I would go down to the computer room in the middle of the night. I would sweet-talk Sergeant Whittaker into letting me run my own programs, sitting at the console of the machine—yes, the machine whose main job was to launch a nuclear attack. Rest easy, though: The red button was not in that room.
Working hands-on with the machine, I got ten times as much work done as when I had to wait for my cards to be taken down and my listings to be brought back up. Feedback came faster, I learned faster, and my programs worked sooner.
That’s what Scrum is about. Instead of waiting months or even years to find out what the programmers are doing, in Scrum we find out every couple of weeks. A Scrum product owner with a really good team will be seeing actual features taking shape every few days!
And that is what Kenny’s book is about. If you’re new to Scrum, read it through from beginning to end. Then keep it nearby. If you’ve been doing Scrum for a while, scan it, then keep it nearby.
When you find yourself thinking about something that’s happening to your team, or wondering about different things to try, pick up this book and look around. Chances are you’ll find something of value.
—Ron Jeffries