Is Scrum Bad or is it Just Bad Scrum?
That debate is not very helpful to Scrum Teams. Here are two scenarios to move beyond the debate and help teams make Scrum work.
I work with teams that are struggling to improve their agile teamwork. I lean on Scrum, and have helped guide teams with a wide range of ‘Scrum maturity.’ I’ve seen plenty of criticism of Scrum, and it makes for some energetic debates about whether Scrum itself is flawed or the problems rest with implementation. Is Scrum bad, or is it just bad Scrum?
In my experience, many times these criticisms reveal either an improper understanding or implementation of Scrum — or both (see the conclusion for an important exception). And the debate doesn’t actually help the teams that are struggling with Scrum. Instead I recommend that you focus your attention on what the team needs to be more successful.
Many of us have seen that Scrum works better than other approaches. Let’s rethink the debate in order to give Scrum Teams more helpful guidance. Here are two scenarios where we could better support Scrum Teams (without getting stuck in debates about whether Scrum works).
1. The scenario: A team is struggling with a Scrum implementation and showing frustration, perhaps blaming Scrum.
Not helpful: Hold up the Scrum Guide and criticize the team for not properly using Scrum.
Helpful: Encourage the team to reflect on their progress. Ask the team whether they are performing better now versus a month or two ago. Many times a Scrum Team is making progress. When they reflect on their progress, they recalibrate expectations and remember that they’re on a Scrum journey. They can renew their commitment to Scrum, and especially strengthen their resolve to do regular Scrum Retrospectives to reflect and improve. If a team is not progressing, it’s important to look at the discipline teams in their Scrum Practice. Pay special attention to (1) the Daily Scrum, and the team’s consistency and quality of interaction and (2) Sprint Retrospectives, and the discipline of continuous improvement. Does the team ‘inspect and adapt’ its improvement experiments adopted in the Sprint? Does the team select an improvement to try in the upcoming Sprint?
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint. — 2020 Scrum Guide
That simple reflection can help when issues or perceived issues come from within the team. But many times the problems come from outside the team — for example, leaders and managers who should support their teams and direct reports. Let’s think about how to approach issues outside the team.
2. The scenario: A team is trying to follow Scrum, but their leaders aren’t on the same page.
Leaders are asking questions and driving behaviors that put a traditional, waterfall project management wrapper around the team. As an example, I’ve seen matrixed organizations with Project Management Offices try to adopt Scrum in their teams while maintaining traditional roles like Project Manager that don’t exist in Scrum. This leads to friction and wasted effort whenever the Scrum Team needs to produce or support project management deliverables that don’t relate to their work and the Scrum process.
Another problem arises when a developer’s manager tasks them with work that is not part of the team’s goal. Practically speaking, that developer’s contributions are less predictable and can be out of synch with the rest of the team.
These leaders aren’t boosting productivity. They’re destroying focus and sabotaging the Scrum team. These behaviors go against the fundamental premise that a Scrum Team should be autonomous and self-organizing.
[The Scrum Team] is a cohesive unit of professionals focused on one objective at a time, the Product Goal…They are structured and empowered by the organization to manage their own work. — 2020 Scrum Guide
Not helpful: Remind the Scrum team that the Scrum Master has a responsibility to educate leaders and managers on Scrum.
Many times a Scrum Master does not have the authority (explicit or implicit) to influence senior leadership or managers that are undermining Scrum. Even though by definition this is a vital part of the Scrum Master’s role. Here is what the Scrum Guide says about the Scrum Master’s service to the organization:
The Scrum Master serves the organization in several ways, including:
• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum implementations within the organization;
•Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
•Removing barriers between stakeholders and Scrum Teams.
This is a tall order for all but the most experienced or senior Scrum Masters. Here are two practical ideas that may be more helpful.
Helpful: Make the Scrum team’s work visible.
In one case, I convinced a startup CEO that creating and updating Gantt charts destroyed value, and shared the benefits Scrum provides in prioritizing and focusing the team. His words to me: “as long as I know that the team and our contract manufacturer are making daily progress that will get us to our goal of manufacturing transfer as quickly as possible, I don’t care about the Gantt chart.”
My Scrum implementation with the team was clearly on probation. I made sure that the process and the results of the team were clearly visible:
- The team had its daily standup and tracked its work as post-it notes on kanban boards (with To Do, Doing, and Done columns) on the walls of the team’s bullpen, which happened to be outside the CEO’s office.
- As Scrum Master, I had more frequent conversations with the CEO about progress and roadblocks.
- I convinced the contract manufacturing partner to use the same approach in their facility for their internal work supporting our team — and when we weren’t there ourselves they emailed us a picture at the end of the day.
Helpful: Give the Scrum Master a mentor.
Sometimes a Scrum Master needs a guide to help them with external challenges in Scrum implementation. This is important when the Scrum Master is inexperienced or doesn’t have the authority to educate or negotiate with leadership outside the team. Such a team mentor can be internal or external to the organization — what matters is their experience and credibility with both the team and company leadership. A Scrum Master might be self-aware and adopt a mentor or mentors as needed to fully serve the team and the organization. However, that is not always (rarely?) the case. The organization should have a champion that also takes responsibility for the outcome of the Scrum Team. If you’re that project champion, ask yourself what the Scrum Master needs to succeed and if you can identify a mentor to help.
To wrap up:
If your team (and the organization) is aligned on purpose, let that be the guiding light and consider the implementation of Scrum as an experiment. If you encounter problems with Scrum, go back a step and ask what the team can do to make the situation better (not perfect, just better). And if the team isn’t equipped, supported, or empowered properly, engage leadership (a Scrum Master responsibility, sometimes with help from a team mentor) to properly understand and support the effort.
In this way, we may be able to move the conversation past “bad Scrum vs Scrum is bad” and toward deeper consideration of ways to improve upon Scrum itself.
Are you still tempted to jump into that debate? Ask yourself if you have given your best effort to get value from Scrum. I think the most compelling arguments about the limitations of Scrum come from those who seem to have transcended Scrum, as Spotify has. Or created a strong and effective agile culture that is most certainly not Scrum, like Basecamp has done. So if your organization has gotten the most from Scrum and is ready to join the conversation about how to go beyond it, congratulations!
