How Did Scrum Come About?
Before listing the misconceptions, let's first understand the origins of Scrum. The earliest roots of the Scrum concept date back to the 1980s, when Hirotaka Takeuchi and Ikujiro Nonaka mentioned it in their paper “The New New Product Development Game.” They called it a holistic and rugby approach.
In the early 1990s, Ken Schwaber used Scrum at his company, while Jeff Sutherland developed a similar approach at Easel Corporation. Later, they created the official Scrum framework and the Scrum Guide, which became very popular, especially in the software development industry.
Some form of Scrum was adopted by Google, Yahoo, Microsoft, and several other Fortune 500 companies.
10 Misconceptions About the Scrum Methodology
Below are 10 of the most common misconceptions about Scrum and why they are harmful to clients and employees.
Scrum Is a Process
This is one of the most common mistakes people make when talking about Scrum. A common term you may hear is the Scrum process. Basically, Scrum is not a process, but a set of lightweight rules that help a Scrum team develop its own process.
Scrum Is an Acronym
This is a pretty sneaky misconception. I say that because you could use it as a trick question in an interview. If someone claims to be a Scrum expert, ask them what the acronym “SCRUM” stands for. If they were Scrum experts, they would say it isn't an acronym. Scrum comes from a term used in rugby. You can often see Scrum written in all caps in résumés and job descriptions created by people who don't know how Scrum originated.
Scrum Is a Silver Bullet
Again and again, I've seen managers think that Scrum is the reason a project fails or succeeds. That can't really be true. I say this because Scrum is just a set of rules that, when followed, helps a team develop its own process. People implementing Scrum succeed or fail depending on how adaptable and insightful they are. A good analogy for understanding this is a game of chess. If you lose a game of chess, you can't blame chess itself for the loss. Chess is simply a game with a set of rules; the people who play chess lose or win, not chess. Scrum is like chess.
Scrum Means No Documentation
This misconception seems to be fading, but it still exists. Adopting Scrum does not mean giving up all documentation. You can still have documentation in the form of flowcharts created during whiteboard sessions, user stories, business analysis notes, or any other supporting documentation needed for a user story.
Scrum Is Micromanagement
As an employee of a company that implements Scrum, you shouldn't assume that Scrum is micromanagement. Micromanagement can happen as a side effect of a manager not understanding what Scrum is, but Scrum does not recommend micromanagement. In fact, Scrum gives the team more power to create the product.
Scrum Is Only Iterative Development
If you think you're following Scrum by doing only iterative development, you're seeing only half the picture. Several new teams moving to Scrum can fall into this trap, and it won't do much good for either the team or the customer. Scrum isn't just meetings and Scrum iterations, but also culture, teamwork, and cross-functional behavior.
Scrum Teams Do Cowboy Coding
Because Scrum is relatively fast-paced, some teams without good guidance may take shortcuts, which can lead to low-quality code. This doesn't necessarily mean that Scrum leads to cowboy coding. In fact, Scrum is simply a project management framework. Continuous code integration, automated code quality checks, and test-driven development are lean coding practices that can be used in any environment, including Scrum.
Scrum Leaves No Time to Do Real Work
Of course, it's not true that Scrum involves too many meetings. In fact, Scrum takes a minimalist approach to meetings. All the meetings in Scrum are enough for the team to inspect and adapt. The key meetings that make up Scrum are daily preparation, sprint planning, sprint review, sprint retrospective, and product backlog refinement. Anything beyond these meetings is a special meeting added by the team.
Scrum Can't Work with CMMI
I've seen projects successfully achieve CMMI certification while following Scrum. There may be certain government-based projects where the client requires the project to be CMMI-certified. You can still achieve CMMI Level 3 certification by making a few changes to the process you follow within Scrum.
The Client Can Change Requirements Anytime and Anywhere
A client who constantly changes direction during a sprint can damage the Scrum team's morale. At the very least, the Scrum team needs a full iteration to go through the entire lifecycle. This dangerous misconception can be dispelled by providing Scrum training to the client.
To Sum Up
According to statistics, Scrum is by far the most popular methodology.
No other Agile framework places greater importance on the client.
