The fourth set of the Scrum Master theses addresses standups:
- Standups are meetings well suited to discuss a current Sprint’s progress: is all going as planned, or does the Scrum team need to adjust?
- Standups are a convenient time for a Scrum team to meet and communicate with a project’s or product’s stakeholders.
- Standups cannot 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.
- Standups are valuable if the Scrum team is already collaborating well and the basics — such as the product backlog, and sprint planning — are in order.
- The more experienced a Scrum team, and the better the internal communications, the more a standup will seem 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.
- A two-person Scrum team does not necessarily need a formal standup — meeting for coffee would be a practical alternative.
- There is something wrong with a Scrum team whose members do not communicate impediments before each standup. It’s possible they’re acting more like a group of people being in the same place at the same time pursuing a similar goal than a Scrum team.
- Standups are not reporting sessions for the benefit of product owners or participating stakeholders.
- Offline boards are valuable: physically taking a card and moving it instills a sense of ownership of a user story. (This is the same mental model that explains why sales-people want you to touch the merchandise before a purchase.) If you must let go of either an online or offline board and you are a co-located team, consider letting go of the online board.
The fifth set of the Scrum Master theses deals with retrospectives:
- 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 not helpful. During a retrospective, the members of a Scrum team should focus on how to improve a situation — and avoid blaming one another.
- Some Scrum teams always include the product owner in their retrospectives, while other teams insist that the product owner should be expressly invited.
- It’s best not to hold 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’).
- The format for a Scrum team’s retrospectives should be changed regularly. The same format should not be run more than twice.
- Smartphones, tablets, and laptops should not be permitted at retrospectives so that the members of the Scrum team are not distracted, and can focus on contributing to the meeting.
- 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.
- According to Diana Larsen and Esther Derby in their book, “Agile Retrospectives: Making Good Teams Great,” there are five stages to running a retrospective:
- Setting the stage
- Gathering data
- Generating insights
- Deciding what to do
- Closing the retrospective
- A 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 an estimate of when results can be expected.
- Action items should be placed on a board to make tracking progress visual and more prominent.
- Every new retrospective should start with reviewing the status of the action items decided upon during the previous retrospective.
The sixth set of the Scrum Master theses addresses 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 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 — Agile practitioners all — 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 to Agile reflect either a team’s progress in becoming Agile or the organization’s progress in becoming a learning organization.
- Both qualitative and quantitative metrics are used:
- 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 metric used for Agile must be tailored to the organization.
- The metrics that the Scrum Master should be tracking are only those that apply to the Scrum team. 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, or that could be made readily available, that would ensure a successful transition to Agile practices such as Scrum. This also applies to SAFe, LeSS, Nexus, DAD, XSCALE, or the so-called ‘Spotify methodology.’
- The ‘best practices’ of and ‘lessons learned’ by other organizations during their transition to Scrum 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 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:
- Making the organization more efficiently.
- Helping the organization deliver faster.
- 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.
- Mastering continuous product discovery and delivery (thus minimizing risk).
- Agile practices’ benefits need to be sold to an organization before beginning a transition — Agile is not everybody’s darling, and personal agendas will be affected by a successful transition.
- A transition will encounter inertia and resistance to change directly proportional to the size of the organization.
- How an Agile transition 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 sizes and the number of teams, and current project management practices.
- How a transition is undertaken should be determined by the goals of the organization — what is hoped to be achieved.
- A successful Agile transition 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 Agile practices requires training and educating most members of an organization — not just future Scrum team members — in Agile practices and principles. Training and education are essential for a successful transition. Read more: Prototyping with Absolute Beginners
- There is a huge difference between ‘doing Agile’ and ‘being agile.’ Transitioning 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, it is likely to deliver a smaller return on investment.
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 need to be a part-time Agile Coach, too, dealing with organizational impediments and constraints, while training other members of the organization and looking for prospective change agents that may join your course. You need to sell ‘Agile.’ You need to win hearts and minds within the organization to overcome its inherent resistance to change. Hence, organizing Scrum ceremonies is just a small part of a Scrum Master’s job.
Which relevant Scrum Master theses are missing to describe the role in a better way? Please share with me in the comments.