As a software developer you are certainly aware of Scrum. You may have already used Scrum or heard about it only marginally. With this article I would like to give you an overview of what Scrum is and how you can apply this methodology. Plus: You can also use many of the principles even for working on your side projects alone or in a small group.
Scrum is probably the best known process model of agile software development. It is a collection of definitions and tools for managing projects. Scrum is not a rigid structure, but a flexible toolbox. A scrum project team consists of three parties: the product owner, who determines what is to be developed in the next sprint, i.e. the next iteration, the development team itself, who is responsible for the implementation and presentation of the results, and the Scrum Master, who guarantees the smooth running of the project. Scrum is designed for small, self-organized teams.
As already mentioned, the project implementation according to Scrum consists of several iterations, so-called sprints. A sprint typically lasts between one and four weeks and is used to prioritize selected user stories (formulated system requirements formulated from the user’s perspective) from the product backlog (all requirements for the project), transfer a selection of these into the sprint backlog (collection of requirements for processing in the current sprint) and implement them.
This prioritization and selection of requirements is called Sprint Planning. Although the requirements are set by the product owner, they are agreed with the team during the planning phase. This should ensure that the planned requirements are also realistic and feasible.
During the sprint the Daily Scrum takes place daily, a short meeting to discuss the current status and to clarify possible problems.
After a sprint has been completed, the sprint review takes place in which the team, together with the product owner, validates the various requirements and checks their fulfillment. This is followed by the Sprint Retrospective, in which the Scrum team discusses the cooperation with the Scrum Master and defines suggestions for improvement. The result of the sprint is delivered as an “increment” and the process starts again.
To summarize the most important terms in a nutshell:
- Scrum is a collection of agile software development methods for project planning and implementation
- The product owner defines the goals of the project and validates their achievement
- User Stories are the requirements described by the product owner, which are defined from the customer’s point of view
- The Scrum Master is a member of the team, which deals with the elimination of problems and thus enables the team to work with the best possible efficiency.
- The product backlog contains a collection of all project requirements
- The Sprint Backlog contains a selection of these requirements that are to be implemented in the current sprint. Prioritization and selection is made by the product owner, the team agrees to the selection
- Daily Scrum is the daily briefing of the team to discuss possible problems and obstacles.
- Sprint planning is the planning of the sprint before its execution, which usually takes a complete day (so much for “Agile software development does without extensive planning”)
- Sprint Review is the final discussion and presentation of results after a sprint with the product owner
- The Sprint Retrospective takes place after the Sprint Review and serves as an agreement within the team regarding points for improvement
- An increment is the result of a sprint, which is part of the project result, i.e. the product
So much for the rough plan. But what does Scrum have to offer? And why should I use Scrum and not another agile development methodology? First of all: Most teams do not work strictly according to a specific agile methodology such as Scrum or Kanban, but roughly follow one and adapt it to the individual needs. So if you choose to use Scrum, that doesn’t mean you can’t make customizations or add your own tools.
In general, working according to agile principles does not always make sense. The resulting self-responsible way of working does not suit every team and does not make sense for all tasks. Nevertheless, there are also many scenarios where the application of the appropriate methodology can make sense.
There are some disadvantages of agile methodology, which I would now like to discuss. Agile methods require a strong involvement of the customer. The product owner is usually an employee of the customer who is very familiar with the project. However, if the partner company is not or only little familiar with agile methods, it is often not easy to convey to the customer why he should spend a not inconsiderable amount of his employee’s time on the project. It is very important to give the customer an understanding of the procedure and to actively involve him.
It is also essential to understand the basics and use agile methods, not only the convenient ones, but also those that may seem annoying in the beginning. Another point is the culture of intolerance to mistakes often found in larger, older farms. Mistakes are important because you learn from them and thus improve. These errors must be communicated in a team and possible solutions discussed. If members are afraid to express their concerns and problems, a Scrum project will most likely fail.
Teams that are new to this approach may also be unsure about the flat hierarchies and the apparent lack of responsibilities. Here it can help to integrate an experienced Scrum-Master into the team.
Scrum does not define any concrete recommendations for action, but only principles and methods that can be applied. The exact selection and structure is then left to the team, which is certainly also an obstacle in initial contacts with agile software developers.
Nevertheless, there are some advantages that Scrum offers compared to classical methods: The rules are quick and easy to learn. To use Scrum in a team, no extensive training is required, the principles are easy to learn and can be introduced quickly. The communication channels are short and flexible, which means that changes can be reacted to quickly and problems can be contained quickly.
The high level of transparency due to the high degree of communication and the continuous improvement process ensures that problems are dealt with quickly and thus enables the team to be highly efficient.
Résumé
Finally, the choice of methodology is not a general one, but depends on many different conditions, both for the team and the project. And in terms of agile software development, there is not only Scrum. Hopefully this article gave you a rough overview of the approach with Scrum. In a follow-up post I will describe alternative concepts so that you can form your own picture and decide what is best for your project. However, in my experience I prefer Scrum over for example Kanban when working with a larger team. For personal and smaller projects, I usually use Kanban. But that’s the topic for the next post. Stay tuned!