You’ve already provided your product’s stakeholders with training in Scrum. After the initial phase of trying to apply the concepts, when the very first obstacles are encountered, some of these stakeholders begin to resist continued adoption. What is your strategy for and experience in handling these situations?
This question is meant to encourage an exchange of ideas about, and lessons learned when overcoming resistance to Scrum within an organization. Familiarity with agile failure patterns that are common to many organizations will demonstrate your candidate’s experience. (We have published a list of several agile failure patterns.)
Your candidate should also be familiar with the particular challenge middle managers face in any transition to agile practices. Moving from a command-and-control style (i.e. managing people and telling them what to do) to a servant-leadership style — thus abandoning Taylor’s principles — is not for everyone
Your Scrum team is consistently failing to meet commitments, and its velocity is volatile. What might the possible reasons be? How would you address this issue with the team?
If a Scrum Team is exhibiting a volatile velocity, consistently failing to meet their forecasts, it suggests that velocity is being used as the prevalent metric for measuring that team’s progress.
Your candidate should mention this, and talk about the notoriety of ‘velocity’ as the industry’s most prevalent metric for measuring a team’s progress. They should further be able to explain why velocity is altogether a doubtful agile metric and point out that quantitative metrics are not ideally suited to measuring a team’s progress in mastering Scrum.
There are many factors that make a Scrum Team’s velocity volatile:
New team members being onboarded;
Experienced members leaving the team;
The team working in uncharted territory;
The team working with legacy code, probably undocumented;
The team running into unexpected technical debt;
Holidays and sick leave reducing the team’s capacity;
An executive intervention changing a Sprint’s scope; and
The team addressing unplanned priority bugs.
Another common cause for a Scrum Team to consistently fail in meeting their forecasts is that the team’s Product Backlog items are being poorly prepared, thus making the work items difficult for the team to estimate. Conversely, the projects being given the team might suffer from poorly documented legacy code, excessive technical debt, or just too much buggy and poorly written code — all of which make estimation a gamble.
Your candidate should not align themselves with the fallacy that a team’s adoption of Scrum is working only because a Scrum Team’s forecasts and velocity are aligned. Cooking the agile books is easy to do!
What are the main artifacts of the Scrum Framework?
There are three main artifacts in SCRUM:
Product Backlog
Sprint Backlog
Product Increment
Why aren’t user stories simply estimated in person-hours?
Estimating user stories in person-hours is rarely a good idea. It intentionally diverts the emphasis away from the true purpose of the estimation process: to create a shared understanding of the task ahead among all members of the Scrum Team. Ergo, the estimate itself is just a byproduct.
Estimating is often tricky when:
Legacy software is involved,
A team is facing significant technical debt, or
A team is composed of mostly junior members.
Hence story points are much better suited to estimating than man-hours in all situations, but especially in tricky situations, because they reflect both the complexity of the task and the effort required to complete it.
Using person-hours instead of story points typically shifts the focus from value creation for customers to the more traditional project management of costs and budgeting, effectively imposing a waterfall process. Also, estimating in person-hours suggests an unmerited level of precision.
A good candidate would mention the ongoing discussion in the agile community as to whether estimations are useful in general. They would also likely point to the ‘no estimates’ concept.
What is Scrum?
Scrum is a simple iterative framework which comprises of 3 roles, 4 events, 3 artifacts and few rules which believe in delivery of product features or solution in iterative, incremental manner.
The iteration is called as SPRINT and is mostly of a month or less where teams deliver a potentially releasable solution at the end to the user/customer.
Scrum believes in ownership culture and gives Team the freedom of choosing how much to plan to deliver in a sprint however the What is decided by Product Owner.
How is estimation in a Scrum project done? What are the techniques used for estimation?
Estimation can be done using any available estimation techniques such as Function Points, Wideband Delphi etc. and Scrum has no recommendation for this. However a relative estimation technique like Planning Poker estimation has been widely used across multiple companies and is very popular.
What is the major advantage of using Scrum?
Early & continuous feedback which fosters inspect & adapt
Early delivery to markets
Increases communication between business and implementer reducing the scope for defects
Technology and business are aligned and hence cost reduction
Whats the Role of the Scrum Master?
A Scrum Master plays a very key, optimized and conclusive role for the working of Scrum Framework. The task and goal of Scrum Master are very diversified right from as the leader of Scrum teams to being the interface between the product owners and product developers. The position of Scrum Master is exclusive yet its practice and influence is extremely broad in use. So here are the following roles a Scrum Master plays in an organisation for Implementation of Scrum Framework.
Responsibilities of an effective Scrum Master:
Manage the Project Development and Implement the practices of Scrum
Keeping an eye on every track of the work process
Implementing Agile Development practices
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.
What suitable agile metrics have you used in the past?
This question is an invitation to the candidate to share lessons learned from the successful application of metrics to help a Scrum Team improve continuously.
Suitable agile metrics follow three rules:
The first rule of tracking meaningful metrics is only to track those that apply to the team. Ignore those metrics that measure the individual.
The second rule of tracking metrics is not to measure parameters just because they are easy to follow. This practice often is a consequence of using various agile tools that offer out-of-the-box reports.
The third rule of tracking metrics is to record context as well. For example, data without context, the number of available team members, or the intensity of incidents during a sprint may turn out to be nothing more than noise.
Examples of suitable agile metrics are:
Lead time,
Cycle time,
Number of defects escaping to production, or
Ratio of fixing work to creating new value.
Good candidates should be aware of the evidence-based management concept.