Stefan Wolpers November 23, 2020 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: Technical Debt & Scrum: Who Is Responsible?)
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. There is now, however, 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 composition of the Sprint Backlog. But this only happens if a Scrum Team is certain about the quality of the Product Backlog items in question.
- It is the prerogative of the Development Team members 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 in order 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 prerogative of the Development Team 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 prior to 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.
- 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.
- 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.
Don’t forget to include 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.
Business & Finance Articles on Business 2 Community
(31)
