When it comes to myths and misconceptions about Scrum, there doesn't seem to be any shortage. Some reflect people's hopes, others mirror their fears. Scrum Alliance® asked its trainers to identify the most common myths they hear from different stakeholders, and three themes recurred:
Let’s look at each of these in turn.
Scrum is a "magic bullet," one trainer quoted executives as saying. Other trainers hear:
"It will solve every problem."
"Scrum means I get more delivered faster."
"Now I'll be able to deliver all the features I want on time and to budget ... won't I?"
This myth is prevalent among executives and project managers, because those groups are the most involved with project management approaches.
For executives, the assumption is often that Scrum will deliver projects on time, scope, and budget — often with an emphasis on getting more in less time. Scrum’s true focus — to deliver better solutions to clients — should be important to executives, so this myth suggests that more effort needs to go into helping executives understand the real value of Scrum.
Related: 4 Ways to Ease the Transition from Waterfall to Agile
For project managers, this myth has a different impact. Trainers hear:
"Scrum is easy."
"ScrumMasters are not required."
"Project managers and ScrumMasters are interchangeable."
Project managers often compare their current role with that of the ScrumMaster and assume that they will easily be able to transition to that role. Or they assume that the ScrumMaster role is the same, with a different name. Or, at least, that the ScrumMaster will report to the project manager.
While many executives default to “better” when considering Scrum, there are project managers who feel threatened — thus minimizing the significance of the ScrumMaster role. In fact, the ScrumMaster is much more of a team coach than most project managers are.
Related: Differences Between Agile and Scrum, and How They Differ From Waterfall
"There isn't any requirements-gathering up front."
"There is no documentation in Scrum, so tracking progress is an issue."
"I don't know what to deliver if I don't get detailed specifications."
Trainers run into the second myth primarily among project managers and developers, and this is understandable. For them, the details of project execution matter. Their focus is on both requirements and system/development documentation. Again, the root of this myth can be linked to comparisons with traditional project execution approaches. There, documentation is highly structured and is a separate phase of the project — requirements drive design, which drives development. In Scrum, the focus is on developing solutions earlier in the process, but that doesn’t mean documentation is "skipped."
The documentation of a Scrum project is different. Instead of a fixed requirements document, there is a product backlog — a living and evolving entity that shapes the ongoing development. While poor management of the product backlog can result in Scrum projects that have insufficient documentation, the parallel situation also occurs frequently in Waterfall projects.
Related: Video — Scrum for Any Project or Product Development Effort
"No one bears bottom-line responsibility for delivering."
"Scrum allows development teams to do what they want."
"[There's a] lack of process, [a] sense that things are a free-for-all."
"No planning. No requirements. No way to predict release dates. It's really not any different, just a rearrangement of the deck chairs on the Titanic."
The final myth is perhaps the most common. It is almost exclusively the domain of executives and project managers, who traditionally rely heavily on formal project plans and feel unsettled without a highly structured, task-driven management approach. This myth also cuts to the heart of what project managers hold dear: delivering on time, scope, and budget.
In Scrum, however, the focus is on developing the highest-priority backlog items first. The guarantee is either to deliver on time with a projected scope or to deliver a defined set of features by a projected date. While Scrum has a number of different ways to plan and forecast completion, none of those are easily understood by a project manager used to work breakdown structures.
Executives, meanwhile, may want more visibility. Even if they're skeptical about the accuracy of a Waterfall-based project plan, it does provide visibility into the project at a granular level. That gives executives comfort that the details are being tracked and managed — and that there is solid data behind the information they receive. Scrum's more streamlined approach, combined with the element of the self-managed team, creates an inaccurate perception that there is no tracking of progress and no accountability for the work.
The reality is that Scrum projects are often tracked and managed more accurately than Waterfall projects. The focus is on what is important at the time that the work is being carried out. The highest-priority features are always the focus, and tangible deliverables are produced at the end of every sprint — providing a very real checkpoint of progress. At the same time, the people accountable for the work are being held to that accountability by their colleagues, not by a “percent complete” number in a detailed project plan.
For many stakeholders, Scrum is still new. They want to compare it to something they already know — Waterfall. However, Scrum is different from traditional project-execution approaches, and that makes comparisons between the two difficult. Comparisons are unnecessary (they are different approaches that work in different situations), and they can also result in misunderstandings that become widely accepted as "facts" — and myths are born. The biggest challenge in dispelling those myths is often gaining acceptance that they are myths in the first place.
Want to learn more? Watch our Scrum Foundations eLearning Series or learn more about becoming Scrum Alliance Certified.
Get the latest resources from Scrum Alliance delivered straight to your inbox
Subscribe