TL;DR: The Scrum Master Theses
The following 70 Scrum Master theses describe the role 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.
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:
- Scrum is not a methodology, but a framework. There are no rules that apply to each and every 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 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 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 are helpful in understanding the health of a Scrum Team. 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, but 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:
- a) 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. There are, for example, also bugs, spikes, or non-functional requirements that do not fit into the user story template.)
- b) 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 the preservation of an application’s technical health to ensure the Scrum Team is ready to actually pursue an opportunity in the market. (Read more: Tweet