Scrum: modern and flexible agile project management

When a team starts a project, they don’t just dive straight into work – most projects require project or product management first. The agile approach is common practice in many companies today. The focus is on flexible working methods, incremental developments and transparent processes. In the sphere of agile project management, the term “Scrum” is becoming increasingly well known. Originally intended for software development, the model has also become well known in many other industries. In this article, we explain what exactly this buzzword entails.

Scrum dates back as far as the 80s, but it has been around in its present form since 1995. It was then that Ken Schwaber and Jeff Sutherland teamed up to publish a paper, the “Scrum Guide.” They wanted to make work more productive and at the same time introduce as few regulations as possible to avoid limiting creativity.

To make this possible, Scrum defined a framework that could easily be applied to various situations. This is done with the aim of continuously improving both the way we work and the product or service itself. Parts of the framework are categorized into roles, events, artefacts, and rules. Within these limits, Scrum teams should be able to achieve results as efficiently as possible, providing the customer with the best possible product. Customers, clients, and users play an important role at Scrum: the development of the product is specifically tailored to their requirements.

With regards to working with Scrum, there are two keywords that play a very important role:

• Iterative: With Scrum, a product is constantly evolving and performing repeatedly. The process is cyclical: it starts with planning and development, then testing and evaluating, and finally it comes back to the planning phase. So, the Scrum methodology is not only associated with the initial production, but also with future developments.
• Incremental: Scrum is based on the idea that a product is created step-by-step. Each step represents intermediate goals. This method is a departure from a way of working toward one single goal at the end of development. To achieve greater flexibility, large projects are divided into several smaller ones.

If you combine the two approaches described above, the result is an iterative-incremental approach, which implies both a constant, gradual development, and step-by-step checks and iterations. On the one hand, this approach makes the process more transparent and efficient, since checks are planned more frequently, and on the other hand, the quality of the product is also improved, since its functionality is continuously tested.

Scrum was originally intended for agile software development; developers rely on Agile Scrum to continously improve their work on programs. But it is also a suitable model for other products – for example, with the production of hardware. At the end of a Scrum project, it’s not completely necessary to have a physical product – every result-oriented project can benefit from the Scrum methodology. For example, the model is also successfully used for the organization of marketing teams or administrative bodies, and to develop services.

The starting point of Scrum is always with small teams, although “small” is a relative term. For larger work groups, however, the flexible model is less suitable, but there is always the option of dividing these up into smaller groups. Scrum is also ideal for networking teams. The framework places great emphasis on teamwork: within a Scrum team, each individual member should bring their own skillset to the table.

Scrum is not a fixed method or concrete working technique, but rather a framework that offers the teams points of reference for their work process. There are certain roles, events, and artefacts within this framework.

Within a Scrum team, there are three fixed roles: the team, the product owner, and the Scrummaster. The team are the actual developers of the product. The group is set up in such a way that it can organize itself and determine how they want to reach an agreed goal. At Scrum, there are no hierarchies within a team. While it goes without saying that each employee has his or her own area of responsibility within the team, everyone has to account for the product in the final review.

The size of the team is fixed: you should be set up so that you can act quickly and flexibly, but also remain efficient. Aim for a medium-sized team: not too big and not too small. Schwaber and Sutherland recommend between three and nine members per team.

The product owner is responsible for the quality of a product and the work. This person takes on a control function. The product owner organizes a product backlog, a list that defines the requirements for the project (you can find out more about product backlog in the “Scrum artefacts” section below. One of the tasks of the product owner is to put the goals in order and document them. The product owner plays a deciding role: while the teams themselves set out how they achieve the goals established in the backlog, establishing the goals is done at the product owner’s discretion. To ensure maximum productivity, the team must trust the decisions of the product owner. Nevertheless, there is no leader with Scrum: both the product owner and the team have different focus areas and are decisive in their own area. Just as the team does not question the backlog, the product owner does not interfere in the development process.

In comparison to the other roles, the Scrum master functions as a sort of mediator. They are responsible for integrating and enforcing the workflow. That means that this role is responsible for the overall organization of the Scrum team. This person also organizes and moderates meetings. Additionally, the Scrum master assists both the team and the product owner, but they never interfere in the actual development process. Their function is merely to simplify the work processes for all employees involved in production, while increasing productivity and creativity.

As a contact person, the Scrum master ensures that everyone involved understands the processes correctly. They give tips regarding the backlog or the organization of the team, and try to settle any issues that may arise. The Scrum master has a similar function to a coach. It is essential for this person to be very familiar with the framework. It’s even possible to get certified as a Scrum master; several certification bodies offer corresponding training courses. Both the Scrum Alliance and Scrum.org were founded by Ken Schwaber, and offer the “Certified Scrum Master” and the “Professional Scrum Master” certificates.

If you organize workflows according to the Scrum principle, there are certain events that occur regularly. Since Scrum is an iterative process, the work is carried out in repetitive cycles. Each event takes place again with each repetition. The frequency of Scrum events means that there are hardly ever any unscheduled meetings. All events have a fixed timeframe.

The cycle itself is known as a “sprint.” This describes the development phase. At the end of a sprint, the development team delivers a finished product increment. This means, that the development must have led to a product that can potentially be delivered. Each sprint has a clear mission that is completed at the end of a project. The timeframe for a sprint is determined in advance, but should not exceed 30 days. When determining the timespan, the following factors should be taken into account: a sprint can’t be extended or shortened, and the other project sprints should have the same duration.

Sprints are deliberately kept short so that the formulation of goals is not too complicated. The short duration also ensures that progress can be reviewed at the end of each month. Only in a few exceptional cases may a product owner cancel a sprint – and only the product owner. It’s possible to do so if, for example, the company’s goal has changed and the original goal no longer needs to be achieved. In principle, however, sprints shouldn’t be cancelled, as this reduces productivity.

A sprint begins with sprint planning. All roles within a Scrum team should be involved in this phase. During a meeting, participants discuss the upcoming product increment – what should each increment entail and how should the goal be achieved. The meeting should last no more than eight hours. The starting point for the planning phase should be the product backlog. The development team and the product owner sit down together and agree on which goals should be achieved in the coming month. The development team then discusses how the tasks should be completed. At the end of the meeting, the developers should discuss the plan together with the product owner and the Scrum master.

Within the sprint, a Scrum takes place every day. This occurs at the same time and the same place each day, to organize the company’s effort. During this 15-minute meeting, the developer team goes through the outstanding tasks for the day and the progress made the previous day. The developers also assess the general progress of the project, including the progress made with backlog entries. The daily comparison ensures that all parties involved remain focused on their goals, which ultimately results in increased productivity.

The Scrum master is responsible for ensuring that the daily Scrum takes place, while the developers are responsible themselves for the progress of the meetings. They decide which items are discussed in each meeting. As long as the content is about achieving the sprint goal and the 15 minutes are not exceeded, the Scrum master does not interfere, and ensures that no one else interferes the developers during the daily Scrum.

When the sprint has come to an end, a sprint review follows. This process analyzes the product increment. The results are evaluated together with people that aren’t part of the Scrum team but still have an interest in the product, such as company owners or customers (collectively called stakeholders at Scrum). Additionally, the work processes are discussed and the various problems or challenges that arose during development are shared. This has an impact on the further planning, because the product owner uses the opportunity to respond to the progress of the backlog. The findings of the sprint influence the outlook for future performance.

The respective market situation also has an influence on the backlog. Particularly with long-term projects, priorities can shift and budgets can change. Such topics will also be considered in the sprint review and will change the future approach. For a month-long sprint, no more than four hours are required for the review.

The sprint review is followed by another review, the sprint retrospective. The entire Scrum team – including the product owner and scrum master, but not the stakeholders – sit together for a feedback round that should last no longer than three hours. While the review focuses primarily on the product and the progress of the product, the retrospective is mostly about teamwork. The aim of the second review is to improve the team’s ability to work together and to smoothen out any internal problems. As soon as a sprint ends, the planning phase of the next one begins.

Items that play an important role within Scrum are called artefacts. This includes the likes of product backlogs, sprint backlogs, and the completed increments.

Transparency is an important element of Scrum. Everyone involved should have easy access to all information available. It is for this reason that extra care is taken to ensure all Scrum artefacts are clear and easy to understand. The product owner is responsible for the product backlog. The backlog is a sorted list of all elements that are crucial for the product. This includes the functionality of the product and bug fixes or improvements.

The work for the product backlog is ongoing. The list is managed in a dynamic way – new insights are incorporated at all times, entries are strongly distinguished, new tasks are added, and the sorting is adapted. At the beginning, the product owner is usually assisted by the Scrum master. The master knows from experience how to formulate the document to be as transparent and effective as is required. Entries should generally be oriented towards the customer. In addition to a description of the required feature, the document also contains a note on the workload and an entry on the priority level.

The sprint backlog is generated from the product backlog. This contains all entries of the product catalogue selected while planning for the upcoming sprint. It shows all steps leading up to the current sprint. During the daily scrum, the progress will be judged by the sprint backlog. This list can also be updated during the sprint to meet the team’s needs and challenges. Now it is also the responsibility of the developers to make changes in the sprint backlog. Neither the product owner nor the Scrum master may change the list.

At the end of a sprint, the developers present the increment, i.e. the result of the development phase. The increment should include all sprint backlog entries and all increments of previous sprints. It should always be directly deliverable at any required moment. It should be ready for use, even if there are no actual plans to deliver the product increment. In the sprint review, the team introduces the increment and the product owner and stakeholders can review the results.

Scrum offers a number of advantages compared to other agile methods, as well as traditional project management methods. These are mostly due to the step-by-step approach and the small number of rules that may limit the team:

• Communication: Good project management can only function when all team participants are on the same level. Scrum places a lot of emphasis on communication in the team. There is therefore a relatively large number of events. The daily meeting at the beginning of the day makes sure that no developer works past the others. Any problems with the team are addressed in the final retrospective.
  
  
• Flexibility: Scrum is used for relatively short sprints. Since there is a maximum of one month between the two planning meetings, the project can also be changed at short notice and adapted to any new requirements.
  
  
• Transparency: Both the constant communication of all team members and the Scrum artefact system ensure high transparency. Backlogs are formulated in such a way that everyone can easily find their way around them and can find any necessary information.
  
  
• Quality control: The iterative principle of Scrum ensures continuous control of the product. Bug fixes are just as much a part of the product backlog as the further developments. In the sprint review, the development team also presents a finished increment. The product owner and stakeholders have the opportunity to convince themselves of the quality. This makes it possible to respond much faster to developmental errors than to find a faulty function at the very end of a project.
  
  
• Creativity: Scrum is based on the self-organization of the team. Instead of dictating the working processes from top down, the developers start working with their own ideas first. Since the framework of Scrum is comparatively open and has few rules, individual team members are more encouraged to bring ideas to the table.
  
  
• Effectiveness: Compared to classic project management, Scrum requires much less documentation. The focus should be on a functioning product and not on complete documentation that costs both time and resources. Instead, the team can concentrate fully on the development work during the sprint and carry it out as it sees fit.

Despite the obvious advantages, Scrum is not suited to all businesses. Due to the disadvantages explained below, it is not the ideal solution for many companies:

• Lack of overview: What can be a big advantage for one team, can be a major disadvantage for another. The incremental planning can sometimes result in a team losing sight of the bigger picture in a complex project.
  
  
• Complex communication: Scrum events are all pre-arranged, and for many teams and projects, such a high level of communication is unnecessary. In such cases, the daily Scrum may hinder productivity rather than encourage it. Too much time is spent on organization and communication instead of working on the actual product.
  
  
• Uncertainty regarding planning and responsibility: Scrum ensures that teams organize themselves. This can be beneficial, but in some areas and industries, such a flat hierarchy can also lead to confusion in planning and ambiguity regarding who is responsible for what.
  
  
• Not integrable: Scrum can only be integrated into some companies with significant adjustments to the structure of the company. In such cases, the question arises, whether one loses more effectiveness than one gains through Scrum.

Whether or not Scrum is suitable for your business, ultimately, you’ll need to decide for yourself. Consider whether the flat hierarchies and regular communication synonymous with Scrum will increase productivity and improve job and product quality in your operations.