As already mentioned, Scrum is a framework for how to manage work. It might be incomplete and neither does it solve the problems for you nor does it tell you how to write your code. Scrum only gives guidance on how to solve problems.
Scrum is for you when planning and implementing new features or releasing your product takes longer than it should. Also when you see a decline in quality, customer trust and relationship, the morale of the team or amount of work done.
Scrum doesn’t use the term project. It uses the term product because the goal is to produce shippable products with every iteration (Sprint). It helps the organization to have a transparent progress (Burndown Chart). There also must be a pre-defined criterion for being done (Definition of Done). Scrum helps to adapt your process from sprint to sprint (Retrospective). With Scrum, feature after feature gets implemented. This means that only what is needed to build the needed feature will be implemented. For example, only a small piece of the data layer (instead of building the whole layer at once) will be implemented.
I will explain all the keywords in the braces, in the next parts.
Implementing Scrum in an organization can be hard and might take a long time. Usually, a company has, depending on its size, several levels of management. Every manager gives the employees below him tasks to do. Tasks like fix this bug or implement this feature. However, the idea of Scrum is that the team is self-managing and outsiders only provide help to the team. This means that suddenly these managers have to serve the team and provide help and support. Ideally, a company has high performing, self-managed teams and the management can focus on the strategic direction of the company.
Self-organizing means that the team manages itself without help or interference from outside. The team decides what work will be done in a sprint and decides how to implement it. The role of the external management is to see the bigger picture and long-term goals and to remove impediments to the team’s success. This is the key to create a high performing team.
If the team takes the ownership of the product, the team feels more responsible for the outcome and therefore is more committed to it. This leads into trying harder to improve the quality. If the team does not support the idea of Scrum, it won’t succeed. A high performing team sees the success as the reward of their hard work. Every team member should reflect on themselves and try to improve their own performance at every sprint. The result of a high performing team is a finished superior product at the end of every sprint.
Start small: do fewer products, less at once, less complex in the beginning
Think big, start small: a big bang introduction to Scrum will lead into failure. Start small with a pilot project. Take what you learned in this project and take it further within the organization.
Explore and adopt: learn the system within which you operate and then adopt.
One team one goal: if every team member has the same goal, you will achieve better results
Focus on value: focus on what’s the most valuable feature for the customer at the current time.
Empower teams: the team has the permission to make mistakes. Mistakes are the best source of growth and learning.
Lead by example: the organizational leader must lead by acknowledging the agile process by accepting that the team is self-managing and giving it the freedom it needs. Don’t do it as shown in the following comic 😉
Collaborate: Leaders must work not only with the Scrum teams but also with the other leaders within a company.
At the beginning, do Scrum exactly as the Scrum Guide suggests. After you are used to the process, try to experiment and start adapting it, so that it fits your team better. Reflect on the changes. If they were good, keep them. If they didn’t improve anything or even made you less productive, revert them.
Previous: Scrum Part 1 – Welcome to the future