Understanding Scrum - an introduction to the agile framework

Scrum is one of the best-known frameworks for agile project management and is particularly popular in software development. Unlike a method, Scrum as a framework provides a loose structure that leaves room for the use of tools. This is particularly advantageous when the project goal is not well defined, and adjustments are required during the process. However, the implementation and realisation of the framework within the structures of the company takes time, as the team and also the management have to get used to the new rules of the game. Over time, however, those involved develop and become more adept at using the Scrum framework. But what makes Scrum different and why is it a framework and not a method?

A method provides a set of principles, tools and practices to guide processes to achieve a goal. They are predefined steps that must be performed in this way. It is therefore a systematic solution that has its limits in terms of flexibility. So, if you have a project where few changes are expected, a method is probably the better choice. A framework, on the other hand, has a loose, incomplete structure that leaves a lot of room for other tools and practices. It has to be adapted to individual problems and serves only as a basic framework. 
And this is exactly how Scrum behaves: as a framework. It is incomplete and only specifies the parts that are absolutely necessary for the implementation of the project. No strict specifications are made, because the rules are there to guide the team. In order to follow this loose structure, there are three concepts - the so-called pillars - that give Scrum stability: transparency, inspection and adaptation.

Open communication and knowledge sharing creates transparency in the team so that the process is visible to all. Every decision in a project is made based on the state of the artefacts, and if these are not transparent, wrong decisions can be made. These can reduce the quality of the project and increase the risk to its success. Finally, transparency also allows the results to be inspected, as they are disclosed. 
By regularly inspecting the process documents, it is possible to check whether the process and the way of working are at all goal-oriented. Unwanted deviations and problems can be identified early on, and adjustments can be made through changes.
In Scrum it is important that the framework is implemented and if something is not acceptable, an adjustment must be made. This is the only way to minimise deviations as quickly as possible.

In Scrum there is no project manager, but three central roles that work together to create the best possible project. All participants have the goal of Scrum in mind: to produce a deliverable in each Sprint.

The Product Owner, acting either as a direct customer or as the customer's representative, is responsible for ensuring that the customer's requirements and ideas are incorporated into the current project. The Product Owner ensures that all activities and tasks are aligned with the intended Product Goal and that all functionalities defined in the Product Backlog are fulfilled.
As the manager of the Product Backlog, the Product Owner is responsible for ensuring that the product delivers value and is commercially successful. The Product Owner is responsible for creating and prioritising the items in the Product Backlog to ensure that the Product Goal is achieved. He works with the Developers to set the Sprint Goal, i.e. the goal for each Sprint. He is the central point of contact for the Developers and should always be easily available.

The Scrum Master is responsible for promoting and implementing Scrum in the company. This means that he is responsible for ensuring that all participants understand Scrum and that the instructions, rules and values are followed. It is important for the Scrum Master to know how the company is structured: Hierarchical? Is delegation possible? Is there already an understanding of agile working? Based on these answers, Scrum can be implemented and communicated.
The Scrum Master is also at the side of the Developers and supports them in self-management, so that they learn to make their own decisions. He should ensure that Scrum events run smoothly, that the schedule is adhered to and that the team can work productively.
If necessary, he can also help the Product Owner to formulate the Product Goal and to create and prioritise the Product Backlog Items. In this way he can help to implement Scrum and ensure that Scrum is effective.

The Developers come from different disciplines, so the team is cross-functional. This ensures that all skills are represented. The task of the team is to create the Sprint Backlog together with the Product Owner and to have created a usable Increment after each Sprint. This Increment must meet the "Definition of Done", which describes the state in which the Increment fulfils the desired quality. Only when an Increment meets the Definition of Done can it be considered usable.

Artifacts are process documents that give the Scrum Team an overview of the work and values. They include the Product Backlog, the Sprint Backlog and the Increment. Each Scrum Artifact has a Commitment that the Scrum Team agrees to and that creates transparency.

The Product Backlog is created at the beginning of the project and contains all the requirements for the product. The Product Goal is the Scrum Team's commitment to the Product Backlog. 
The individual entries are called Product Backlog Items, which are used to create the final product. They are ordered by importance and the top ones, which need to be described as precisely as possible, are implemented in the next Sprint. Typically, Product Backlog Items are formulated as User Stories. These give the user the opportunity to formulate wishes and requirements for the final product. User Stories that are easy to implement are prioritised. Those that are still too complex and extensive are prioritised as so-called Epics further down the Product Backlog. As the Product Backlog is updated, the entries are also re-evaluated. It is important to check whether some items are already obsolete and should be removed. 
If the items meet the Definition of Ready, i.e., if they are understood by the Developers and ready to be implemented in the next Sprint, and if they meet the corresponding Sprint Goal, they are transferred to the Sprint Backlog.

The User Stories to be implemented in the current Sprint are recorded in the Sprint Backlog. During a Sprint they are processed to achieve the Sprint Goal defined in the Sprint Planning Meeting. The Sprint Goal represents the commitment for the Sprint Backlog. 
The User Stories in the Sprint Backlog should also be prioritised so that the Developers know what to work on first. At the same time, tasks should be formulated to implement the User Stories. In addition, it should always be recorded what is currently being worked on and what has already been completed. If it becomes apparent that a User Story is being worked on for too long, it is important to find out what the problem is and to take action.

An Increment is an essential step towards achieving the Product Goal and is the main goal of each Sprint. The end result should be a successfully tested and usable sub-product which, in combination with other Increments, forms the final product. To achieve this goal, it is essential to meet the Definition of Done. The Definition of Done serves as the Increment's commitment: Only work that meets the requirements of the Definition of Done can be considered a complete Increment.

In the Scrum framework there are five events that take place in a fixed order and are limited in time to increase efficiency. These are Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. The events refer to the particular Sprint and take place during that Sprint. So, a Sprint is like a "container" for all the other events. As soon as a Sprint ends, a new one begins, and each Sprint works towards the Sprint Goal to create an Increment that contributes to the final product. A Sprint should not last longer than four weeks, as this allows adjustments to be made more quickly and minimises the risk of a bug going undetected for too long.
During each Sprint, the actual development work, the Sprinting, takes place between the Sprint Planning Meeting and the Sprint Review Meeting. There is also a Daily Scrum Meeting every day.
In the Sprint Planning Meeting, which takes place before the Sprinting, the upcoming Sprint is planned. Items are selected from the Product Backlog that fit the Sprint Goal.
The Daily Scrum takes place every day at the same time and is a must for all participants. Here, the developers give a short update in a maximum of 15 minutes. What has been done, what is planned for today and what has disrupted the workflow? There should be a lively exchange between all Developers.
The Sprint Review takes place after the Sprint. Here the results are reviewed and possible adjustments for future Sprints are discussed. Acceptance of the Increments is also discussed, and the Product Owner can also test them and give his opinion openly, so that the Developers can improve them if necessary. This is to check that the Sprint Goal has been achieved and that progress has been made towards the Product Goal. If not, unfinished Product Backlog Items are put back into the Product Backlog. 
The Sprint Retrospective can take place immediately after the Sprint Review. Here the working methods are evaluated, and the Developers discuss possible productivity and process improvements. They ask themselves what can be done better in future Sprints.

When there is no proper workflow in place, there can be many challenges. In such situations, compromises are often unavoidable. However, it is important to always ask yourself whether these compromises could have a negative impact on the team's commitment. If this is the case, careful consideration should be given to alternative ways of dealing with the challenges effectively.

Resistance to the introduction of Scrum can often arise if the organisation is inconsistent and offers few incentives. To avoid this, it is important to address people's concerns and fears so that they feel noticed and valued. A good way to overcome resistance is to introduce the best team to Scrum first. The success of the best team, even if it is a bit bumpy at first, can spread motivation to the other teams and reduce scepticism.
It is important to give people time, lots of help and support. Coaching and training can help to train the team itself, but also how to use Scrum.
Daily Scrums can create a feeling of control, so it should be shown what freedom it gives. Eventually the team works completely independently, supporting each other and achieving the goal.

If it is not clear in the team who is responsible for what, it can quickly lead to delays or even project failure. Therefore, the roles must be clearly defined from the beginning and uncertainties must be cleared up quickly. This requires the team to work together. The Scrum Master is particularly important. He has the task of implementing Scrum in the team and thus with the Developers. If he notices that the members are not clear about their tasks, he must intervene and, if necessary, hold workshops so that the members realise what is important and are clear about their role in Scrum.

Cooperation and communication in the team depends, among other things, on the composition of the team. The team should have characteristics, knowledge and skills that complement each other. The wishes of future team members should be taken into account, as some of them may have worked together before and therefore know who works best with whom, even though the team will naturally only find its way together and get settled over time. Important qualities that team members should have are good and open communication, so that problems or help can be shared immediately; commitment, i.e. that team members are motivated to carry out their tasks; self-control, as they have to organise themselves; and loyalty and fairness. Even if the team members have some of these qualities, problems can arise. This is where the Scrum Master comes in, helping to build the team by resolving conflicts or establishing a reasonable culture of conflict. This is where the openness and communication skills of the team members are of great benefit.
One option available to the Scrum Master is team building according to Tuckman. This includes team building workshops in which formal, i.e. work-related, but also personal issues are discussed. If there are any conflicts from previous projects, these can also be discussed and, ideally, resolved. In the next phases, the members slowly get to know each other and organise themselves. Over time, everyone knows what their tasks are and the Scrum Master can take care of other things. 
In general, it is important to keep the turnover as low as possible to keep the team at a good level.

The Product Owner decides which Product Backlog Items will be implemented first. Although the Product Owner has the customer's wishes in mind, it is not always easy to prioritise the items accordingly. This is where the Kano model can help. This graphically depicts the relationship between customer satisfaction and the quality feature implemented. Customer satisfaction can vary between low and high, quality between not met and met. There are three different features that are of particular importance: Basic attributes are taken for granted by the customer and are therefore self-evident. However, they do not make the customer more satisfied if they are present, but are only noticeable if they are missing, because the customer is then dissatisfied. Performance attributes are actively demanded and can be discovered by observing the market. They make the customer satisfied when they are present and dissatisfied when they are absent. Attractive attributes are not taken for granted and are not actively demanded. They do not make the customer dissatisfied if they are not present, but disproportionately satisfied if they are. This is one way of finding out which features should be implemented first. If you can differentiate yourself from the rest of the market with an exciting feature, it is sometimes worth implementing it first.

Scrum is particularly well suited to projects without a fixed goal or timeframe, as the project can be delivered in short, agile Sprints by a team working independently. However, the freedom of the team brings with it many uncertainties - both for the team, which has to get used to the approach, and for the client, who does not know exactly when the project will be completed and what the budget will be. It is particularly important that the Scrum Master keeps an eye on everyone and pulls them in the same direction. As the project progresses, more and more solutions will emerge from the challenges, and you will know when the framework has reached its limits and how to proceed.

Would you like to learn more? Then we recommend our Certified Junior Agile Project Manager (IAPM) web-learning platform.