If you've worked in or around software development for more than a few years, you are probably familiar with the term Scrum. You may have been on a team that used Scrum with varying levels of success. Before I really familiarized myself with the Scrum Guide, I certainly had all kinds of assumptions and misunderstandings about what Scrum was, what it claimed to accomplish, and all its components.

These days, I often hear echoes of those same assumptions I used to share in how others discuss or refer to Scrum. When I suspect I hear such echoes in a colleague's argument, I think it's worth my time to try to expose the assumption and then challenge it a bit. Here are four assumptions I've encountered often or recently.

Scrum is a process
Scrum solves all your problems
You can cherry pick parts of Scrum
Leadership implements Scrum on behalf of a team

Assumption #1: Scrum is a Process

Scrum is a framework within which a team can refine its processes and relationships, but it's easily confused as process unto itself. I believe this is the reason teams who try to adopt Scrum will pick only the parts they think improve their existing process. Some people have experience with some level of Scrum adoption from previous teams, and the success or failure of that team is conflated with the usefulness of the framework itself.

However, Scrum is not your process, evidenced primarily by the fact that it is devoid of any business domain. Additionally, it contains timed events within which your team can execute and refine your process, but does not instruct you how to execute that process. For example, the Daily Scrum is a 15-minute time-boxed event with only a couple generic directives: The Development Team inspects progress toward the Sprint Goal, and makes a plan for the next 24 hours. Though it offers an example, the Scrum Guide does not say how you should conduct this daily event, only the constraints and objectives of the event focused on inspecting and adapting the team's work.

Assumption #2: Scrum solves all your problems

Many people I've spoken with have an assumption that a perfect implementation of Scrum yields a completely refined and effective delivery process for the team. Others who have experienced failure while attempting to use Scrum simply see it as a solution that doesn't work for all situations.

Usually, teams that fully implement the events, roles, and artifacts of Scrum will see things get worse before they get better. This is because Scrum gives transparency to the bottlenecks and other problems that exist in your current process. The intent of Scrum isn't to give you a process to use instead, but rather a framework within which you can refine your process as a team. You hold regular events where you can plan and collect feedback in order to refine your existing processes.

Assumption #3: You can cherry pick parts of Scrum

In conversations I've had about Scrum adoption, there often arises the question, "Which part of Scrum should we adopt next?" The underlying assumption is that some parts of Scrum offer more value than others, and you can pick only the ones that help you the most and ignore others.

There aren't many components of Scrum; Only three roles, five events, and three artifacts. Each one exists in support of the others and lacking one or more of them can render the framework mostly useless. Imagine you implement the Sprint time-box on its own. Lacking any other role or event, the end of the time-box is meaningless. Or imagine you have all the events and artifacts, but only the roles of Product Owner and Development Team. Lacking the Scrum Master, you have no one to support the team by teaching the framework values, coaching its use, removing impediments beyond the team's control, and etc. You would also have no dedicated advocate of the framework to support the organization to help understand how to interact with the team in order to maximize the team's effectiveness.

Assumption #4: Leadership can implement Scrum on behalf of a team

This assumption possibly represents the most fundamental misunderstanding of the values of the Scrum framework. See if any of these looks familiar to you:

"We do a form of Scrum, but we don't need a Scrum Master"
Management dictates that the team hold all the events (except the Sprint Retrospective)
"Let's just start with the Daily Scrum", but it is run by project management and ultimately is just a status meeting to ensure everyone has work to do.
The only person on the Scrum Team who has any Scrum training is the Scrum Master (and likely they are the Project Manager)

These are evidence that leadership has heard of the Agile revolution and wants to be aboard to get all the productivity gains, but doesn't understand the value proposition of Scrum. Likely the team itself has no Scrum training and is either ambivalent or even hostile towards the implementation of the framework.

It's certainly important that a successful Scrum framework implementation ultimately has the support of leadership. It can be supported in advance, which is certainly less painful, or it can be supported in arrears after a team has used the framework and proven some success. But without the buy in of the team, Scrum cannot accomplish anything useful.

Conclusion

It's not enough for some of the leadership or some of the team to try to use Scrum, it is imperative that eventually everyone has an understanding of Scrum and why it proposes to offer any value at all. If your team has decided to use Scrum and you aren't familiar with what is actually in the Scrum Guide, you can read it here. If you think you know Scrum, you can always check your assumptions also by reading the Scrum Guide. This is a free resource to anyone who wants to get to understand the what and why better. I revisit it often and review individual sections to refresh on its content.

Scrum is truly what it claims to be: lightweight, simple to understand, and difficult to master. If your team is taking its use of Scrum seriously, then you should all be familiar with its content and occasionally discuss with each other to mutually understand its intent.

Photo by UX Indonesia on Unsplash