What is Scrum? A brief definition

Let’s start by writing it “Scrum”, not “SCRUM” as you often see. It’s not an acronym, and we don’t know exactly why Ken Schwaber and his colleagues capitalized the term. Perhaps because in the age of typewriters, boldface did not yet work as well as capital letters as a means of emphasis. Maybe he just thought it was cooler – we don’t know. From 2002 at the latest, with the publication of Schwaber’s “Agile Software Development with Scrum“, it is spelled “Scrum”, and that’s how we keep it in this article – agree? Incidentally, the book should be required reading for every aspiring Scrum Master, as well as for teams working according to Scrum.

Scrum is also not a term exclusive to software or projects: it comes from rugby, literally translates as “scrum” and, according to Wikipedia, refers to a phase of the game in which all 32 players scramble for the ball after a breach of the rules. This leads to different versions of a “scrum” in which a lot happens, divided into many small steps; everyone knows what to do, which brings the ball forward bit by bit in joint moves: order in chaos. Oh dear, we have almost casually summed up the quint essence of Scrum. Incremental work, wonderful. Hirotaka Takeuchi and Ikujiro Nonaka should also be mentioned in passing. In their article “The New New Product Development Game“, the Japanese talk about Scrum as early as 1986 and mention that there are already numerous companies in Japan and the USA that work according to this (then) new “method”. So nothing really new in the West. And east.

(Almost) last, but (for sure) not least: Scrum is a framework, not a methodology. This is debated here and there. With a “method”, however, not only the framework is clear, but also its implementation. Although Scrum as a framework specifies basic rules and structures, it does not prescribe how it should be implemented.

Speaking of which, do we need to explain Scrum itself again at this point? I think we’d better keep it simple here, because most readers will probably know. To be on the safe side, in case someone looks over your shoulder:

Scrum in Quick Dive

Scrum is a framework for project development, primarily – but not exclusively – for software development. A typical character trait is to divide once large and lengthy goals into small steps, so-called increments, with fixed times and roles. The aim is to be able to repeatedly present the stakeholder with functioning sub-steps, to be able to respond flexibly to requirements and changes and to move step by step towards a final goal. Scrum. Crowded, but with order. Makes sense. The roles are clearly assigned:

• The core is always a (software) development team that is led by a
• Scrum Master is supported, and with the
• Product Owner who shares the product vision with the team and

working cooperatively towards the final product. The core of this approach is the “sprint“, a defined period (usually between 1 and 4 weeks, two weeks is the most common standard) in which the actual development work takes place.

To provide optimum support for this work, there are so-called “Scrum events“:

• Sprint planning at the start of the sprint, in which the entire team defines the scope of work for the sprint based on the priorities of the product owner and the available resources.
• In the Daily Scrum (also known as “Daily Stand-Up”), the team meets and briefly discusses what was done the day before and what should take place today (so it makes sense early in the day).
• In the sprint review, the team presents the (ideally) functional product increments to the stakeholders, often the product owner. In the example of a smartphone app, this could be a new function, an interface, functioning buttons and the like. Not the entire app, but partial steps, called “increments”. The product owner also plays an important role here and provides feedback on progress. The key question of this meeting is: “Are we on track?”
• Often neglected and seen as a nuisance, but one of the most important events is the “sprint retrospective” (often abbreviated to “retro”), in which the team (usually without the product owner) meets and reflects on the past sprint: What went well, what was not ideal, what needs to be improved? How exactly can we improve, where are there any gaps? It should always be possible to derive concrete results from this in order to optimize the next sprint.

If you have now heard of the “artifacts”, i.e. the

• Product backlog (i.e. the list of all desired work on the product),
• the sprint backlog (the list of tasks that the team wants to complete in the current sprint) and the
• Increment (sum of all product backlog items that were completed during this and, if applicable, the previous sprint),

you’re already doing well. Only those who actually work with it need to know more. To conclude the paragraph, the three pillars of Scrum that underpin our framework: Transparency, Review, Adaptation. With so many increments, you need an overview, sub-steps must be checked (quality assurance) and adaptation must always be possible. After all, Scrum as a primarily agile framework (which it may be at times – we’ll get to that) is based on agile principles, above all the “Agile Manifesto”. But I’ll link you to it now so you can read it for yourself – open it in a separate tab, and when you’ve finished reading it (or don’t read it at all), we’ll continue right here:

What Scrum is not – The limits of the framework

So now we know quite well what Scrum is, and perhaps also have an idea of how we would like to use this framework in our organization. It’s not rocket science. Perhaps an “Agile Master” who – for whatever reason – likes to decouple themselves from the team and attaches great importance to the fact that they are not “just” Scrum Masters. The role of an Agile Master or Agile Coach within a software development team is very clear: it is that of the Scrum Master. As part of the team. Not a leader, at best an advisor. Not a servant either – at best a contact person for all matters, because there is trust.

That all sounds wonderful and not particularly complicated, right?

So why do we now have to bother with the premise that Scrum, according to the clickbait title of this article, doesn’t work at all? Is that really so fatalistic? Let’s take some examples from real projects that I have come across. I won’t name them specifically, but all of us involved with this article are familiar with such or similar stories:

• Planning every single step in the team takes an insanely long time. Entire days are used to plan everything down to the last detail. Jira is installed, a billion stories are written and then everyone sits in a circle and asks themselves the same three questions every day until someone drops dead. In the end, there are lots of story points, the actual conversion of which into hours or project days is a big secret. These should be used to get an idea of the complexity of a task and to obtain an estimate from the team of how long it might take to complete it. Instead, story points and Kanban boards are – far too often – used to rigidly measure the time and performance of team members. Kanban boards are also very popular outside the project landscape – or, to call a spade a spade: misused.
• Sure – we have T-shirt sizes, a great idea: So and so many story points are an M-task, a few more are an XL-task, and we can also include a small S-story. But is updating Kibana now an L or XL task, or are we splitting the story into lots of little S stories? And what if the test server goes down? As a result, the team fills its schedule, always looking to deliver instead of focusing on programming (testing, implementing, etc.).
• And what happens when the Scrum Master AND Product Owner are on vacation? Is there still a Daily, or even a Sprint Planning? What if storypoint specifications are always the same and almost never caught up with? Is a spillover planned, or does it simply mean: target not achieved, order gone?
• Well, then maybe we’d rather write a ticket after all (but only the simple ones – who wants to voluntarily grab the enormously complex problem ticket so that everyone on the Kanban board can see later that they were unable to solve the task completely, possibly through no fault of their own)? Or would the problem have been solved in 5 minutes, while writing, forwarding and closing the ticket took half an hour? How many pointless story points are we losing here? Can we still charge the customer for this?

Oh, you know what? Scrum simply doesn’t work for us, and all that agile stuff doesn’t help anyway, except to make things complicated.

But, spoiler: It is precisely the agile idea that is missing here. Scrum is NOT the same as Agile Development. It is a building block, and a building block alone does not make a house. Or Lego castle. Uhm, or riverside puzzle that has been lying on the cupboard gathering dust for months, and not just because all the pieces with grass on them look the same. Scrum is a tool that needs to be used correctly, and in all the examples above this was simply not the case.

Scrum by no means means that you don’t have to or have to document because the Agile Manifesto says so. It does not. It says: “We put working software above detailed documentation.” In other words, we value documentation and use it. We just don’t want them to be unnecessarily sprawling, and functional software increments that we can offer the customer in the – watch out? – Sprint Review, we prefer to do so. The agile manifesto also says this, even though it is often overlooked: We prefer the new insights, but we also value the foundation on which they are built.

Scrum does not always work and not in every project. Ultimately, it is “only” a tool for process management, for optimized and adaptable processes and work steps. However, it is not a panacea for making any software development team more efficient. A nice graphic for this is the so-called “Stacey Matrix” from the official PMI Agile Practice Guide (for a better understanding: Scrum as an agile framework falls under “Adaptive Approach”).

However, and Ralph Douglas Stacey says this himself: The matrix has no real significance. It is intended as an aid, a first overview. However, it is often used to promote agile methods or specifically Scrum. That is not the basic idea behind the matrix. For example, “complexity” is not a suitable metric on the basis of which to select the project method, and of course the matrix cannot take the specific project environment into account either. However, the matrix is certainly an aid to getting a rough idea of whether Scrum could fit here or not, and you should have seen it at least once either way. Done with this.

So we learn that there are indeed areas in which the classic waterfall method is still adequate in development, or the V-model (knowledge of the PDCA cycle is also recommended as a first check). Scrum is not a solution that stands on its own and fits on absolutely every lid, regardless of the circumstances. This also applies if the pot would otherwise fit: a team may be broadly based, the project requires an adaptive and flexible approach to development, the company provides support, the Scrum Master does not come from the development team (a common mistake): And yet it still doesn’t work. Not every team member wants to work independently and cooperatively at the same time. Not everyone wants to talk publicly about their work, and not every developer feels comfortable with clearly defined roles, preferring instead to switch projects frequently. Without a team, there is no Scrum – this is an unwritten but absolutely essential truth. However, Scrum itself is not a means of forming teams. Sometimes a good Scrum Master can inspire and bring a team together, but they cannot create it alone.

We have now established what Scrum is not, what expectations it cannot fulfill and what mistakes can occur if the framework is used incorrectly. Time for us to stop looking at Scrum as a solution, but as a building block on the way to the goal.

Scrum as a building block of functioning agile software development

A recurring mental error that occurs in day-to-day work with Scrum and especially for decision-makers considering its use is this sentence: Scrum is a fixed framework for which you have to follow all the rules in order for it to work.

Scrum is adaptive in its absolute basic nature. Customization is one of the essential advantages of the framework. Sure, omitting Scrum events is not a particularly good idea. But nobody says that it is no longer Scrum because Product Increment Planning is also part of the recurring meeting cycle. Nobody says that team members are not allowed to express themselves outside the retro or that increments should only be presented in the review. Flexibility is one of the hallmarks of the agile methodology in particular, and Scrum is simply one of its tools. There are other tools: lean management/development, Kanban (although almost always part of Scrum), extreme programming (XP) (here too, for example, the “pair programming” part can find its way into Scrum projects) or Crystal, a method (or framework) that is extremely focused on the individuals in the team.

Scrum is therefore not just a project management tool – it is a building block, a critical component of an overall, overarching agile philosophy that stands for adaptability, team cohesion and customer focus. Thanks to the constant exchange of information, customers are always aware of the status quo, progress, goals and, of course, costs, even in complex and long-running projects. Companies that use Scrum can also track very precisely which costs are incurred at which point and draw vast amounts of knowledge from completed sprints. From simple flowcharts that give us a good idea of team velocity, to complex dashboards that provide information on which tasks are repeated, how they were accomplished, with how many people, in what time? Clear house numbers, delivered by an adaptive and flexible tool. Full cost control and insight into performance without having to monitor it passively and aggressively. Wonderful.

Scrum flexes its muscles at team level in particular: The pillars of Scrum (remember, without scrolling up again, right?) ensure that all tasks and processes are transparent, checked and adaptable at all times, more so than the events and basic rules. Open communication, coming together regularly and interacting as a real team, in which every member is equally important (“The Circle Way – With a Leader in Every Chair”), builds trust and reliability, in others and in one’s own abilities. An open culture based on these values allows for feedback, but also for mistakes: these are examined and avoided for the future. And if they do reappear (after all, according to the rigid application, every mistake is allowed to happen, but only once…)? The team then investigates – together – how this can happen. Being listened to constantly, in a safe environment, without fear of disciplinary reprisals: this is possible in a sprint retrospective like in hardly any other setting. Just giving criticism that is not the least bit constructive, but simply letting off steam in a group that understands and appreciates you: infinitely valuable. Psychological safety is not just a buzzword. It enables teams and individuals to achieve tremendous things, but above all to achieve well-being, stability and appreciation for themselves and others.

Scrum no longer sounds so methodical and rigid, right?

Used correctly as a building block of an agile transformation, Scrum – in the right scenario – is an option that can work if attention is paid to the variables. Do employees not like to work independently, but need every task explicitly mentioned and demanded? There is such a thing, not everyone is made for freedom. Probably not a good fit for a Scrum team. The ability to take criticism, further development on a professional and personal level, team spirit and a certain selflessness are all part of this. Scrum is a framework for teams. If you don’t have a team, you don’t need Scrum, it’s as simple as that. By the way, a good Scrum Master is a great advantage here: we’ll talk about this again in a moment.

Speaking of teams: if you combine Scrum with DevOps practices, you can create extremely strong development teams with few external dependencies and great agility, which enables the delivery of high-quality software (or other products) faster and more reliably than in traditional team divisions. Reducing dependencies (“impediments”) is the declared task of the Scrum framework (and subsequently of the Scrum Master). Only in DevOps teams can Scrum really be used as the agile manifesto once intended, namely, as the Scrum Guide says: “The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.”

Real delivery, from development to release, i.e. “end-to-end”, is not feasible in pure development teams. There are often pure development teams and pure operations teams, and Scrum is already experiencing its first headwinds. Sure – not every organization has the choice. But the rumor that Scrum doesn’t work with DevOps units? Just an urban legend. A nonsensical one at that.

Even more could be said about Scrum as a building block: How it is wonderfully scalable, for example in SAFe projects, how the recurring nature of Scrum brings all stakeholders on the same boat again and again (allegorically speaking. Although I don’t see why a retro couldn’t also take place on a boat).

But the biggest advantage of Scrum as a building block is certainly consistent with what the co-founder of the agile manifesto, Ken Schwaber, said about it, we quoted it in English just two paragraphs ago, but it’s so important, so here it is again: the most important element of Scrum is the creation of a finished and basically release-ready product increment.

The advantage is obvious. At the end of each sprint, teams, entrepreneurs and stakeholders can come together and see real progress. Not after 2 years of development and intensive testing, where ancient bugs have to be looked up in endless documentaries (if they are designed and commented on in a meaningful way at all. Everyone knows legacy documentaries from developers who simply didn’t care in the end…), and where after the presentation it’s seventeen steps back in development because it feels like a million new versions, updates and platforms have been created in the last two years. Instead, Scrum progresses iteratively, always has its finger on the pulse, presents results, adapts to circumstances and also gives you the opportunity to respond to current and possibly changing stakeholder priorities: By reprioritizing in each sprint, you only implement the goals that are really desired instead of wasting work on unnecessary tasks – it could hardly be more flexible.

For me, however, something else is even more important. “Take it with a grain of salt” – my agile journey has only just begun. It may therefore be more a personal note than a fact, however: The formation of a team is the essential achievement of Scrum as a framework. I know of no other tool that creates trust to such an extent, for teams, for customers, for companies. Teams are made up of real people, with strengths and weaknesses that we can use – in both cases – to develop personally. The constant, ongoing exchange at eye level, the visibility of everyone, people and processes, the encouragement to take responsibility and ownership for development steps and one’s own performance: They create cohesion. Regular, incremental successes release dopamine, the reward for a job well done. Every completed sprint is not just a simple achievement of a goal. It is a step towards a higher standard of true excellence and enhances the team’s ability to not only meet deadlines, but to create outstanding collaborative outcomes. What’s more, real feedback helps us to progress both professionally and personally, and Scrum and all its events offer endless opportunities for this. Paired with a Scrum Master who sees themselves not only as a moderator, but also as a facilitator and enabler in the role, bonds are formed in Scrum teams that create real psychological security and can enable people to achieve great things. Or even small things, that’s what Scrum is for.

Oh, that would almost be a good conclusion, the article is not exactly short. But let’s talk briefly about what has changed in Scrum – we’ll do this by looking at what has been officially recorded in the Scrum Guide. It’s interesting, provides an opportunity for a small list (Google loves lists), and we have a well-rounded article. Because what Scrum is, what it is not, what it can do, if you use it correctly as a building block instead of a solution: We have clarified everything. So let’s get going, time is short, quickly make the changes and then to the conclusion, okay?

What Scrum is now – the changes since 2020 (official Scrum Guide)

Yes, times change, and times change you. And they change Scrum. Let’s talk about the Scrum Master, for example: according to the previous definition, the Scrum Master at best has no authority in the team, neither disciplinary nor technical, and should come from software development (at least in the software development area). Instead, project managers are now also seen as Scrum Masters (from “Servant Leader” to “True Leader”), as are “non-techies”, who can bring in new and different perspectives due to their distance from the technical level and, if we are talking about self-confident facilitators, can place a greater focus on creating psychological security (we recommend the Sharon Bowman’s school of thought -> “Training from the back of the room”). And Agile Coach and Scrum Master become blurred again. By the way: The roles are not titles. A Scrum Master can be a great Scrum Master without calling themselves one or ever having completed a Scrum Master certification.

Until now, sprint planning has been dominated by the thesis of two questions: “What do I do” and “How do I achieve this”. Meanwhile, a third question is welcome: “Why do we want this?”. It’s a somewhat complex question that doesn’t fit into every context. But (another Anglicism, I just like them:) Here we go again – Scrum is adaptive. Your Scrum Master is welcome to come along with or without authority, as long as they are NOT a developer from the team (they have more important things to do, like, uh, making money for your company!), and you can ask just one question. But you’ve heard it before.

Also new are the “Commitments” – the artifacts (do you remember all three?) now come with a commitment. The sprint backlog now receives the “commitment”, i.e. the “dedication” of the “sprint goal”, and the increment receives the “definition of done”. This increases transparency for everyone involved and helps to further deepen the Scrum values. Honestly, for someone who wants to know why you should do almost every task in life and has driven countless employers into semi-madness with it, I think this is a beacon for cooperative and appreciative cooperation within a framework. Who said Scrum doesn’t work? Oh, me. But we all agree that it was more of a decoy. And if you’ve read this far: respect, you seem to be interested in the topic!

Some other aspects have also been added: The concept of “one team” (as opposed to the old division into Development Team, Scrum Master and Product Owner). Scrum Masters monitor the introduction of and compliance with the Scrum rules, but not for the company or the Scrum Guide, but for the team, and Product Owners maintain the Product Backlog efficiently and independently (the latter, however, has not been widely accepted so far, all too often the maintenance of the Backlog is part of refinement meetings with the Scrum Team, as is Increment Planning, a kind of higher-level vision alignment). According to the updated Scrum Guide, Product Owners no longer have to moderate the Sprint Review, this is now done by the Scrum Master, and above all, the vision of the “Product Goal” has been emphasized more clearly again: We are working towards a final, finished product. This can sometimes get a little lost, especially in long-term and very complex projects. Good advice, thanks Internet and Scrum Guide.

By the way, we are now allowed to leave something out. Where Sprint Planning has an extra question, the Daily can do without it completely. “What did I do yesterday, what am I doing today, what could prevent me from doing my job?” Development work, mental work – it’s rarely possible to pack it into rules, and thanks to Scrum it doesn’t have to be: simply talking openly about what you’re working on, where you might need help, where an impediment is in the way – that’s healthier and more in keeping with the times.

The term “estimation” has also been dropped, which of course refers to the story points for specific tasks. However, this does not mean that Fibonacci Sequence, Planning Poker or Dot Voting have been buried forever: They have never been specifically mentioned in the Scrum Guide. Scrum should move away from numbers, from rough estimates, from dividing performance into fixed time periods. Instead, Scrum teams are moving towards focusing on achieving their goals. Admittedly, this remains somewhat open to interpretation, as story points and T-shirt sizes will remain for business purposes and for the sensible distribution of tasks within the team. However, it cannot be denied that such time allocations always involve a certain amount of performance evaluation, which is actually undesirable in Scrum teams.

Le Grande Finale: Why Scrum often doesn’t work, but is powerful when used correctly

Scrum is not a solution. Not a panacea. Not a money-printing machine. No methodology. Not suitable for everyone. Not suitable for every project. Not made for all people. Scrum is not designed to measure performance, to appease stakeholders or to save money (although that CAN be a nice side effect). Scrum is not unchangeable, it is not VUCA, it is not controlling. Scrum is not made for projects.

If you see just one of the above points differently, you are probably not suitable for Scrum without questioning your thought patterns (yes, that’s how it works. Scrum may be suitable for you, but you may not be suitable for Scrum. Agile methods may not be suitable for your project, but be wonderful for you).

Scrum is a building block. A tool from the agile toolbox. Scrum is made for people. Scrum is a ladder, a step to enable teams to achieve great things in iterative processes. Scrum is agile, but not synonymous with agility. Scrum is often used incorrectly. Because of its simplicity, Scrum is often underestimated in terms of how complex it can be (anyone who has ever worked through the Jira of a legacy project knows what I’m talking about).

Companies that use Scrum well, however, gain experience, trust their employees and see the added value of teams that feel comfortable and appreciate each other. I recommend the movie “Pattern breaker” (which can be viewed free of charge on YouTube, where this link leads): Employees who work in psychologically safe environments do not trade them in, even for significantly higher salaries and many other benefits, and stay for years, often their entire career, with an employer that enables them to work in a self-determined, cooperative and appreciative manner.

Surely you’ll allow us a little self-promotion after such a long article, right? Cognizant Mobility has been working with OEMs and high-profile customers for decades because it focuses on precisely these values. Transparency, verifiability, customization. Not only thanks to Scrum – there are teams with and without a Scrum framework (although the majority work according to Scrum). However, the agile values have basically always accompanied the company; CEO Jörg Ohlsen has always worked according to the motto of allowing employees to organize themselves, take responsibility and maintain completely open communication.

Success speaks for the company, just as Scrum stands for the teams that make this success possible.

So, a success story after all, who would have thought it? In the end, Scrum does work.