Change management

Perhaps you have already heard of Scrum and are wondering what exactly it is all about and whether it would make sense to use Scrum in your company?

We want to address these questions in this and the next article: From the definition and emergence of Scrum to the advantages and disadvantages that can arise when an organization introduces Scrum – we examine the topic of Scrum from all sides!

The Scrum Guide: What is Scrum?

Why Scrum?

Does this sound familiar to you?

At some point, Mr. M. realized that he didn’t feel like it anymore. He was the head of a small company with around 30 people – mainly civil engineers – in the civil engineering sector. He was overworked: He was constantly expected to put in his two cents, his employees were always asking him for tasks and everyone wanted to know what he thought of current projects as the boss. Careful attention was paid to compliance with hierarchies. However, the fact that he constantly had to deal with approving and taking responsibility meant that he could hardly devote himself to the tasks that would have taken the company forward – such as strategy, marketing and recruiting.

On top of that, the projects dragged on for a long time, even though he always did his best. There was no land in sight, because his team was entrenched; everything would continue in this rut indefinitely.

After careful consideration, he decided that he had to do something different, that he even had to change something fundamentally.

He decided to introduce Scrum in his company…

For your orientation:

In this article, we will look at the theory – how Scrum works, the underlying concepts and so on.
In the next article, we will take a look at the practical side of things: there we will report on the experiences our customer Mr. M. and his employees have had with Scrum in practice.

What is Scrum? The definition – the most important points in brief

Scrum is an agile method with which projects can be managed, developments can be driven forward and which is suitable for establishing self-organization in a company. Scrum is characterized by close communication between all those involved, a high degree of adaptability to change and flat hierarchies. With Scrum, it is possible to manage “on sight” when there is a high degree of ambiguity and complexity; it is not necessary to draw up a detailed project plan before the project begins. Scrum works with teams that are cross-functional or interdisciplinary. The goal and direction are predetermined, but the teams have the freedom to shape their own path to get there.

The benefits of Scrum: When is Scrum the right solution for you?

Scrum is a suitable method for you if…

you work with a team
many factors are still uncertain and cannot be planned
you want to process and complete your projects at maximum speed
you need maximum flexibility
the focus is on customer requirements
your employees should be encouraged in their motivation and personal responsibility
you want to become an attractive employer with flat hierarchies, plenty of room for maneuver and responsibility.

The history of Scrum: How Scrum came about

The term Scrum

The Japanese scientists Ikujirō Nonaka and Hirotaka Takeuchi are considered the most important researchers in the field of knowledge management. In 1986, her article “The New New Product Development Game” appeared in the Harvard Business Review. This laid the foundation for understanding project management and product development in a new way:

Nonaka and Takeuchi emphasized the importance of collaboration, as it brings synergies and hidden knowledge to light and thus paves the way for new ideas. What was new here was to take up impulses from the team instead of organizing top down.

They used the words “scrum” and “sprint”, which they borrowed from rugby, for the first time. Scrum means hustle and bustle. In rugby, it is a dense collection of 5 – 8 players who push in the same direction and try to bring the ball into play as a unit. This is the symbol of different employees working together as a close-knit team, reacting spontaneously in the same direction in order to be successful.

Scrum in software development

The US software developers Ken Schwaber and Jeff Sutherland are regarded as the inventors of Scrum.

At the beginning of the 1990s, Sutherland and his software development team developed the foundations of this type of collaboration. What was new here was that the project manager no longer acted as a manager, but took on a moderating role. Scrum took account of the fact that in the rapidly changing world of software development, the development process often has to be adapted quickly to sudden changes, meaning that long-term advance planning of the process is not possible.

In 1994, Sutherland and Ken Schwaber put the team’s findings into a form.
In 1995, Ken Schwaber presented Scrum for the first time at a scientific conference focusing on computers/programming.
The first book on Scrum, “Agile Software Development with Scrum”, written by Ken Schwaber and Mike Beedle, was published in 2001.
In 2001, the agile manifesto was created, in which Sutherland and Schwaber, together with others, set out the values behind agile software development. More on this in a moment.
In 2003, Schwaber began training the first Scrum Masters and published another book: “Agile Project Management with Scrum”.

Scrum in other industries

In 2007, Schwaber published his third book “The Enterprise and Scrum”. The processes, roles and principles of Scrum have now been made transferable to other industries. Since then, more and more companies have gained experience with Scrum.

Scrum and other agile methods represent a contrast to traditional management: Tasks are no longer assigned and controlled by superiors. A so-called “product owner” sets a goal for the team and the team is responsible for its implementation.

Here is an overview of other agile methods: Design Thinking, Design Sprint, Lean Start Up, Scrum, Business Model Canvas

Agility

Agile working – the values behind it

In the winter of 2001, 17 independent-minded people from software development spent a presumably amusing ski trip together at a ski resort in the mountains of Utah. Many of them were already working with methods such as Scrum. Ken Schwaber and Jeff Sutherland, the founders of Scrum, were also among them. In addition to numerous leisure activities, they worked together to find ways and values to improve software development. And they did: those present agreed on four fundamental values. These values are now the basis for agile working worldwide, even in industries that are far removed from software development. These are the four original values summarized in the so-called Agile Manifesto.

The agile manifesto

“We are finding better ways to develop software,

by doing it ourselves and helping others to do it. This activity has taught us to appreciate these values:

Individuals and interactions more than processes and tools

Functioning software more than comprehensive documentation

Cooperation with the customer more than contract negotiation

Responding to change more than following a plan

That is, although we find the values on the right important,

we estimate the values on the left to be higher.”

It is important to mention at this point that the Agile Manifesto does not want to do without plans, processes and documentation; there are just things that have priority.

Source: http://agilemanifesto.org/iso/de/manifesto.html

The values behind Scrum

Based on the agile manifesto, we have defined the values on which Scrum is based. These apply to all areas of work and industries – not just software development.

Focus on the people involved and the cooperation within the team and with the customer instead of on processes, contracts and documentation.
Focus on customer benefits and flexibility instead of long-term plans and compliance with them.
Self-organization: The team plans its work itself and makes the necessary decisions (trust).
Speed: Continuous delivery of project progress to the customer.
Flexibility: We are always happy to incorporate any changes requested by the customer as the project progresses.
Cooperation: Interdisciplinary mixed teams, personal communication is the most efficient.
Continuous improvement: feedback from colleagues and customers is constantly incorporated.
Transparency: The team is regularly informed about the current state of affairs. Adjustments can be made promptly.
Structure: The team sets fixed time limits that everyone must adhere to.
Simplicity: focus on the essentials, leave things out.

Video What is Scrum

Susanne from berliner team talks about Scrum in this 2:30 minute video.

The Scrum Guide: How does Scrum work?

Five activities, three roles and three artifacts

In the graphic at the very end of this article, you can see how the individual factors are connected and how the Scrum method works. We will now explain the meaning of the individual terms, functions and so on. As mentioned above, the basics of Scrum (the core) consist of three roles, five activities and three artifacts.

The three roles in Scrum

Let us first take a look at the three roles that can be taken on by team members, and in some cases also by outsiders, during a Scrum process: Product Owner, Scrum Master and Scrum Team.

The product owner – goals and priorities

Mediator between the team and the outside world

The Product Owner is the person who formulates the goal and requirements of the project and commissions the Scrum Team to do so. To this end, he acts as an interface between the Scrum team and the outside world, i.e. customers, stakeholders and other participants.

If the result of the collaboration is to be a product, for example, the product owner finds out what the customer wants and needs and uses this to define what the product should ultimately look like, what it must be able to do and what features it needs in order to please the customer.

This means that the product owner is responsible for ensuring that the resulting product is later well received by the customer, that it is attractive to the customer and therefore marketable.

He breaks down the information he receives from the customer into individual work tasks and then provides the team with the goal to be achieved and the steps to get there; he creates a requirements list (product backlog) for this purpose.

Set priorities

He is also responsible for prioritizing tasks: Where do we start, what is the most important thing at the moment? He can assess what the customer is currently focusing on; in software development, for example, it may be a priority to be able to quickly present a certain part of a program to the customer for testing.

The Scrum team receives the requirement and works on it independently for the duration of a work cycle (sprint). It decides for itself how much work volume it can handle in the work cycles (sprints), which usually last two to four weeks. The team acts without work instructions; the product owner is not the superior.

Sprint Review

At the end of a sprint, the product owner reviews the progress made, gives his opinion and obtains feedback from customers and stakeholders. This step is called a sprint review.

The Scrum Master – supporting the team

While the Product Owner is responsible for the product and its criteria, the Scrum Master ensures that the process runs as smoothly as possible. So he doesn’t really have much to do with the content, the product itself; but he knows best how Scrum works.

Moderator and mediator

The Scrum Master moderates the process by ensuring that communication flows and that the various meeting formats and structures are put into practice. Instead of organizing and distributing tasks, it provides the platform that enables the development team to decide for themselves who takes on which tasks and when, how they are organized and how many of them are to be completed in which period of time. He acts as a moderator for these decisions. When conflicts arise, he takes on the role of mediator. The Scrum Master removes obstacles and protects the team from outside interference.

He leads the process without being a manager, as traditional managers are not needed when working with Scrum. There are no hierarchical structures; instead, there are various roles that the team members can take on, some of which also include management tasks.

The Scrum development team – independent execution

Actually, all of them together, i.e. the Product Owner, Scrum Master and the development team, are called the Scrum Team.

However, we take a broader view of Scrum: Scrum is not just a method of development, but also a way of organizing collaboration. We call the team that ultimately implements the requirements the development team. This team makes decisions together. When the team receives the requirements list (product backlog) from the product owner, it decides how to deal with the requirements in the next work phase (sprint). It discusses the following questions together:

How much can we manage?
Who can do what?
How do we manage that?
How do we organize ourselves?

– And then finally sets about implementing it.

A team should consist of 7 people from different disciplines. If more than 10 employees are required, then they should be divided into smaller teams. The small size ensures that sufficient communication is possible and makes self-organization easier.

Other roles in Scrum

We have looked at the three central roles in Scrum. It should also be emphasized that the roles mentioned above differ significantly from roles in traditional project management.

In addition to the roles mentioned, there are of course other people who are involved in a Scrum process – the so-called stakeholders. These are, for example, customers, users or management – all people who have an interest in the development of the product or service in one way or another.

The sprint – the timing of work cycles

A sprint is usually a period of 2-4 weeks. During this time, the development team works together on the tasks set by the product owner in the product backlog.

How does a sprint work?

Each sprint cycle begins with joint sprint planning and is followed by the work phase. In sprint planning, the goal of the current sprint cycle is defined and the work is distributed. During the work phase, they communicate regularly with each other according to a predefined plan. These meeting and communication formats are described below. At the end of the cycle, there is a so-called sprint review. Here you look together at the results you have achieved within the 2-4 weeks. On top of that, there is a sprint retrospective in which we look at the form of collaboration: How did we work together? What can we improve?

During a sprint, the development team works undisturbed. In other words, it pursues the specified goal, which cannot be changed within this period. There must be no redirection during an ongoing sprint; there is plenty of opportunity to update goals and procedures between sprints.

Once a sprint has been completed, the next sprint follows immediately.

The length of a sprint

Sprints are deliberately kept relatively short so that you always have the opportunity to obtain the customer’s opinion in between and so that you can take changes in the market or situation into account. This ensures that you don’t work in the wrong direction for too long. It has been found that two to four weeks is a good period. During this time, possible changes from outside are usually not too great, so that the team can throw itself into the given tasks for the time being.

A sprint is as long as previously agreed; it cannot be extended. All sprints should have the same length so that the entire process has a kind of clocking.

The product owner can cancel a sprint if the task has changed so fundamentally in the meantime that it no longer makes sense to continue working on it or if it is foreseeable that the team will not be able to achieve the sprint goal, for example because it has misjudged the volume of work. In the event of an abort, a sprint retrospective is first conducted to look at how the work was done and what could be improved – and then the next sprint planning is started again.

An ideal tool for a sprint is a so-called sprint wall, on which the tasks to be completed within the current sprint cycle are visible to everyone at all times. More on this later.

The sprint goal

The sprint goal describes the result that should be achieved by the team at the end of a sprint, i.e. after 2-4 weeks. What is important here is that this goal is something that is visible; a result of which you can say that you have something concrete. This gives the team a goal, orientation and motivation at the same time.

Here are some examples of possible sprint goals: At the end of the sprint we want to…

… have completed the documents for all 250 participants in the change process.
… publish a new element in the store on the website.
… have finished developing the sensor.

As you can see – even if many tasks are subsumed under them – these goals are tangible and usable. Finally, they should also be tried out, touched, checked and viewed by everyone involved, including stakeholders, in the sprint review.

The artifacts in Scrum

Now we come to the so-called artifacts. Wikipedia describes artifact as follows:

An artifact (software development) is a product that is created as an intermediate or final result of software development

You can tell from this word that Scrum comes from the field of software development. There are three artifacts in Scrum: the product backlog, the sprint goal and the product increment. These describe the respective goals, the respective status.

The product backlog

The product backlog describes the vision of the finished product or service. All requirements are listed here in as much detail as possible: What should it look like, what features should it have, what does it need? The product owner is responsible for determining and compiling this information with the help of stakeholders, especially customers.

The product backlog also contains the tasks that need to be completed in order to develop the product.

The product owner also works continuously during the sprints to keep the product backlog up to date: He presents the current prototype to the stakeholders after each sprint cycle and incorporates criticism, requests and other details defined by the stakeholders into the product backlog.

In this way, he puts the interim results through their paces: Are we still on track with our development? Is this still the right thing to do? What needs to be changed?

The procedure

The original start backlog can be developed in a design sprint, for example.
From this idea, you break down which tasks need to be completed.
A prototype is developed by working through this task list.
This is constantly reviewed by customers and stakeholders for its usefulness (product backlog refinement).
Requirements and tasks in the product backlog are updated according to this feedback.

The tasks in the product backlog

You can imagine this in detail as follows:

There are always larger task packages. From these, individual tasks are then prioritized and carried out in more detail. In this way, you end up with a list of relatively detailed tasks so that you can estimate the amount of work required.

This can then be used to plan the work for the next sprint.

So you work your way from the big vision, from the big goal, to individual work steps that can be completed in a sprint period of 2-4 weeks.

The sprint backlog

The sprint backlog shows the tasks that have been selected from the product backlog for processing in the next sprint.

A so-called sprint wall is often used to make the tasks and their respective processing status accessible. This wall or panel is divided into four columns from left to right.

The sprint wall

On the far left are the backlog entries, i.e. the specified tasks that describe in detail what needs to be done.
In the middle, these tasks are subdivided into smaller tasks.
The third section, a little further to the right, contains the tasks that are currently being processed.
Finally, the column on the far right contains the tasks that have already been completed.

The process

Tasks move from left to right. This visualizes how far you have already come in this current sprint. Whether the sprint wall is an actual wall, a whiteboard or an online function such as Trello, where everyone has the current sprint wall on their cell phone, each team can design it however they like. Of course, it’s an advantage to use an online sprint wall if you tend to work together virtually and don’t always work in the same room.

It is also important to mention that the names of the team members who are working on the task are indicated on the tasks that are being processed. Once a team member has completed a task, they move it to the corresponding fourth column.

The team member then selects a suitable new task in the column containing tasks that still need to be completed, puts their name on it and adds it to the “In progress” column.

The product increment

The product increment is all entries in the product backlog that were completed during the current sprint plus what was already completed from previous sprints. It is virtually the current status of the product that corresponds to the “Definition of Done”. As the sprint goals are tangible, usable goals, the product increment must also be usable and clear.

An example of such an increment could be executable software: a part of a new program that already works on its own. In a change process, an increment could be a completed process in a sub-area of the organization if changed structures, processes and new forms of collaboration have already been implemented in this sub-area.

Definition of Done

The “Definition of Done” is a common understanding of the Scrum team about when work is considered finished. For example, it contains something like quality criteria.

The product increment, as the current status, serves both to motivate and to check the result.

The Scrum meeting formats

Sprint planning

A sprint begins with joint sprint planning.

Duration: 4 – 8 hours, depending on the length of the sprint.

Sprint planning phase 1

This is where the Product Owner, Scrum Master and development team come together. As always, the Scrum Master has a moderating function. The product owner presents the current product backlog, i.e.: what exactly is the current version of the product or service we are developing? As he has already worked out and prioritized task packages in the preliminary work, he next presents the tasks he has planned for the upcoming sprint.

The entire team works to ensure that everyone understands what exactly is at stake, what is to be achieved and what tasks are pending. The development team then considers among themselves how many of the tasks presented by the product owner they can actually accomplish in the next sprint cycle. Once the executing team has discussed this, it defines the next sprint goal together with the Product Owner and Scrum Master: What should the result look like after the sprint?

Sprint planning phase 2

After this first part of the sprint planning, the development team and the Scrum Master withdraw. The team discusses what exactly it needs to achieve the sprint goal. It agrees on which tasks are still necessary in detail and how it wants to organize itself. The Product Owner does not need to be involved in this detailed planning. He can, but it is not necessary.

Once the detailed tasks have been named, they are made available to everyone on the sprint wall. They are not distributed to the team members, but the team members themselves choose which task they want to work on and when. Only when a team member has decided that a task is a good fit for them does they write their own name on it and move it to the “in progress” column on the sprint wall.

The Daily Scrum

At the start of each day within a sprint, the development team meets together with the Scrum Master.

Duration: approx. 10-15 minutes

The Daily Scrum

The Daily Scrum is a short meeting every day at the same time. Ideally, it takes place right at the start of the day. It’s about briefly exchanging information. It is deliberately kept very short so as not to get bogged down. The Scrum Master is responsible for keeping things short and sweet. The following three questions are asked every day:

What have we achieved since the last Daily Scrum?
What will we achieve by the next Daily Scrum?
Are there any obstacles? And what are these obstacles?

Possible obstacles can be: lack of information, disagreement about how to implement the task, a conflict or organizational obstacles. The Scrum Master collects the information on the obstacles and ensures that they are removed if possible.

What can this look like?

For example, the executive team has an organizational problem: it needs more capacity, someone to support it. The Scrum Master organizes the support. Of course, this does not mean that he has to fulfill every wish of the team. Because if the team is able to remove an obstacle itself, then it must also tackle it.

If, for example, information is missing and needs to be exchanged within the team, an appointment is made for this, in which this content-related information flows; the scarce time of the Daily Scrum is not used up for this. This is really just about ensuring that everyone is up to date.

Burndown chart

It is also advisable to visualize the current status in a burndown chart. Here, the number of tasks still available for a sprint in relation to the time still available is recorded daily in a graphic. This gives you an indication of whether the planned goal can be achieved.

The Sprint Review

The sprint review is the meeting to present the sprint result.

Duration: 2-4 hours

The Sprint Review

After completion of a sprint cycle, a sprint review meeting is convened. Team, product owners, sprint masters and stakeholders are invited. In the sprint review, the team presents the result of the last sprint and answers questions about it. Ideally, the Sprint result is something that can be touched and tried out so that the steakholders can gain experience with the product. The stakeholders take a look at the result: How does the product actually work? Can I cope with this? What am I missing? etc.

The product owner notes down the feedback from the stakeholders and enters it into the product backlog so that the information gained can be incorporated directly into the next sprint.

The aim of the sprint review is to improve the product.

If a further session is required to update the product backlog, i.e. to update objectives, tasks and priorities, this is called a product backlog refinement event.

The Product Backlog Refinement Event

The Product Backlog Refinement is an ongoing activity of the Product Owner to update the Product Backlog.

Product Backlog Refinement

During the sprint, the product owner continues to work on updating the product backlog. He cannot do this all by himself; he has to consult stakeholders, i.e. customers, users, management and also members of the work team. He invites them to a product backlog refinement event, which takes place once or twice during a sprint. At this meeting, the stakeholders can specify which functionalities they would like to see in the product. The members of the executing team can provide feedback on what works and what doesn’t. The product owner is responsible for incorporating stakeholder feedback into the updating of the product backlog. He also ensures that the tasks that arise are defined, assessed and prioritized. It ensures that the product backlog is kept up to date, which means, for example, that new entries are added and old ones removed, and it specifies which tasks are to be processed in the next sprint.

Sprint retrospective and outlook

Duration: 1- 3 hours

In the sprint retrospective, the team reflects on the collaboration during the last sprint.

Sprint retrospective

After the sprint review and before the start of the next sprint, the development team comes together and considers what went well in the last sprint and what the team can optimize. The aim is to optimize work processes and find a way of working together that is as pleasant as possible for the team. This meeting is moderated by the Scrum Master. Various techniques are available for this purpose. As it is the Scrum Master’s job to support the team in their work and optimize collaboration, the Sprint Retrospective is an important part of their work.

Questions that the team can ask themselves here:

How did we do at the last sprint? How did we work?
What went well?
What didn’t go so well?
Does our team fit?
Are we good at communicating with each other?
How do we discuss things? What can we improve?
How did we define “done” (“Definition of Done”)?
Is that too much or too little of a challenge, or is it just right?
Have we made any progress with the result?
Are we on time, in this sprint and overall?
Will we manage to develop our product in time if we carry on as we are now?

Scrum overview

Here you will find a graphical overview of all roles, meetings and artifacts and how they are connected:

Scrum: What’s next?

And what happens when you introduce Scrum in your company?

What are the advantages and disadvantages?

In our next article Scrum in practice – advantages and disadvantages of Scrum, we report on how our customer, Mr. M., succeeded in introducing Scrum in his company, what obstacles he had to overcome and what had a positive effect.

In our article The Scrum retrospective – explanation and practice, we go into detail about the retrospective.