All books are like a story and this one is no different. This one starts with the origin of Scrum: rugby. Unlike football or soccer, in rugby, there is a strong team emphasis with few to no roles. This is what makes Scrum different from Waterfall. As they say, “It is not the players that make a team win, it is the team that make the players win.” Hiring only specialists and then shifting work from one department to the next is tiresome, especially in today’s knowledge-focused industries.
After the introduction, the idea of the “Our Scrum is Special” chapter was to take away the illusion that with Scrum, you could throw away all the basic project management approaches and invent your own Scrum. The path to implementing Scrum in your company is unique, yes, but your company most probably will face the same challenges as any other. Ultimately, you need to track what parts of Scrum you have implemented. Replace “we do Scrum” with “we are on the path of implementing Scrum.”
Having multidisciplinary teams is one big step toward that goal of having an Agile company. Sharing knowledge by working together as a team, removing production phases, and focusing on quick delivery can be achieved by transforming your departments into individual teams that can do everything related to their part of the feature or whole product.
This leads us to the tools: While the usual approach of using but a pen and paper is replaced by software tools, people tend to forget what Scrum is about. Purposefully not using certain features JIRA provides and using certain standards 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, that needs to be addressed. One example are the acceptance criteria and the Definition of Done. Here, there is often no clear decision made about how to integrate them into JIRA. So, they exist somewhere in the documentation, or implicitly in people’s heads. But with a plugin 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—Waterfall. The team is not trusted to deliver the whole product. Instead, important decisions are made in management because the best people were moved out of the team. With Scrum, it is once again important to have the team own the product. If this is not done, you face a number of issues.
One particular issue related to ownership is the sprint, its estimation, and the commitment to it. Not without reason was Scrum 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, they will consciously or subconsciously blame the people who meddled with it. Teaching the team to make smarter estimations is a good way to win over both sides and increase productivity.
All that said, and all work done, it is time for delivery, right? Too often, I see that people confuse Scrum sprints as 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 going on.
With the projects growing big, you will also need to add more people and teams to your project. Organizing them in JIRA can be tricky, but there are a number of ways the software can help you to accomplish the task.
Finally, there are a number of ideas of going through 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.
After the introduction, the idea of the “Our Scrum is Special” chapter was to take away the illusion that with Scrum, you could throw away all the basic project management approaches and invent your own Scrum. The path to implementing Scrum in your company is unique, yes, but your company most probably will face the same challenges as any other. Ultimately, you need to track what parts of Scrum you have implemented. Replace “we do Scrum” with “we are on the path of implementing Scrum.”
Having multidisciplinary teams is one big step toward that goal of having an Agile company. Sharing knowledge by working together as a team, removing production phases, and focusing on quick delivery can be achieved by transforming your departments into individual teams that can do everything related to their part of the feature or whole product.
This leads us to the tools: While the usual approach of using but a pen and paper is replaced by software tools, people tend to forget what Scrum is about. Purposefully not using certain features JIRA provides and using certain standards 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, that needs to be addressed. One example are the acceptance criteria and the Definition of Done. Here, there is often no clear decision made about how to integrate them into JIRA. So, they exist somewhere in the documentation, or implicitly in people’s heads. But with a plugin 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—Waterfall. The team is not trusted to deliver the whole product. Instead, important decisions are made in management because the best people were moved out of the team. With Scrum, it is once again important to have the team own the product. If this is not done, you face a number of issues.
One particular issue related to ownership is the sprint, its estimation, and the commitment to it. Not without reason was Scrum 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, they will consciously or subconsciously blame the people who meddled with it. Teaching the team to make smarter estimations is a good way to win over both sides and increase productivity.
All that said, and all work done, it is time for delivery, right? Too often, I see that people confuse Scrum sprints as 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 going on.
With the projects growing big, you will also need to add more people and teams to your project. Organizing them in JIRA can be tricky, but there are a number of ways the software can help you to accomplish the task.
Finally, there are a number of ideas of going through 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.
