Foreword by Ken Schwaber
I created Scrum to improve the way in which I and others develop software. Scrum has been refined over the last 27 years, mostly through the creation, publishing, and gentle refinement of the Scrum Guide. Jeff Sutherland (the coauthor of Scrum) and I posted Scrum, as precisely defined in the Scrum Guide, online so people can suggest improvements. Over the years, we have refined Scrum based on these comments, making Scrum easier to use and understand.
When I first used the phrase “Scrum Master,” many people became confused. Nobody was mastering Scrum; we were all learning how to use it and how to augment it with practices and tools so as to improve outcomes and to help team members use Scrum with proper values, practices, artifacts (“Done” Increments), and roles—all working together to achieve Scrum’s goals.
The Scrum Master’s job is to help the organization and the Scrum Team use Scrum properly to improve their ability to deliver value. The Scrum Master has to help the team members and people who are affected by Scrum (human resources, finance, etc.) understand how they can operate optimally. Anyone on the Scrum Team can improve their Scrum mastery; they can become better at using Scrum and empiricism to achieve better results, to deliver more value, in complex domains. Anyone can become more professional.
A professional is someone who works for money and follows the rules established for the profession. Professionals act and work according to standards, where they exist (e.g., adhering to the rules set forth in the Scrum Guide). They also embrace and embody a set of ethical principles established by their profession (e.g., the Scrum values of Focus, Commitment, Openness, Respect, and Courage).
Sometimes the Scrum professional may be torn between two alternatives. In these circumstances, the Agile Manifesto provides higher-level guidance:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Scrum professionals do not redefine Scrum itself or “tailor” it to their organizations; Scrum is Scrum. To create Increments of valuable Product and reach the desired outcomes, they do add supporting and ancillary practices, including DevOps, Kanban, and testing, reconciliation, and communication practices. Practices that distinguish Scrum from other approaches to complex work include the following:
The team organizes work in short cycles.
Management doesn’t interrupt the team during a work cycle.
The team reports to the client, not to the manager.
The team estimates how much time and effort that work will take.
The team decides how much work it can do in an iteration.
The team decides how to do the iteration’s work.
The team measures its own performance.
The team defines work goals before each cycle starts.
The team defines work and desired outcomes through a progressively refined description of outcomes (called the Product Backlog).
The team works to systematically and continuously improve and to remove impediments.
Our job as Scrum professionals is to continually improve our ability to use Scrum to deliver products and services that help customers achieve valuable outcomes. This book will help you to improve your ability to apply Scrum. Its authors share their experiences and advice, gathered from helping many clients and students learn and apply Scrum in their organizations. I hope that it helps you in your own professional journey.
Scrum on!
—Ken Schwaber, co-creator of Scrum and founder of Scrum.org