Should you check a team’s health during a Sprint Retrospective, or is doing so unnecessary? If you do, how would you go about it?
Measuring the health of a Scrum Team — that is, getting an idea about current levels of engagement and satisfaction — is useful for identifying trends that may affect productivity and team cohesion.
For example, one effective method of measuring the health of a Scrum Team is to circulate an anonymous multiple-choice questionnaire before the team’s Sprint Retrospectives. A questionnaire that requires just two minutes to complete and uses a simple scale for each of the questions — from 1 (terrible) through 2 (poor), 3 (neutral), 4 (good), to 5 (excellent) — is usually well-suited.
During the Sprint Retrospective, the team should discuss the results with an aim to uncover any concerns or frustrations they may be harboring. (See above, gathering data.)
What anti-patterns do you know of that can happen during a Sprint Retrospective?
Typical Scrum Sprint Retrospective anti-patterns are:
Waste of time: The team does not collectively value the Sprint Retrospective. If some team members consider the Sprint Retrospective to be of little or no value, it is most often the Sprint Retrospective itself that sucks. Is it the same procedure every time, ritualized and boring? Have a meta-Sprint Retrospective on the Sprint Retrospective itself. Change the venue. Have a beer- or wine-driven Sprint Retrospective. There are so many things a Scrum Master can do to make Sprint Retrospectives interesting and valuable again, reducing the absence rate. Furthermore, it is good to remember that (in my experience) introverts like to take part in Sprint Retrospectives also.
Prisoners: Some team members only participate because they are forced to team up. Don’t pressure anyone to take part in a Sprint Retrospective. Instead, make it worth their time. The drive to continuously improve as a team needs to be fueled by intrinsic motivation, neither by fear nor by order. Tip: Retromat’s “Why are you here?” exercise is a good opener for a Sprint Retrospective from time to time.
Groundhog day: The Sprint Retrospective never changes in composition, venue, or length. In this case, the is that the team will revisit the same issues over and over again – it’s like Groundhog Day without the happy ending.
Let’s have it next Sprint: The team postpones the Sprint Retrospective into the next Sprint. Beyond the “inspect & adapt” task, the Sprint Retrospective serves as a moment of closure, helping reset everybody’s mind so that the team can focus on the new Sprint goal. That is the reason why we have the Sprint Retrospective before the planning of the follow-up Sprint. Postponing it into the next Sprint may also interrupt the flow of the team, and delay tackling possible improvements by up to a Sprint. This is why it is important to have the Sprint Retrospective before the planning of the follow-up Sprint.
#NoDocumentation: No one is taking minutes for later use. A Sprint Retrospective is a substantial investment for many reasons and should be taken seriously. Taking notes and photos supports the process.
No psychological safety: The Sprint Retrospective is an endless cycle of blame and finger-pointing. The team wins together, the team loses together. Unfortunately, the blame game documents both the failure of the Scrum Master as the facilitator of the Sprint Retrospective as well as the team’s lack of maturity and communication skills.
Bullying: One or two team members are dominating the Sprint Retrospective. This communication behavior is often a sign of either a weak or uninterested Scrum Master. The Sprint Retrospective needs to be a safe place where everyone–introverts included–can address issues and provide their feedback free from team members who are dominating the conversation, bullying or intimidating other teammates. The failure to provide a safe place will result in participants dropping out of the Sprint Retrospective and render the results obsolete. It is the main responsibility of the Scrum Master to ensure that everyone can be heard and has an opportunity to voice their thoughts. According to Google, equally distributed speaking time fosters and signifies a high-performing team. Read More: “What Google Learned From Its Quest to Build the Perfect Team.”
Stakeholder alert: Stakeholders participate in the Sprint Retrospective. There are plenty of Scrum events that address the communication needs of stakeholders: the Sprint Review, the Product Backlog refinement, the Daily Scrum events – not to mention opportunities of having a conversation at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities is still not sufficient, feel free to have additional meetings. However, the Sprint Retrospective is off-limits to stakeholders.
Passivity: The team members are present but are not participating. There are plenty of reasons for such a behavior: they regard the Sprint Retrospective as a waste of time, it is an unsafe place, or the participants are bored to death by its predictiveness. The team members may also fear negative repercussions should they be absent, or maybe a homogenous group of introverts was unwittingly hired. Whatever the reason, there is likely no quick fix. The Scrum Master needs to determine what style of Sprint Retrospective will work best in their organization’s context.
The Scrum Master Role as a Contradiction?
The Agile Manifesto infers people over processes. Isn’t a Scrum Master — whose role is meant to “enforce” the process — therefore a contradiction?
Scrum Masters do not wield any real authority but act as servant leaders. The Scrum Team does not report to them. This question is meant to help reveal whether your candidate understands that their role is to lead — as opposed to manage — the team. Asking this question is also likely to reveal why your candidate is interested in the role of a Scrum Master in the first place.
Acceptable answers should emphasize facilitation and support, for example:
“I am the servant-leader for the Scrum Team. It’s my job to make them successful.”
“I am neither a project manager nor a people manager. I support the Scrum Team in achieving self-organization. I do not tell people what to do.”
“I am the Scrum Team’s facilitator as teacher, coach, or mentor, encouraging them to excel as a team.”
The Product Owner for your Scrum Team frequently turns requirements documents received from stakeholders into tickets and asks you to estimate each. How do you feel about this procedure?
A Product Owner should not take this shortcut and turn requirements documents received from stakeholders into work items, and a Scrum Master should never accept such a procedure. It’s nothing more than a waterfall process dressed-up as a pseudo-agile practice.
If an organization is supposed to focus on delivering value to its customers, it is essential that any process involving ’requirements’ being handed down to its engineers by a project manager be abandoned. It makes no difference if the project manager is posing as a Product Owner. Instead, the organization should start including everyone in the product discovery process, thereby ensuring a shared vision of what needs to be built.
Should a Product Owner assign user stories or tasks to individual members of a Development Team?
A Product Owner individually assigning user stories to members of a Development Team is not Scrum, and if a Product Owner is doing this they need to be stopped. Development Teams are self-organizing. The assignment of user stories and the distribution of tasks among the members of a Development Team is the prerogative of the team itself. Preventing this anti-pattern should be one of the Scrum Master’s most pressing concerns.
How do you handle team members who ‘lead’ Daily Scrums, turning the event into a reporting session for themselves?
There are no leadership roles in the Development Team. However, it’s not uncommon for some members of a Development Team to assume leadership. This typically happens when a particular team member possesses superior (technical) expertise, communication skills, or simply a greater level of engagement.
All teams go through Tuckman’s stages of team development: forming, norming, storming, and performing. Scrum Teams are no exception.
It’s important that when a member of a Development Team assumes leadership this does not result in other members reporting to them. A Scrum Master must be vigilant and intervene if necessary to ensure that all team members communicate and work together — during Daily Scrums and otherwise — in the spirit of Scrum.
What do you understand by the term Sprint? What is its duration?
A Sprint is heart of Scrum. Sprint is a time boxed container which has all 4 mandatory events Sprint Planning, Daily Scrum, Sprint Review & Retrospective. It’s a repeatable event of maximum 1 month or less during which Team delivers a potentially releasable software or solution.During the Sprint:
No changes are made that would endanger the Sprint Goal
Quality goals do not decrease
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.
The Product Owner of your Scrum Team tends to add ideas of all kinds to the Product Backlog as a reminder to work on them at a later stage. Over time, this has led to over 200 items in various stages. What are your thoughts on this? Can a Scrum Team work on 200 Product Backlog items?
Any Product Backlog larger than the scope of two or three Sprints is barely manageable. Misusing a Product Backlog by adding hundreds of items to it is a clear sign that the Product Owner needs help from the Scrum Team or the Scrum Master to better cope with an influx of ideas, suggestions, and requirements. A smaller Product Backlog avoids misallocating resources; a larger Product Backlog is an indication of waste.
Your candidate should make it clear that they would support a Product Owner in dealing with the size of the Product Backlog, and the ideation process in general, for example, processing input from stakeholders and customers.
The role of the Product Owner is a bottleneck by design. How do you support the Product Owner so that they maximize value?
This question revisits the previous. Again, your candidate should focus on explaining why involving the Scrum Team early in the product discovery process is beneficial for both the Product Owner and the organization.
Additionally, Scrum Masters can effectively support Product Owners by ensuring that the Product Backlog refinement process is continuous and of a high value regarding the Product Backlog. “Garbage in, garbage out“ does apply to Scrum. Essentially, the Scrum Team either wins together or loses together.
I have mix of features as well as defects being planned in every sprint? Defects being from field can come anytime. How do we deal with this?
The catch: This is a tricky situation – if you say that you will accept defects midway you are playing with change of sprint goal mid of the sprint which is a No-No and if you say you won’t accept defects midway then you are not solving the business problem.
Answer: There are multiple options
a) Scenario 1: I can have 2 different teams – 1 for Feature Development and other for defect fixing. (Ideal)
b) Scenario 2: Based on the trend of defects, I can limit my planned features and leave the scope for defects handling. This way you are not playing with Sprint Goal
c) Scenario 3: Reduce the sprint length if the defects SLA is not too short like something below a week to accommodate incoming defects in next sprint.
How to:
• You can go through a Scrum Master Certification or Kanban KMP1 Certification and KMP2 Certification will give you in depth knowledge. Read more about Scrum master interview questions.