Some well-intentioned practices sound reasonable, but a closer examination reveals potential pitfalls that can compromise the Agile manifesto principles or the Scrum Guide's underlying Empiricism. By understanding the rationale behind these practices and exploring their drawbacks, teams can foster a more nuanced and practical approach to achieve true agility and continuous improvement.
Reporting on team velocity and individual velocity
Perceived Benefit: Companies may believe that tracking - and reporting to leadership - team and individual velocity provides a clear measure of productivity for leaders to measure individual performance.
Why it sounds like a good idea: Velocity can be an easy metric to gather if the team uses many common electronic Scrum boards. Velocity is a metric that measures the number of 'points' assigned to each Product backlog item, and it is easy to calculate per Sprint how many points are closed per team or individual.
Why it's not a good idea: While velocity can be a valuable planning tool for the Scrum Team, using it as a metric for performance evaluation can lead to distorted results and counterproductive behaviors. For example, team members may be hesitant to participate in Refinement activities because it could impact their individual performance metrics for the Sprint, even though good Refinement can accelerate the team's performance in the long term. Or, team members may be less likely to pair program or collaborate with their peers, or lead developers may hesitate to spend time coaching newer team members if individual performance is based on the number of Product Backlog items closed per developer alone.
What to do instead: Velocity can be used by the Scrum Team to help them decide how much work to plan for an individual Sprint. When working with the Scrum Team, the Product Owner can also use Velocity to forecast future delivery dates. It's essential to recognize that velocity is a planning tool, not a measure of individual productivity, and misusing this metric to measure individual performance may harm collaboration and team dynamics and reduce the team's ability to forecast accurately.
Instead of using velocity or similar measures like throughput to measure individual performance, focus on team performance using outcome-based metrics. For example, is customer satisfaction increasing? Is lead time - or the time from when a request is received to when the customer receives value - improving? Are team members collaborative and focused on customer outcomes? Is the Scrum team delivering a done, valuable increment each Sprint that meets the Sprint goal? These are all much more valuable ways for leadership to measure team performance than limited metrics like 'velocity'.
Referencing the Scrum Guide in every meeting
Perceived Benefit: It may seem to the Scrum Master that they should continually reinforce the Scrum framework by simply referring to the Scrum Guide.
Why it sounds like a good idea: The Scrum Master is accountable for improving the adoption of Scrum, so continually educating the Scrum team about the contents of the Scrum guide may seem like a good idea.
Why it's not a good idea: While the Scrum Guide provides valuable guidance, simply repeating the verbiage in the Scrum Guide may not be enough to help the Scrum team improve the adoption of Scrum within the organization. The Scrum Master may need to coach the team to help them understand the 'why' behind the framework. For example, why does the Scrum guide call for a Retrospective at the end of each Sprint? Why should there be a single Product Owner?
The Scrum Master may need to use different approaches at different times to help the team focus on continuous improvement. Simply parroting the Scrum Guide is not enough and may be counterproductive if the Scrum team doesn't understand the 'why' behind the framework. (To learn more about the 'why' behind the Scrum framework, sign up for Rebel Scrum's upcoming Professional Scrum Master course.)
What to do instead: Understand the principles behind the Scrum Guide and apply them judiciously. Encourage teams to adapt their processes within the framework to suit their unique contexts. Foster a culture that values creativity, experimentation, and continuous improvement. Remember that Scrum teams are not perfect overnight, and use the Retrospective to help the Scrum team focus on continuous improvement.
The Scrum Master should only focus on the Scrum Team
Perceived Benefit: The Scrum Master’s task is to improve the adoption of Scrum. It seems like a good idea that they should focus exclusively on the Scrum Team.
Why it's not a good idea: The Scrum Team does not operate in a vacuum. Instead, many of the impediments to the smooth functioning of a Scrum team come from outside of the Scrum team. For example, stakeholders new to Scrum may not understand the concept of incremental delivery. The Scrum Master may need to work with these stakeholders to help them understand that they may not get everything that they have asked for in one Sprint, but what they will get is visibility, transparency, and the ability to provide feedback which may impact the Scrum Team's direction or improve the product. Other examples where the Scrum Master may need to focus their time are in adjacent processes, such as how work is requested from the Scrum team or even how budgeting and financial planning in the organization impact the Scrum Team.
What to do instead: Understand that the Scrum Master serves the Scrum Team and the organization. They help the Scrum Team - and the organization - to master the principles behind the Scrum framework to improve agility and deliver value sooner to the customer. It's not just about facilitating events, it's about improving the adoption of Scrum in the organization and across Scrum Teams.
Conclusion
As companies navigate the landscape of Agile frameworks and practices, it's crucial to critically evaluate well-intentioned practices to ensure they align with the Agile manifesto's core principles and the Scrum framework's underlying Empiricism. While tracking team and individual velocity, referencing the Scrum Guide, and limiting the Scrum Master's focus may seem like good ideas, their potential downsides must be considered.
By acknowledging the limitations of seemingly beneficial practices, teams can foster a culture of innovation, collaboration, and responsiveness, ultimately driving sustained success in their endeavors.
It's important to remember that, in the long run, no one will care about individual velocity when the team consistently delivers incremental value and continually improves customer outcomes. The focus should be on collective achievements and the positive impact on customer outcomes.
Make this the year you collaborate with your peers to improve your adoption of Agile frameworks like Scrum and Kanban. Get tickets today for discounted pricing at the Scrum conference that will leave you buzzing with ideas from fellow practitioners and industry experts.