What is Scrum?

Scrum is not an abbreviation or an acronym. (The spelling SCRUM is therefore also incorrect.) The term originates from the sport of rugby, and refers to a “scrum”, also a game situation, in which a phase of the game is restarted on command. Hirotaka Takeuchi and Ikujirō Nonaka first used the term in 1986 in Product Development: The New New Product Development Game, writing:

“In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method—as in rugby, the ball gets passed within the team as it moves as a unit up the field.

This holistic approach has six characteristics: built-in instability, self-organizing project teams, overlapping development phases, “multilearning,” subtle control, and organizational transfer of learning. The six pieces fit together like a jigsaw puzzle, forming a fast flexible process for new product development. Just as important, the new approach can act as a change agent: it is a vehicle for introducing creative, market-driven ideas and processes into an old, rigid organization.”

The following Scrum values exist:

• Commitment
• Courage
• Openness
• Focus
• Respect

The commitment of the team to achieve the agreed sprint goal, the commitment to quality, learning and doing the best together is essential to working together and building an agile culture.

Courage is important for the success of the team because it is about trying new things, admitting mistakes, asking for help when needed, saying “no” to some demands and challenging the status quo if necessary.

Openness is the basis for a learning culture, for feedback and new ideas. Openness as a value enables informed decisions, increases efficiency and builds trust.

Focus helps the team to concentrate on the important things – for example, with tools such as timeboxing, definition of ready or definition of done. In addition, the Scrum Mast tries to keep disruptive influences away from the developers and the product owner does not influence how developers realise user stories, for example.

Respect as a value is essential for the cooperation between the participants. The ideas, views and achievements of others must be respected. Respect is a central building block for successful and productive development.

Here you can find more information on how the values interact in concrete application.

The book Scrum – The Art of Doing Twice the Work in Half the Time is often cited when talking about speed. Twice the work in half the time? Sounds good, doesn’t it? Moreover, since terms like sprint are borrowed from athletics and velocity is another word for speed, it is little surprise that agile methods are often sold on a speed advantage. André Claaßen therefore speaks of an agile speed lie. And Stefan Wolpers calls for “The Art of Doing Twice the #Value in Half the Time“.

And is Scrum faster than alternative approaches? If it is possible to work calmly and continuously with each other at a constant speed, to integrate feedback at an early stage and thus consistently avoid undesirable developments, then rework, adjustments or time-consuming bug fixes are avoided, and this also increases the overall speed of development.

The Scrum Guide is short and clear, the framework easy to understand – are there any challenges at all with the introduction or application?

Yes, quite a few:

• Does the new procedure fit the organisation and the projects at all?
• How can the approach be established if it is imposed “from above”?
• How do career paths change when there are only three responsibilities?
• How does the individual visibility of individual employees change when the team becomes the focus?
• How does individual goal setting change when teamwork becomes a central component?
• How is customer feedback integrated into the approach?
• How does the management of the organisation change with the help of key figures?
• What happens if success is not achieved in the short term?
• What role do tools actually play in the application?

This list can easily be extended. It’s a good thing that Heiko Bartlog has written a great series of articles on Agility? We tried it! Does not work! in which he takes up these and many other points and provides impulses on what organisations can do to get the best out of the framework.

There is no hierarchy of roles; it is explicitly stated in the Scrum Guide:

“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required….

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint”.

Of course, individual tasks are assigned to the participants, but there is a joint responsibility for implementation and results. Ergo: No role is more important than another.

Similar to the roles and accountabilities, there is no one event that is more important than the others. The sprint is considered the heart of Scrum, because all the others take place within this event:

• Sprint Planning takes place at the beginning of the Sprint by discussing the why, the what and the how.
• The Daily Scrum is the daily standup meeting where developers meet to synchronise and share progress, upcoming activities and potential problems.
• The Sprint Review is an event at the end of a Sprint to inspect the completed work in relation to the set Sprint goal and to discuss future adjustments.
• And the Retrospective takes place at the end of the Sprint to review the recent past – i.e. the past Sprint – and thereby improve future collaboration within the team.

All events have their meaning and purpose; each event would be missing if it did not take place. Ergo: There is no hierarchy of events.

Agile software development with its prominent representatives such as Scrum or Extreme Programming is based on a foundation of values that were published in 2001 as the “Manifesto for Agile Software Development” – in short: Agile Manifesto.

It was written with the following claim: “We find better ways to develop software by doing it ourselves and helping others to do it. Through this activity we have come to appreciate these values:”

Apart from the fact that Scrum is nowadays basically used for the development of complex products or services (and thus not only for software development), the four values and 12 principles of the Agile Manifesto form the basis for the framework and therefore have great significance for its application in practice.

Kai-Marian Pukall has published an interesting article on Modern Agile Principles: Agile work made easy.

There are many organisations that offer different certifications for Scrum and/or agile. The two best-known organisations are likely to be the Scrum Alliance and Scrum.org. Felix Stein has already compiled a whopping 240 agile certifications from 39 different organisations at the end of 2020. It is very likely that there are considerably more nowadays, as many organisations have realised that there is good money to be made from certifications.

However, it would be a mistake to assume that just having a certificate is enough to have a good command of the framework or the tasks and activities of the various responsibilities. In reality, it is similar to a driving licence: it entitles the holder to drive a vehicle, but he or she can only really drive a car well many years later and only if he or she drives, drives and drives very regularly.