This book challenges two illusions that can get in the way of your company’s road to being genuinely Agile: first, that your Scrum is “special,” and second, that you can hide behind project management software. JIRA is powerful—and this book will show you how to use it more effectively—but it makes it easy to forget that the first idea of Agile is: Individuals and interactions over processes and tools.

This book begins with the origin of Scrum: rugby.

Unlike in football or soccer, in rugby, there is a strong team emphasis and few to no roles. This is what makes Scrum different from Waterfall, which is focused on hiring only specialists and then shifting work from one department to the next—a tiresome approach, especially in today’s knowledge-focused industries. Building multidisciplinary teams is a crucial element to achieving an Agile company. Sharing knowledge by working together as a team, removing production phases, and focusing on quick delivery can be achieved. The key is to transform your departments into individual teams that can do everything related to their part of a feature or product.

This leads us to the tools.

People tend to forget what Scrum is really about. Purposefully not using certain JIRA features to create new stories will help to remedy that situation. There is a great deal that JIRA does (and does not do), compared to the pen-and-paper approach. Two examples are the acceptance criteria and the definition of done. Here, there is often no clear decision made about how to integrate them into JIRA. They exist somewhere in the documentation, or implicitly in people’s heads. But with a plug-in and some workflow programming, we can automate the definition of done elegantly. All the information needed to complete a story in one place: great!

With the tools and numbers in order, the focus moves to the team.

Often, it is the last (or middle) chain of production. The team is not trusted to deliver the full product. Instead, management makes essential decisions because the best people were moved out of the team into management roles. With Scrum, it is vital to have the team own the product. If this is not done, you will face several tricky issues. One particular topic related to ownership is the sprint (its estimation, and the commitment to it). Not without reason, Scrum was changed a few years ago to replace “commitment” with “forecast.” Striking the right balance between the product owner and the team is crucial. If the team does not own the sprint in its totality, including deciding on its own how to complete it, the team will, consciously or unconsciously, blame the people who meddled with it. Leading the team to make smarter estimations is an excellent way to win over both sides and increase productivity.

All that said, and the work done, it is time for delivery, right?

Too often, I see that people confuse Scrum sprints with development sprints. Scrum is the business side, to check on you, to communicate with the client, to plan in chunks, etc. But delivery? That can be done at any time. If you ever encounter a team that delivers at the end of the sprint, you will see many Waterfall elements in play. As your projects grow, you will need to add more people and teams. Organizing them in JIRA can be tricky, but there are ways the software can help you to accomplish the task.

Finally, there are several ideas relating to your daily Scrum Master routine to help you to do your work better. From psychology to small productivity tips, big things are achieved in small steps.

Where does your team stand in terms of Agile? Are you making the most of Scrum? This book was written with an experienced Scrum Masters in mind. It trusts that you already know the basics, so the chapters will jump right into the day-to-day challenges, as well as the global idea of Agile organizations.