Why are some elements of Scrum purposefully vague and how does it impact your Scrum Team?

Scrum is very popular in the software industry. There are logical reasons for this. First and foremost, it started out as a new way of creating software. On top of that, Scrum is an Agile framework. Agile also has its roots in software development:

“We are uncovering better ways of developing software by doing it and helping others do it.” — Manifesto for Agile Software Development

But how often is a product software only? Many Product Owner and teams do themselves and their product short by limiting their focus on software. Or even worse: a software feature.

In this article, I will discuss this anti-pattern and suggest ways to solve it. …

What did actually change?

One of the major changes in the new Scrum Guide is the introduction of commitments. Each Artifact contains a commitment to ensure focus and transparency:

  • The Product Goal is a long term objective and the commitment for the Product Backlog;
  • The Sprint Goal is the objective for a Sprint and the commitment for the Sprint Backlog;
  • The Definition of Done is a quality standard and the commitment for the Increment.

The introduction of commitments helps the Scrum narrative. It clarifies the importance of an anchor in complex environments. Commitments are stable factors in a world that embraces changes. Plans may change, solution directions may alter but the Product Goal, Sprint Goal and Definition of Done remain a North Star. …

My issues with Accountabilities

One of the misconceptions is that Scrum is soft. Scrum Teams can’t make promises ‘because the product environment is complex’. When Scrum Teams don’t deliver, they give the same excuse. No one can say anything about it because the team is self-managing. Outsiders aren’t allowed to intervene. This faulty perception of Scrum must sting the creators of the framework.

Scrum isn’t like this. Instead, Scrum requires relentless commitment. Without this commitment from the Scrum Team and its stakeholders, Scrum isn’t effective.

I assume this is why they decided to be clearer in the new Scrum Guide by adding Commitments and Accountabilities. I like the emphasis on the two, but I don’t like how they implemented Accountabilities. Scrum Master, Developers and Product Owners all have their own accountabilities. But what about the Scrum Team? Shouldn’t the team be the prime focus? …

Scrum Masters Are Accountable For Things Beyond Their Control

Sarah is the Scrum Master for Scrum Team Desperados. She has observed how the team ignores using Sprint Goals, resulting in a lack of focus. They work on everything at once. Sprint after Sprint they fail to finish half of what they planned. Sarah is convinced a Sprint goal will help repair this.

She has presented her observations. She put a lot of effort into teaching and coaching the team to understand the importance of the Sprint Goal. But this is to no avail. The team doesn’t see the merits and regards it as extra work. …

On the power and deceptiveness of labels

The Scrum Guide 2020 has updates on many fronts. One of them is that as of now Scrum Teams are self-managing. This used to be self-organising. On the surface, this looks like a major change. The radicality of the change is confirmed when you compare the following two lines from the 2017 and 2020 guides:

“Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” — Scrum Guide 2017


“They [the Scrum Teams] are also self-managing, meaning they internally decide who does what, when, and how.” — Scrum Guide 2020

Reading these, the inevitable conclusion is that Scrum Teams now have more to say about their…

My First impression

The new Scrum Guide is out. I eagerly anticipated it, because it promised to be impactful. Ken Schwaber had stated that the SG would go from 19 to 13 pages. This is mind-blowing. Many already considered the previous Scrum Guide to be very condensed.

I did see some room to cut out the deadwood. For instance, I didn’t see why the Daily Scrum section needed the example of the three questions. I also didn’t see why we needed examples of how a Sprint Planning should be conducted. But 6 pages less is really something.

At the same time, I hoped that the Scrum Guide would add…

The fascinating search to find the answer to “Why Agile”

Why do we work “Agile”? This question may seem obvious, but many don’t know. They choose Agile for all kinds of wrong reasons, as you can see in the graph from The State of Agile 2020:

Image for post
Image for post
Reasons for adopting Agile — 14th Annual State of Agile Report 2020

It’s good to see that many understand Agile helps you manage the changing priorities. Most of the other arguments are great too. But the fact that “Accelerate Software Delivery” and “Increase Productivity” are in the top three is worrying. Although the first is open for multiple interpretations, I immediately think of teams working late to meet artificial deadlines.

It is important to understand why Agile exists. Only then people are in a position to make a conscious choice to adopt an Agile way of delivering their products. It prevents people from choosing it for the wrong reasons and will help us to get rid of the confusion of tongues. …

Information may arrive months later. Don’t let it stop you from bringing it up at the Sprint Review.

I love Sprint Reviews. At this event, empiricism works full throttle. The Scrum Team has added new potential value to the product Increment. Now the team and its stakeholders inspect the Increment and discuss what to do next.

The Sprint Review can be a powerful event to influence the direction of the product. But often Product Owners and their Scrum Teams waste excellent opportunities. They are in a vicious circle and only discuss the latest additions to the products. The stakeholders appear out of courtesy, not to help improve the product. …

There’s so much more to unpack

Scrum is everywhere. Almost everyone in the software development industry who has been working ‘Agile’ has worked with Scrum.

According to the State of Agile 2020, around 95% of the organisations polled practice Agile development methods.

Image for post
Image for post
State of Agile 2020

It doesn’t mean all teams in the organisations work ‘Agile’, but it is widely adopted. From all the teams using ‘Agile’, approximately 75% work with Scrum or a Scrum inspired approach.

And what does it mean for the Scrum Team if this is an issue?

The Scrum Guide (2017) is very clear that the Product Owner must optimize the value of work the Development Team does. But what does this mean exactly? Can a Product Owner hold the Development Team accountable for not keeping their promises? Is this part of the responsibility to optimize the value of the work?

When this is a loaded question, it tells something about how the Product Owner cooperates with the rest of the Scrum Team. Let me explain.

Image for post
Image for post
Image by Gerd Altmann from Pixabay

The Product Owner Role

If you consider all mentions of the Product Owner in the Scrum Guide, you notice a pattern. The Product Owner:

  • needs to ensure the team understands goals, product domain and…


Willem-Jan Ageling

Interested in ways to work better together. I love the discussion with open-minded people.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store