70 Scrum Master Theses

(Germany)

October 13, 2020

TL; DR: 70 Scrum Master Theses

The following 70 Scrum Master theses describe the role of from a holistic product creation perspective.

The theses cover the role of the Scrum Master from product discovery to product delivery in a hands-on practical manner. On the one side, they address typical Scrum events such as Sprint Planning, Sprint Review, and the Sprint Retrospective. On the other hand, the Scrum Master Theses also cover, for example, the relationship with the Product Owner, they deal with agile metrics, and how to kick-off an agile transition, thus moving beyond the original framework of the Scrum Guide.

Do you want to get this article in your inbox? You can sign up here and join 27k other subscribers.

📅 November 19, 2020: If you use Scrum then join the free Hands-on Agile meetup—it will be worth your time!

The Role of the Scrum Master

This first set of the Scrum Master theses addresses their role in the Scrum process:

Scrum is not a methodology but a framework. There are no rules that apply to each scenario — just good practices that have worked before in other organizations.
The good practices of other organizations cannot simply be copied to your own. Every good practice requires a particular context to work.
As somebody hiring for a Scrum Team, you need to determine what works for your organization — which is a process, not a destination.
The role of a Scrum Master is primarily one of servant leadership and coaching. It is not a mere management role. (Although the Scrum Master role also has management aspects, for example, regarding the responsibility for promoting and supporting Scrum within the organization.)
A Scrum Master should recognize that different stages of a Scrum Team’s development require different approaches: some, teaching; some, coaching; and some, mentoring.
A Scrum Master should know of the Shu -Ha -Ri (Japanese martial arts) method of learning new techniques.
A Scrum Master’s principal objective should be to remove themselves from daily operations by enabling the Scrum Team to be self-organizing.
Being a Scrum Master does not entail, and should never entail, enforcing processes.
Scrum is not designed for bean counters, although some metrics help understand a Scrum Team's health. Generally, insisting that the team achieve specific KPI, e. g. forecasts vs. velocity does not help.

Scrum doesn’t elaborate on the process that enables a Product Owner to add valuable, usable, and feasible work items such as features to the Product Backlog. Product discovery using the Design Thinking, Lean Startup, or Lean UX frameworks help. Still, in any case, a good Scrum Master will want the Scrum Team to be a part of this process (whether by participating in user interviews or running experiments).

Download the 47 Scrum Master Interview Questions to Identify Suitable Candidates

Product Backlog Refinement and Estimation

The second set of the Scrum Master theses focuses on the importance of the Product Backlog refinement:

Product Backlog refinement and estimation are essential tasks for every Scrum Team. Although the Product Owner (at least officially) is in charge of keeping the Product Backlog at ‘peak value delivery,’ they need the assistance of the entire Scrum Team to do so.
A cross-functional — be it distributed or co-located — Scrum Team working independently of other teams is an ideal scenario. The reality is that most Scrum Teams will often be dependent upon deliveries from other teams (e.g., API endpoints) and deliverables from the UX or UI people if those are not embedded within a Scrum Team.
There are two essential ingredients for good Scrum Team performance:
- Writing user stories as a team. When a new feature should be built, the Product Owner first explains why and provides the necessary background (i.e., market intelligence, results from experiments, user interviews, statistical data). Writing user stories, then, is a collaborative effort involving the entire Scrum Team. The process should create a shared understanding of what will be built and for what reasons (the Product Owner providing the ‘why,’ the Scrum Team detailing the ‘how,’ both negotiate the ‘what’), and a shared sense of ownership among team members. A good team will always challenge the Product Owner whether a proposed functionality is indeed the best use of the Development Team’s time. (Please note that not all Product Backlog items are user stories. For example, there are also bugs, spikes, or non-functional requirements that do not fit into the user story template.)
- Keeping technical debt at bay. When a weak Development Team meets a commanding Product Owner, focusing on shipping new features, the team may end up as a feature factory, churning out new code while neglecting the technical foundation. A good Scrum Team pays attention to preserving an application’s technical health to ensure the Scrum Team is ready actually to pursue an opportunity in the market. (Read more: Technical Debt & Scrum: Who Is Responsible?)
A well-refined Product Backlog probably has work items detailed for about two or three Sprints in various refinement stages. There may also be additional work items that no one except the Product Owner is working on.
Product Backlog refinement is a continuous process involving the Product Owner, the Development Team members, and probably subject matter experts or stakeholders.
A Product Backlog is “actionable” if the Scrum Team can organize a successful Sprint Planning at a moment’s notice.

Sprint Planning

The third set of the Scrum Master theses covers the Sprint Planning:

It used to be that a Product Owner would explain high-value user stories to the Scrum Team during Sprint Planning. The Scrum Team would then turn these into more detailed work items and probably the subsequent task. However, there is now a consensus among practitioners that working on these high-level user stories continuously in a separate Product Backlog refinement process — during the Sprint — actually improves the quality of the items and thus the outcome of the team’s work.
Sprint Planning creates a sense of ownership among a Development Team's members by enabling them to make a valid forecast regarding the Sprint Goal and, subsequently, the Sprint Backlog composition. But this only happens if a Scrum Team is certain about the quality of the Product Backlog items in question.
It is the development team members' prerogative to pick the Product Backlog items that compose the Sprint Backlog. No one can force work upon the Development Team.
If Product Backlog refinement is handled well, an entire Sprint Planning session might be completed within 2 or 3 hours.
A productive Sprint Planning requires a healthy Scrum Team. Dysfunctional teams will not achieve the level of cooperation required. Sprint Planning with dysfunctional teams will only result in a futile and painful exercise.
A Scrum Team should usually avoid allocating more than 80% of their capacity to working on new tasks — including user stories, technical tasks, bugs, and probably spikes. Flow theory shows that a 90% or higher allocation of available capacity will not lead to a team achieving their peak performance. A high-performing Scrum team needs slack time to be prepared for the unexpected or share knowledge among themselves.
Bugs, refactoring, and research require regular attention to avoid building-up technical debt. An effective Scrum Team allocates approximately 20 to 25% of their capacity to these tasks.
Incomplete and poorly prepared work items seriously hamper the effectiveness of a Scrum Team. These items should never be selected for the Sprint Backlog but instead sorted out during Product Backlog refinement meetings.

Daily Scrum

The fourth set of the Scrum Master theses addresses the Daily Scrum:

Daily Scrums events are essential to discuss a current Sprint’s progress: is all going as planned, or does the Development Team need to adjust its approach to accomplish the Sprint Goal?
Daily Scrums cannot fix — and is not supposed to fix—, among other things: a dysfunctional organization, a dysfunctional Scrum Team, an inadequate Product Backlog, a Sprint Planning session gone wrong, low-quality user stories, or a missing product vision.
It is the development team's prerogative to decide on the best way of handling their Daily Scrum event.
The more experienced a Scrum Team, and the better the internal communications, the more a Daily Scrum might be seen as a time-consuming ritual of little value.
An advanced Scrum Team may consider virtual meetings instead of real meetings using, for example, a Slack channel.
Just saying: A two-person Scrum Team probably does not need a formal Daily Scrum — meeting regularly for coffee would be a practical alternative.
There is something wrong with a Scrum Team who does not communicate impediments to their Scrum Master before each Daily Scrum.
Daily Scrums are not reporting sessions for the benefit of the Product Owner or participating stakeholders.
Offline boards are valuable: physically taking a card and moving it instills certain ownership of a work item.

Download the Scrum Guide Reordered for Free

Sprint Retrospectives

The fifth set of the Scrum Master theses deals with the Sprint Retrospective:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” (Source.)
Retrospectives should encourage self-expression, thereby making it easier for a Scrum Team to uncover the concerns and frustrations that its members may be harboring to devise strategies to overcome them. (Learn more on Retrospectives.)
Retrospectives will only improve a team’s collaboration and performance if the team considers these meetings a safe place to provide honest and constructive feedback.
The blame game is hence not helpful. During a Sprint Retrospective, the Scrum Team members should focus on how to improve a situation — and avoid blaming one another.
There are various dedicated applications available to support Retrospectives with distributed Scrum Teams.
Alternatively, a Scrum Master can handcraft a Retrospective format using Liberating Structures — which works well for co-located and distributed Scrum Teams.
It’s best not to hold Sprint Retrospectives at a team’s workplace. Distance makes it easier for team members to reflect on the Sprint. It’s also helpful to regularly change locations for the meeting. Being in a new locale helps prevent boredom (and team members ‘checking out’ completely).
The format for a Scrum Team’s Sprint Retrospectives should be changed regularly. (Read more: Retrospective Exercises Repository.)
For co-located Scrum Teams, Smartphones, tablets, and laptops should not be permitted at Sprint Retrospectives so that the Scrum Team members are not distracted and can focus on contributing to the meeting.
According to Diana Larsen and Esther Derby in their book Agile Retrospectives: Making Good Teams Great, there are five stages to running a Sprint Retrospective: setting the stage, gathering data, generating insights, deciding what to do, and closing the Sprint Retrospective.
All issues, concerns, and frustrations should be documented — even if temporarily using sticky notes. However, it’s always better to keep a formal document or file. (Limit access to these documents to the Scrum Team members, though.)
A Sprint Retrospective should set SMART goals for action items (the tasks to be done):
Action items should be specific and measurable (“do X more often” does not meet that criteria).
A single member of the Scrum Team should be made responsible for each action item.
Each action item should include a forecast of when results can be expected.
Action items should be placed on a board to make tracking progress visual and more prominent.
Every new Sprint Retrospective should start with reviewing the status of the action items decided upon during the previous Sprint Retrospective.

Don’t forget to includes stakeholders in meta-level Retrospectives from time to time.

Agile Metrics

The sixth set of the Scrum Master theses focuses on metrics:

Generally, the purpose of metrics is to understand a current situation better and gain insight into how it’s likely to change over time.
A good metric is a leading indicator for a pattern, providing an opportunity to analyze the cause for change — and act appropriately in due course.
Metrics in an agile context are not used to manage, and certainly not micromanage, an individual (particularly the creative worker) — contrary to traditional command-and-control management structures.
Metrics in an agile organization should be used to provide the Scrum Team with insights on how to improve, helping them achieve their goals continuously:
- Agile practitioners strive for autonomy, mastery, and purpose, as explained by Daniel Pink.
- Agile practitioners address personal development with metrics by applying practices like Objectives and K ey R esults (OKR).
The experienced agile practitioner realizes that autonomy and responsibility are equally important for self-organized Scrum Teams. Without metrics, both autonomy and responsibility are limited.
The metrics most suitable reflect either a team’s progress in becoming agile or the organization’s progress in becoming a learning organization.
Both qualitative and quantitative metrics may be used for Scrum:
- Qualitative metrics typically reveal more than quantitative metrics when applied to the Scrum Team.
- Quantitative metrics provide more insight than qualitative metrics when applied to the organization.
Any agile metric used must be tailored to the organization.
The metrics that Scrum Masters should track are only those that apply to the Scrum Team as a whole. Metrics that measure the individual should be ignored.
A metric’s context should always be recorded to avoid misinterpretation.
Parameters that are easy to follow should not be measured for that reason alone — especially if a report is readily available in the project management software being used.

How to Kick-off a Transition to Scrum

The seventh set of the Scrum Master theses covers agile transitions:

There is no checklist or master plan readily available that would ensure a successful transition to Scrum.
The ‘best practices’ of and ‘lessons learned’ by other organizations may indicate a direction to take when transitioning, though the context of their transition may not be comparable: what worked for Spotify may not work for General Motors.
Every transition to Scrum should understand the ‘why’: why should the organization become agile?
Reasons typically given by management for transitioning to Scrum and other agile practices include:
- Making the organization more efficient;
- Helping the organization deliver faster; and
- Improving the predictability of delivery dates.
The recognized benefits of transitioning to Scrum and other agile practices are:
- Outperforming competitors by creating a learning organization;
- Creating a great workplace culture by providing room for autonomy, mastery, and purpose; and
- Mastering continuous product discovery and delivery (thus minimizing risk).
Agile and its benefits need to be sold to an organization before beginning its transition to Scrum — Agile is not everybody’s darling, and personal agendas of individuals will likely affect a transition.
A transition to Scrum will encounter inertia and resistance to change directly proportional to the organization's size.
How a transition to Scrum should be undertaken depends upon many factors, including an organization’s industry, regulations and compliance rules, the size and age of the organization, workplace culture, the maturity of an organization’s products and services, team size, and current project management practices.
How a transition to Scrum is undertaken should be determined by the organization's goals — what is hoped to be achieved.
A successful transition to Scrum requires the backing of C-level executives; a bottom-up approach is futile.
The first step of any transition to Scrum is the creation of the first Scrum Team.
Transitioning to Scrum requires training and educating the entire organization — not just future Scrum Team members — in agile practices and principles. Training and education are essential for a successful transition.
There is a huge difference between ‘doing Agile’ and ‘being agile.’ Transitioning to Scrum successfully means becoming — and being — agile.
In an organization transitioning to Scrum, future Scrum Masters should be agents of change rather than drill sergeants — this is by design, given their lack of proper authority.
Creating a ‘happy agile island’ for the product and engineering department is a valid objective. However, in comparison to breaking up functional silos and creating a learning organization, a team of teams is likely to deliver a lesser return on investment.

Scrum Anti-Patterns

The last set of the Scrum Master theses deals with Scrum anti-patterns:

Humans are fallible, so with this propensity for error, there will always be room for (professional) improvement – including Scrum Masters.
Anti-patterns will emerge when core principles (as laid out in the Manifesto for Agile Software Development and the Scrum Guide ) are ignored, made to fit existing structures, or watered down.
The deterioration of principles may be a deliberate process (creating a form of cargo cult agile), unintentional, or a result of good intentions applied in the wrong way.
Whatever the deterioration process, emerging anti-patterns will prevent an organization from reaping agile software development benefits.
Recognizing Scrum and agile anti-patterns is therefore fundamental in the effort for serious, continuous improvement.
Anti-patterns can be identified by observation, Sprint Retrospectives, and other forms of feedback generating activities.

Read More: The “Scrum Anti-Patterns Guide” covers more than 160 Scrum anti-patterns that can block your Scrum Team’s improvement.

Conclusion

To be a successful Scrum Master, you will need to have a holistic understanding of the product creation process. You will also need to deal extensively with organizational impediments and constraints while training the organization’s members and looking for prospective change agents that may join your course. You need to sell ‘agile.’ You need to win hearts & minds within the organization to overcome its inherent resistance to change. Hence, by merely organizing Scrum events and ordering new stickies, you will self-impose a limit on your career as a Scrum Master that will ultimately keep stuck in a ‘Scrumbut’ situation, wasting much of Scrum’s potential.

Which relevant Scrum Master theses are missing to describe the role in a better way? Please share with me in the comments.

What did you think about this post?

Share with your network

Blog Comments