What indicators might there be that demonstrate agile practices are working for your organization, and which of these would demonstrate your efforts are succeeding?
There is no standard or general definition of ‘agile success’ that can be used to measure an organization’s agility. Every organization must develop its own criteria. Increasing team velocity is usually not considered to be a meaningful indicator.
However, although mostly indirect, there are various indicators that may be useful in determining success:
Products delivered to customers are resulting in higher retention rates, better conversion rates, increased customer lifetime value, and similar improvements to the business. (A successful Scrum Team provides a good return on investment to the business.)
The improved organizational agility allows pursuing market opportunities successfully, which previously would have been considered futile.
There has been a reduced allocation of resources to low-value products.
Lead time, from validated idea to shipped product, has been reduced.
The cycle time for hypotheses validations has been reduced, speeding up the product discovery process.
Improved team happiness is exhibited by reduced churn and an increase in the number of referrals from team members.
Increased competitiveness in the war for talent can be demonstrated by an increase in the number of experienced people willing to join the organization.
Increased software quality can be demonstrated by measurably less technical debt, fewer bugs, and less time spent on maintenance.
There is greater respect among stakeholders for the product delivery teams.
Stakeholders are increasingly participating in events, for example, during the Sprint Review.
What kind of information would you require from the Product Owner in order to provide your team with an update on the product and market situation?
Information that a Scrum Master might require from a Product Owner when wanting to update their team on the product, or a market’s reaction to it, would include any information that could provide the Scrum Team with an understanding of why something is of value to customers. Such information may be of a quantitative nature (e.g. analytical data describing how a process is utilized) or of a qualitative nature (e.g. transcripts, screencasts, or videos from a user testing session).
An excellent suggestion on the part of your candidate would be for the Scrum Team to participate in gathering qualitative signals by taking part in user interviews.
Please note: Normally, the Product Owner would provide this information during Sprint Reviews or the refinement process. Noting that the question Q12 itself is pointing at an anti-pattern, that would make a good topic for a Retrospective, is a bonus for the candidate.
How do you deal with team members cherry-picking tasks?
A Development Team has autonomy in how its members choose to distribute tasks, so it may be that a presumed cherry-picking of tasks by individual team members is in fact a valuable and crucial part of the team’s path to performance.
However, if team members are complaining about how others are choosing their tasks, the Scrum Master needs to address the issue. Additional training might help some team members accommodate a greater variety of tasks. Or, perhaps, other team members may need to be gently pushed out of their comfort zone so that they will more readily choose different kinds of tasks over what they’ve become accustomed to. Pair programming may be a suitable first step in that direction.
An anti-pattern of this behavior is when specific tasks, such as quality assurance, are regularly left to the same team members. This pattern reintroduces sub-roles to the Development Team — and needs to be addressed by the Scrum Master.
How do you manage team members who consider Daily Scrums to be a waste of time and are therefore either late, uncooperative, or simply don’t attend?
Refer to Question 25, where addressing this similar attitude and the behavioral problem is discussed at length. Your candidate’s answers should address similar points.
What Sprint Retrospective formats have you used in the past?
There are various Sprint Retrospective formats in common use, and each is meant to accommodate different situations. Your candidate should have experience applying more than one of these formats and should be able to share their logic for having done so. Some basic formats for Retrospectives include:
The classic format:
What did we do well?
What should we have done better?
The boat format:
What’s pushing us forward?
What’s holding us back?
The starfish Sprint Retrospective:
Start doing…
Do less of…
Do more of…
Stop doing…
Continue doing…
You can embed all of these formats in the general Sprint Retrospective format popularized by Diana Larsen and Esther Derby:
Set the stage.
Gather data.
Generate insights.
Decide what to do.
Close the Sprint Retrospective.
There are several websites available that help Scrum Masters to customize Retrospectives to the needs of the Scrum Team, such as Retromat or Tasty Cupcakes. Alternatively, Liberating Structures provide excellent tools, too.
Suitable candidates will elaborate passionately about their preferred ways and tools for delivering Retrospectives. Candidates that provide only mechanical answers require more scrutiny as the Sprint Retrospective is a key event from a Scrum Master’s perspective.
What qualitative agile metrics would you consider tracking?
The purpose of qualitative metrics is to gain insight into how one or more of an organization’s Scrum Teams are progressing with agile.
There are several self-assessment tests available that a Scrum Team can regularly run to collect qualitative metrics about their implementation of Scrum — Hendrik Kniberg’s Scrum Checklist is a good example. The interval to test via self-assessment is every 4–12 weeks, with teams of lesser fluency running their tests at the lower end of this range. The individual values recorded by these tests are not very important, but the trend over time is. To visualize these trends, a Scrum Master will need to aggregate the results — in the case of Henrik Kniberg’s checklist, an agile practice map may be created over time.
While self-assessment tests like Henrik Kniberg’s checklist are usually team exercises for recording implementation metrics, sentiment metrics are best captured by running anonymous opinion polls to ensure the participation of the more introverted team members.
Using opinion polls, typical questions for recording sentiment metrics include:
What value did the team deliver in the last Sprint?
Has the level of technical debt increased or decreased during the last Sprint?
Are you happy working with your teammates?
Would you recommend your employer (or client) to a friend seeking a new job?
It’s best to run opinion polls after every Sprint; these polls should only require a few seconds to complete. As with the self-assessment tests, the individual values recorded by running anonymous opinion polls are not very important — it’s the trend over time that matters. Trends derived from these polls are great points for discussion during a team’s Sprint Retrospectives.
Concerning metrics in general, your candidate should support the Agile Manifesto and its principle of transparency: all metrics should be available to all members of a Scrum Team, and largely also to those working in the product delivery organization generally.
How can you (as a Scrum Master) identify where you need to improve?
This is a simple question: Regularly ask your team and stakeholders how you can improve as a Scrum Master.
Why not run a Sprint Retrospective on yourself? A dedicated Sprint Retrospective is much more effective than spending five minutes, asking for hints at how you might improve, at the end of each regular team Sprint Retrospective.
Good candidates also note that they proactively provide user manuals on how to work with themselves to other team members and the organization.
What are the roles involved in the Scrum framework?
A Scrum framework has three roles:
Scrum Master
Product Owner
Development Team
There are no other roles than these but beyond Product organization, they can have other organizational roles too. Scrum does not speak anything on these roles and this depends on organization to organization.
What does DoD mean? How can this be achieved?
Definition of Done is the checklist of activities that need to be completed in order to call the Product Backlog Item (requirements) DONE so that it can be part of potentially releasable increment. This is common understanding between the PO and Dev Team. This is generally formulated at the start of the first sprint and which can be enhanced later on as the understanding of the Scrum team enhances.
When should you use the Waterfall Method over Scrum Method?
Waterfall method and the Scrum method can be used hand in hand to get the maximum desired output with the collaborative approach. But at times, there is a need when you need to go with the waterfall method despite of the Scrum method or their collaborative approach.
The waterfall method is the simplest approach to the software development process while Scrum is specially designed to have long term effect with complex integration of its principle. So here are some of the places where one needs to prefer waterfall method over scrum method.
When the project is simple:
The waterfall method is the best possible process to use for simple project development and implementation. Unlike big projects which need teams building with a cross-functional collaborative approach and appropriate use of Agile Methodology, Waterfall method should be preferred to have a simple approach for the small projects.
When the project is complicated:
Waterfall method can be preferred for complicated projects. But the thing which makes appropriate use of the Waterfall method with complicated projects are expertise hands. Expertise hands are best to analyse the complications of a project and with approach of the waterfall model, they can design a simple and subtle approach to develop the projects.
To focus on delivery date and budget:
If with the development of software budget there comes a deadline then the waterfall method should be preferred over any other. The deadlines can be the delivery date of product or with the budget of software development or on the focused approach of performance the developed software.
When Investment is not risky:
The software development cycle is a long process and the risk of investment needs to get configured accordingly with the need. But with the software development method where investment is not risky and they have a path for the simplest approach, the Waterfall method needs to be preferred at first for the development process.