The quality of the software is a responsibility of the entire team. The Product Owner is responsible for building the right thing. Ensuring we build the thing right is the main responsibility of the development team. Scrum Masters serve a key role in achieving both aspects. A Scrum Master serves the team by coaching members in self-management and cross-functionality, helping them focus on creating high-value increments, and removing impediments. Sounds great, and abstract, so let us dive in with some practical examples.
Refinements are meant for learning and clarifying the team’s understanding of what they are asked to build. The more successful the team is in reaching this shared understanding, the better the delivery of the feature will be.
it is not the domain expert’s knowledge that goes into production, it is the developer’s assumption of that knowledge that goes into production
– Alberto Brandolini
The methods used to refine work can be highly influential in gleaning this shared understanding. Most refinements will have a form of feature presentation, followed by some Q&A between the team. Visuals and wireframes help to improve understanding. However, for some processes this simply will not work: administrative processes, for example. We love to use visual collaboration methods for this kind of work.
Example mapping is a popular method for clarifying and conforming the requirements of a user story. It is a short and visual way to structure the refinement conversation. A second method (although it is a bit more complex in facilitation) is Event Storming. This is a terrific way to align the language and understanding of business processes, bringing subject-matter experts and the development team together for a shared sense of reality.
Being able to facilitate these methods as a Scrum Master helps the team to make better assumptions on the problem. Better assumptions result in higher-quality delivery of the product. It is important for refinement that the whole team is available, not just a part of it. Running a Three Amigos (product owner, developer, tester) session is not suggested as it fosters ranking and misalignment.
Some techniques can be facilitated by any member of the group. Example Mapping can be run by anyone, without harming neutrality of the facilitator. In this case the Scrum Master can learn and coach the team to run the intervention. For an Event Storm or User Story Mapping it is better to have a neutral facilitator. The Scrum Master can fulfill this role perfectly, allowing all team members to actively participate.
A Scrum Master is often concerned with an interesting mix of people, embodying both technological and managerial components. Technology here being the broad definition of techniques, skills, methods, and processes used in the production of goods or services. A Scrum Master guides and coaches the team in self-management and to have focus on creating high-value increments. In other words, Scrum Masters are heavily involved in designing and evolving socio-technical systems. A pronounced example of this is in facilitating decision-making, perhaps when the team must make an architectural decision, or a product vision. Making decisions is essential and part of the team’s responsibilities. The Scrum Master can help facilitate the decision-making process that allows everyone to speak up, raise their concerns, and play their part in adhering to the made decision.
Decision-making is a tedious process. By that we mean making decisions where everyone can raise their concerns and feel part of the process. It might feel simple to make decisions, but many elements play a role here: there might be biases in the proposed options. Ranking between the team members can influence the chosen decision, and unspoken pressures can influence how they get to that decision. Proper facilitation of the decision-making process can overcome these biases, influences, and other social factors. Using methods and philosophies from Deep Democracy can help in making decisions and handling resistance.
Using sensemaking can be an immense help in determining whether the decision is supported by the entire group. It helps in searching for the things that are not said: gut feelings, worries, or any other form of concerns. It also helps in making sustainable decisions or growing the buy-in towards the made decision.
Teams should have, and adhere to, a Definition of Done. The Definition of Done is when all conditions that a software product must satisfy are met and it is ready to be accepted by a user. It is not about ticking the checkboxes of the process; it addresses the actual outcome. It is the Scrum Master, in a neutral role, that can question the correctness and adherence of the Definition of Done.
When drafting a Definition of Done, language is important. It might feel like there is not much difference between “unit tests performed” or “unit tests passed,” but there is. The first one is about a step in the process, the latter is about the outcome of that process.
A good Definition of Done also addresses the quality attributes of a product. Elements of the DoD should address items that are related to the performance, security, usability, and maintainability of the product. By extension it should align with the quality narrative of the organization. Is a high-quality product one that has zero bugs, or one that allows for evolution and experimentation? Quality can be ambiguous and should be made explicit by organization and team. The Definition of Done should reflect the quality attributes expected from the delivered product.
Many teams hold sprint retrospectives, often facilitated by the Scrum Master. The dialogue, insights and actions that come from a retrospective have major influence on the quality of the software product and delivery. For a Scrum Master it is important to structure and facilitate the retrospective well, allowing information and ideas to flow from all members of the team. Fun Retrospectives is a great resource for different formats to use in a retro.
In this article we have outlined some of the ways a Scrum Master can influence the quality of the delivered product. For us, it involves the facilitation of dialogues to better understand what is requested—either by the team or the stakeholders. Being a Devil’s Advocate where you can, by sharing your observations and gut feelings about situations. By doing this you enable the team to improve its practices and ability to deliver high-quality software. Want to have more inspiration? Read our other blogs on software quality.