70 Scrum Master Theses

TL; DR: The Scrum Master Theses

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

The theses cover the accountabilities 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.

70 Scrum Master Theses — Age-of-Product.com

🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.

Scrum Guide 2020 — Download the new edition of the Scrum Guide Reordered — Age-of-Product.com

The Scrum Master Theses in Detail

The Role of the Scrum Master

This first set of the Scrum Master theses addresses their role in the Scrum process. I am aware that the Scrum Guide 2020 substituted the roles with accountabilities. Nevertheless, speaking of the “role” of Scrum Masters is a suitable path to basic principles of Scrum mastery:

  • 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.
  • You need to determine for yourself what works for your organization — which is a process, not a destination.
  • The role of a Scrum Master is primarily one of servant leadership—or “true 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, for example, 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).

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:
    1. 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 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.)
    2. 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 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.

Cannot see the form?
Please click here

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 requires 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.

Sprint Retrospectives

The fifth set of the Scrum Master theses deals with Retrospectives:

  • “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.” (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 so that strategies may be devised 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 members of a Scrum Team 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 at any time 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 to 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 members of the Scrum Team 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 just temporarily using sticky notes. Though 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 addresses on agile metrics:

  • The purpose of metrics, generally, is to understand a current situation better and gain insight on 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 continuously improve, helping them achieve their goals:
    • Agile practitioners strive for autonomy, mastery, and purpose as explained by Daniel Pink.
    • Agile practitioners address personal development with metrics by applying methods like Objectives and Key Results (OKR).
  • The experienced agile practitioner realizes that autonomy and accountability are equally important for self-organized scrum teams. Without metrics, both autonomy and accountability 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 start with understanding the ‘why’: why should the organization become agile?
  • Reasons typically given by management for transitioning to scrum and other agile practices include:
    1. Making the organization more efficient;
    2. Helping the organization deliver faster; and
    3. Improving the predictability of delivery dates.
  • The recognized benefits of transitioning to Scrum and other agile practices are:
    1. Outperforming competitors by creating a learning organization;
    2. Creating a great workplace culture by providing room for autonomy, mastery, and purpose; and
    3. 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 size of the organization.
  • 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 goals of the organization — 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, it 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 the benefits of agile software development.
  • 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.

The Scrum Master Theses — The 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.

Update 2018-12-15: The Replay of the Webinar Scrum Master Anti-Patterns Is Available

The video of the webinar is available now:

Scrum Master Anti-Patterns — (Hands-on Agile Webinar #8)

Note: If the browser will not start the video automatically, click here to watch the replay of the webinar Scrum Master anti-patterns directly on Youtube.

📕 Now Available: ‘How to Get Hired as a Scrum Master’

Scrum Master Career: How to Get Hired as a Scrum Master: From Job Ads to Your Trial Day — Learn How to Pick the Right Employer or Client details how Scrum Masters and Agile Coaches can systematically identify suitable employers or clients to avoid mismatches and disappointments at a later stage. If you are planning a career move into the Scrum Master profession, don’t miss out on these tips.

Scrum Master Career: How to Get Hired as a Scrum Master by Age-of-Product

Scrum Master Career: How to Get Hired as a Scrum Master is currently available as a Kindle ebook. Shortly, the paperback version will be available, too.

Scrum Master Interview Question: free download of the most popular ebook on Scrum Master job interviews — by Age-of-Product

📖 The Scrum Master Theses — Related Posts

The Scrum Master Trends Report 2019

The Scrum Master Salary Report 2017

Download the ’Scrum Anti-Patterns Guide’ for Free

Scrum Master Anti-Patterns — 20 Signs Your Scrum Master Needs Help

Peer Recruiting: How to Hire a Scrum Master in Agile Times

22 Scrum Master Anti-Patterns from Job Ads

Lipstick Agile — 15 Signs You Probably Need a New Job or to Roll-up Your Proverbial Sleeves

Speaking Truth to Power 2.0 — Taking A Stand as an Agile Practitioner

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

Date Class and Language City Price
🖥 💯 🇩🇪 September 26-29, 2023 GUARANTEED: Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 💯 🇬🇧 October 4, 2023 GUARANTEED: Professional Scrum Facilitation Skills Training (PSFS; English; Live Virtual Class) Live Virtual Class €749 incl. 19% VAT
🖥 💯 🇬🇧 October 10, 2023 GUARANTEED: Hands-on Agile #54: Product Backlog Management Traps — David Pereira (English; Live Virtual Meetup) Live Virtual Class FREE
🖥 🇩🇪 October 30-31, 2023 Professional Scrum Master (Advanced) Training (PSM II; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 💯 🇩🇪 November 1-2, 2023 GUARANTEED: Professional Scrum Master Training (PSM I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 💯 🇬🇧 November 8, 2023 GUARANTEED: Hands-on Agile #55: Designing Agile Ecosystems with Org Topologies™ w/ Alexey Krivitsky and Roland Flemm (English; Live Virtual Meetup) Live Virtual Class FREE
🖥 🇩🇪 November 21-24, 2023 Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 💯 🇬🇧 November 28, 2023 GUARANTEED: Professional Scrum Facilitation Skills Training (PSFS; English; Live Virtual Class) Live Virtual Class €749 incl. 19% VAT
🖥 🇩🇪 December 11-12, 2023 Professional Scrum Master Training (PSM I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 🇩🇪 December 13-14, 2023 Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 🇬🇧 December 18-19, 2023 Professional Scrum Master (Advanced) Training (PSM II; English; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT

See all upcoming classes here.

Professional Scrum Trainer Stefan Wolpers

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.

✋ Do Not Miss Out and Learn more about the Scrum Master Theses: Join the 12,000-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

Join the Hands-on Agile Slack Group

If you like to join, all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Find this content useful? Share it with your friends!

6 thoughts on “70 Scrum Master Theses”

  1. I also think, “Being a scrum master does not entail, and should never entail, enforcing processes.” has to be further specified.

    I – as SM – don’t put any value on “enforcing processes”. I don’t think I could do my job as coach/mentor, when the team thinks of me as some kind of Scrum Guardian. Also when aiming for management I would have chosen a different job – but to organization who puts the SM in place has expectations about the process.

    (Really) self-organized teams could very quickly modify every aspect of scrum when not slowed down by anyone.

    Exaggeration:
    SM: “…then it’s not scrum”
    DevTeam: “Why?”
    SM: “…uhm…trademarks?”
    DevTeam: “Daily Situps for the PO, Planning Poker becomes just Poker, Aggrospectives and the testers have to go. Plus: We’ll still call it scrum – sue us.”
    And – the other way round:
    PM: “…and I want this to be finished on friday.”
    SM: “Sorry, we had a planning where this wasn’t mentioned. It’s not a small effort either, and according to scr…”
    PM: “I was talking to the people who actually develop something. Go fetch the scrum police should you oppose.”

  2. I too wanted to discuss: Being a scrum master does not entail, and should never entail, enforcing processes.

    My personal take is that there are times when it is both useful and appropriate for a SM to “stick to process” – mostly when a team is in Shu.

    While there is value in learning by “failing” – there are times there’s potentially more damage to be done if the training wheels are taken off too early…

    “Never entail” perhaps too strong …

    How about “Not mindlessly”

  3. Thanks for sharing. Your material is really helping me and the teams forward. If there is anything we can do to contribute in return, feel free to reach out!

  4. Thanks a lot for your feedback, Sjoerd!

    @1: That is the usual approach. To my experience, with most teams, it will work out in the end. However, some people are not willing to embrace agile practices, and they will let you know in the process. I believe that even in this case, a scrum master shall not enforce processes even if that means that the team in question in its current composition may not adapt Scrum.

    @2: If the team is in control that approach might work. If the problem is a result of the organizational structure, the team will have little influence on that in the short term.

  5. Hi Stefan,

    These theses are really helpful!
    Would you also mind sharing a bit more on:

    “Being a scrum master does not entail, and should never entail, enforcing processes.”

    in relation to the scrum guide:

    “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety”

    and

    “Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.”

    I interpret it as such:

    “A scrum master shouldn’t enforce, but instead demonstrate the value of upholding the empirical process control of transparency, inspection, and adaptation”.

    What are your thoughts on this?

    Then on: “A cross-functional and 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 department.”

    This is often indeed the case. In my view, Scrum teams should strive to being more cross-functional in such scenario, ie. steps towards making it an integrated whole, to be able to deliver working increments. The team can list certain dependencies as DoRs and the Scrum Master could strive to resolve dependencies if they become an impediment. Given this thesis, I am wondering what stance a Scrum Team could take (according to you).

    Thanks!

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.