Scrum Your Jira!: Your Waterfall Organization Transformed Into Agile Multidisciplinary Teams

This book challenges two illusions that can get in the way of your company’s road to being truly 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 key 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 in an elegant way. 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 whole product. Instead, management makes important decisions because the best people were moved out of the team into management roles. With Scrum, it is essential to have the team own the product. If this is not done, you will face a number of tricky issues.

One particular issue 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 a good 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 a number of 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 a number of 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.