Scrum Basics - Easy to understand, surprisingly difficult to master

How did I come to this conclusion, and why has this realization even prompted me to start a blog series on the topic of "Scrum Basics"?

For many years I, Anna Rudat, have been working as a Agile CoachI have worked as a consultant, trainer or in one of the Scrum responsibilities (Product Owner, Scrum Master, Developer). In recent years, almost all of my assignments have involved scaled Scrum This means that it is about more than one Scrum team or the Scrum team works together with other Scrum teams on a product. On the one hand, I think this development is great and it shows that Scrum establishes itself as a framework. On the other hand, I keep noticing that most scaling doesn't run smoothly because the Scrum basics aren't in place.

Example of Scrum scaling

There are various reasons for this, one of which runs like a common thread: The individual Scrum teams have not yet really got Scrum up and running for themselves, i.e. at team level. Nevertheless, scaling is already underway. By this I mean that many Scrum basics are already not working properly in a single Scrum team.

That's not how it works

Let me illustrate this with a few examples:

1. Transparency is only practiced incompletely, sometimes even the product owner is not made aware of everything.
2. Scrum teams do not really review their actions honestly in sprint retrospectives, but use them as "vomit meetings"
3. Improvement measures from a retro are not checked for their effectiveness.
4. Scrum teams only adapt things superficially, but core problems remain, such as inadequate test environments/stations.
5. There is no room in the organization to build an agile culture; instead, roles and meetings are simply renamed.
6. The responsibilities in Scrum teams are not clearly understood or filled, there is a lack of Scrum Masters or there are duplicate responsibilities.
7. Sprints are adapted or their length is adopted without paying attention to the team's environment.
8. Sprint planning sessions take hours because they are not prepared or are kept short because topics from the last sprint were carried over because they were not completed.
9. In the Daily Scrum, three questions are mechanically prayed down without thinking about them.
10. Daily Scrum takes place without the Sprint Backlog.
11. No stakeholders who can really give feedback take part in the sprint reviews or the reviews take place internally without a PO.
12. The Definition of Done is not lived or does not even exist.
13. …

This list could be continued almost "endlessly". I have to stop myself even as I write.
Perhaps you also know such points?

Scrum basics - the foundation must be right

Under such conditions with regard to Scrum basics, it is almost impossible for Scrum teams to participate smoothly in scaling. On the contrary: these unclean basics often even hinder scaling and thus further Scrum teams.

In a small blog series on Scrum basics, I would like to support these teams by giving them ideas for solutions.

In my blog series, I would like to go through the entire Scrum framework. I will use the following illustration as a guide.

The Scrum Framework visualized

The first topic is "Daily Scrum", our smallest event in Scrum, which says so much about a Scrum team.

What topics move you? Please leave a comment.

Your Anna Rudat