Welcome to the Home of Scrum! ™

When we introduce Scrum to an organization, many people are skeptical of the monetary benefits and ROI of the Scrum Master position. The question I am often asked is - "How do you justify the salary of the Scrum Master?" I've been thinking about this for some time, and here is an approach that might help you arrive at your own answer... Scrum Master ROI Scratch Pad If you need some help figuring out these answers, contact us and we'll help you out. If you take this approach out for a test drive, tell us what you discovered. My wish for you is not that this approach helps you realize that you need a Scrum Master. It is just that you learn to practice data-driven, evidence based management. Good luck!

TL; DR: Abandoning Scrum Can a Scrum team simply decide to abandon Scrum? After all, the Scrum team is self-managing, according to the Scrum manual, also known as the Scrum Guide. So, let’s explore this question at the very heart of team autonomy. 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 32,000-plus other subscribers. 🎓 Join Stefan in one of his upcoming Professional Scrum training classes! 🗳 Join the poll on abandoning Scrum on LinkedIn! Abandoning Scrum According to the Scrum Guide There are several references to self-management and team autonomy in the Scrum Guide 2020. However, no paragraph is addressing the question of when and how to abandon Scrum directly: Page 4: Adaptation becomes more difficult when the people involved are not empowered or self-managing. Page 4: These [Scrum] values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them. Page 5: [Scrum Teams] are also self-managing, meaning they internally decide who does what, when, and how. Page 5: They are structured and empowered by the organization to manage their own work. Page 6: The Scrum Master serves the Scrum Team in several ways, including coaching the team members in self-management and cross-functionality. Page 7: The Scrum Master serves the organization in several ways, including leading, training, and coaching the organization in its Scrum adoption. Page 7: The Scrum Master serves the organization in several ways, including planning and advising Scrum implementations within the organization. Page 8: [Sprint Planning: How will the chosen work get done?] How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value. Page 9: The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. Page 11: The Sprint Backlog is a plan by and for the Developers. Source: Scrum Guide 2020. (The aggregation is taken from the Scrum Guide 2020 Reordered.) Given the Scrum Guide’s emphasis on empowerment and Scrum team autonomy, I am tending towards the notion that a Scrum team is eligible to abandon Scrum. However, before taking that step, they need to have identified a better way of creating value for the customers and a sustainable business for the organization. Why Teams May Consider Abandoning Scrum In my experience, Scrum teams that consider quitting Scrum fall mainly into three main categories: There is a better way of creating value: Within the organization’s constraints, the Scrum team identified a more effective way of creating value for the customers. Often, this happens within organizations operating in highly regulated markets. Or the organization faces structural debt that cannot be resolve in the short term, thus impeding the proper application of Scrum. Alternatively, the use of Scrum has been mandated across all teams, and Scrum would not make sense given the usual tasks that “our team” is facing in everyday work. (You do not need Scrum to make a hamburger with fries.) The team is tired of preserving the facade of being agile: Officially, the organization practices Scrum. However, in practice, the management pays only lip service to the idea of autonomous teams, practicing a sort of Scrumbut or cargo cult Scrum. Being tired of the lack of openness, the “Scrum team” decides to abandon what they never practiced in the first place. The team members are unwilling to accept more accountability: Despite what Dan Pink advocates in his book Drive on what motivates knowledge workers — autonomy, mastery, purpose — these team members do not want to accept more responsibility. Some just want to trade time for money in a regular 9-to-5 job. Consequently, they ask to be told what to do. (Of course, we want missionaries on our teams, not mercenaries. However, Scrum is not for everyone, and asking for a 9-to-5 job is legitimate.) Abandoning Scrum — Conclusion Scrum cannot be pushed; Scrum needs to be pulled. Scrum comes with a lot of additional accountability. Not all people enjoy this fact. Mercenaries just want to trade time for money. Some organizations embrace self-management just on paper but not in practice which is frustrating missionaries regularly. Scrum is not your one-size-fits-all solution on the path of becoming agile. There are areas where Scrum is a waste of money, brain, and time. Hence abandoning Scrum for something else that creates more value for your customers is a good move. What you should restrain from, though, is abandoning Scrum merely because it is hard to establish, difficult to make successful. Because there are frustrations among the team members, set-backs, and anti-pattern everywhere you look. First of all, give Scrum a decent chance. Have you met a Scrum team considering abandoning Scrum or who did so? Please share your learnings with us in the comments. ✋ Do Not Miss Out: Join the 10,000-plus Strong ‘Hands-on Agile’ Slack Team and Learn More About Self-Management I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free. 📖 Related Posts Scrum First Principles — How to Elon Musk the Scrum Guide The Lack of Agile Leadership Qualities — Making Your Scrum Work #15 Agile Failure Patterns in Organizations 2.0 Why Engineers Despise Agile Download the Scrum Anti-Patterns Guide for free.

A Scrum team consists of three clear accountabilities: one Scrum Master, one Product Owner, and Developers. Often, when working with a Scrum team struggling with excessive conflict or a lack of trust, I find the culprit is a lack of clarity around each of these accountabilities. Even with the best intentions, the Product Owner can become too focused on the upcoming Sprint and not focused enough on the bigger picture. The Scrum Master can become overly protective of the team, and the Developers - wishing only to please - can take on too much work, jeopardizing the Sprint goal. Indicators of a lack of clear accountability on a team might include: The Product Owner has not developed or communicated a Product Goal The Product Backlog does not have enough work ‘ready’ for the upcoming Sprint The Development team or business stakeholders demand an ROI calculation for ordering the Product Backlog The Developers do not feel comfortable determining how much work to pull into the Sprint Backlog at the Sprint Planning meeting Stakeholders or IT managers routinely call on Developers to add work to the Sprint The Scrum Master does not allow IT managers to attend any Scrum events The resource manager criticizes the Scrum Master for not increasing the team’s velocity Sprint over Sprint The business stakeholders provide direction to the Scrum team on how to organize to deliver their work Architects or other subject matter experts are unsure of how to provide guidance to the Scrum team If you spot one or more of these indicators, a deeper understanding of the accountabilities on a team can improve how it functions. A deeper dive into the Scrum accountabilities What the Product Owner does The Product Owner represents the interests of the business or community product stakeholders through the content and order of the Product Backlog. They may delegate this work, but remain accountable, and no one can tell the Developers to work from any other list. How they do it The Product Owner develops and communicates a Product Goal. Based on the Product Goal, the Product Owner creates and orders a Product Backlog (or to-do list), which contains the work needed to improve product value and makes it transparent and accessible. The Product Owner may create a forecast or roadmap to aid communication with stakeholders or customers. Why they do this work The Product Owner is responsible for maximizing the value of the product resulting from the work of the Developers. Without a single individual with decision-making authority determining what the Scrum team will work on next, the Scrum would lose focus on their goals and value delivery would be diminished. Common Product Owner anti-patterns: They haven’t identified a Product Goal Why this happens: The Product Owner may be focused on getting enough ‘ready’ work for the upcoming Sprint or may not be aware that a single Product Goal is necessary. Do this instead: Just like a ship without a rudder, a Scrum Team without a goal can change directions so frequently that it doesn’t achieve any value at all. When the Product Owner develops and communicates a Product Goal for the Scrum Team to aim for, each Sprint is a step towards that goal. Opportunities to share the Product Goal include at the Sprint Planning and Sprint Review events. The Product Owner can also share the Product Goal in refinement or stakeholder meetings. The Product Backlog includes the Product Goal. The Product Backlog does not include enough work for the upcoming Sprint Why this happens: This often happens with newer Scrum teams because the Product Owner has not had time to build up a Product Backlog of ready work. Do this instead: While the Product Owner is accountable for the content and ordering of the Product Backlog, they may choose to delegate those tasks to Developers or others within the organization, such as business analysts, for example. Additionally, refinement meetings can be an opportunity for the Product Owner to collaborate with the Developers and stakeholders to build out a Product Backlog quickly. What Developers do Developers estimate, plan, and execute the work of the Scrum Team. They collaborate with the Product Owner to maximize Product Backlog value and determine what work to pull into the Sprint (Developers own the Sprint Backlog). How they do it Developers self-manage; no one--not even the Scrum Master--tells the Developers how to turn Product Backlog items into a useful increment at least once per Sprint. Generally, Developers are cross-functional, with all the skills as a team necessary to perform work in the Product Backlog. Developers use the Sprint Backlog to plan work and the Daily Scrum as a checkpoint for measuring Sprint Goal progress. There are no hierarchies among Developers on a Scrum Team; everyone is accountable together for delivering a useful increment at least once per Sprint. Why they do this work To deliver a done, usable increment at least once per Sprint. Common Developers anti-pattern: Developers, Resource Managers or Stakeholders may demand using a specific ROI calculation to order the Product Backlog Why this happens: This can be a sign of a lack of confidence in the Product Owners’ decision-making. Do this instead: The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum team. One of the Product Owner’s tools is the Product Backlog. The Product Owner can order the items in the Product Backlog any way they deem best. For example, they may decide that some quick wins would help build trust with the customer base, or they may decide to order items purely based on ROI. Although the Product Owner has full discretion about how to order the list, they should gain input from stakeholders (including the Developers). Doing so will help the Product Owner to make the most informed decisions about ordering the Product Backlog. Stakeholders or IT managers routinely call Developers to ask them to add work to the Sprint Why this happens: Stakeholders or IT Managers may be unaware of the Product Owner accountability. Do this instead: Developers should direct stakeholders to the Product Owner regarding additional work and/or the Scrum Master should provide coaching to the impacted Stakeholders or IT Managers. Only the Product Owner can decide how to order the Product Backlog. What the Scrum Master does The Scrum Master is accountable for establishing Scrum as it is described in the Scrum Guide. It sounds simple, but it isn’t. Being a Scrum Master involves more art than science. The perfect Scrum Team does not evolve overnight. It can take years to become a high-performing unit. A wise Scrum Master knows what challenges to tackle first. Why they do this work The Scrum Master is a servant leader of the team whose purpose is to increase the effectiveness of the Scrum Team by improving its practices. Common anti-patterns: The Scrum Master does not allow resource managers to attend Scrum events Why this happens: In some organizations, members of the Scrum Team may report to IT or other resource managers. These managers may not understand their role and how they should relate to the Scrum Team. Do this instead: The Scrum Master can coach managers in how best to interact with the Scrum Team. For example, managers attending the Daily Scrum should avoid interfering with this daily opportunity for Developers to synchronize. The manager’s sole role should be to identify and remove impediments or to promote a culture of trust among Scrum Team members. The resource manager criticizes the Scrum Master for not increasing the team’s velocity Sprint over Sprint Why this happens: The resource manager may be looking for ways to support the Scrum team but is unaware of the right way to interact with the Scrum Team. Do this instead: Velocity is a tool internal to the Scrum Team that it uses to plan and organize its work. Velocity is not a ruler for measuring team success. Use value metrics instead, which measures the product’s value. The resource manager should be encouraged to participate in the Professional Agile Leadership Essentials class offered by Scrum.org for more information about how to support and coach Agile teams. The business stakeholders provide direction to the Scrum Team about how to organize to deliver their work Why this happens: The business has a vested interest in the success of the Agile team but is unclear about how best to engage with a Scrum team. Do this instead: No one, not even the Scrum Master, tells the Development team how to turn Product Backlog items into a ‘done’ Increment. Encourage the Scrum Team to self-manage to deliver the work. By empowering teams to own the delivery of their own work, organizations can unleash greater creativity and problem solving skills from all Scrum team members. The table below provides an overview of each of the accountabilities included in the Scrum Team:

In this blog post, I share 10 success factors that emerged from a community meetup. These factors helped Scrum practitioners prevent or fix Zombie Scrum in their team and organization.