10 Misconceptions About Scrum Methodology

With Scrum coming into the mainstream market, there now is a higher chance of companies trying to implement Scrum without having complete knowledge of it. This may result in half or hybrid implementations of Scrum which leads to project failures. These failures create a wave of doubts and misconceptions about how Scrum is implemented and the effects of Scrum.

The aforesaid occurrences make it imperative for every leader or manager to ensure that Scrum is understood deeply before implementing it and as the experts might say, the best way to learn something is to learn what that thing is not.

How Scrum came into existence?

Before listing the misconceptions, let’s understand the origins of Scrum first.

The early origins of Scrum concepts date back to the 1980s when Hirotaka Takeuchi and Ikujiro Nonaka mentioned it in the New Product Development Game. They called it a holistic and rugby approach.

In the early 1990s, Ken Schwaber used Scrum at his company and Jeff Sutherland developed a similar approach at Easel Corporation. They later on ended up creating the official Scrum framework and the Scrum guide which gained much popularity especially in the software development industry.

Some forms of Scrum have been adopted by Google, Yahoo, Microsoft and several other Fortune 500 companies.

10 misconceptions about Scrum Methodology

The following are 10 of the commonest misconceptions about Scrum and why these are detrimental for the customers and employees.

1. Scrum is a process

This is one of most common mistakes people make when communicating about Scrum. A common term you might hear is the Scrum Process. In essence, Scrum is not a process, it is a framework of light weight rules, which help the Scrum team carve out a custom process of their own.

2. Scrum is an acronym

This is a rather 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 are a Scrum expert, they would say it isn’t an acronym. Scrum comes from a term used in the sport of rugby. The capitalisation of Scrum is often seen in resumes and job description made by people who don’t know how Scrum originated.

3. Scrum is a silver bullet

I’ve seen time and time again, managers thinking that Scrum is the reason for failure and success of a project. In fact, that cannot be true. I say that because Scrum is merely a framework of rules which when followed, helps the team carve out their customised process. The people who implement Scrum succeed or fail based on how adaptive and inspective they are. A good analogy to understand this is with a game of chess. If you lose a game of chess, you cannot blame chess itself for the loss. Chess is merely a game with a set of rules, the people who play chess lose or win, not chess. Scrum is like chess.

4. Scrum means no documentation

This misconception seems to be fading away but it still does exist. Adopting Scrum does not mean avoiding all documentation. You can still have documentation in the form of flow diagrams that come out of white boarding sessions, user stories, business analysis notes, or any other supporting documentation required for the user story.

5. Scrum is micro-management

As an employee of a company that adopts Scrum one should not assume that Scrum is micro-management. Micro-management may happen as a side effect of a manager not understanding what Scrum is, but Scrum does not recommend micro-management. In fact, Scrum gives more power to the team on how to build the product.

6. Scrum is only iterative development

If you think you are following Scrum by only doing iterative development, you only have half the picture. Several new teams who adopt Scrum, may fall for this trap and it does not do much good for the team and the customer. Scrum is not just about the Scrum meetings and iterating but it’s also about culture, team work and cross-functional behavior.

7. Scrum teams do cowboy coding

Due to the relatively fast paced nature of Scrum, some teams who don’t have good guidance may take shortcuts and this may result in low quality code. This does not necessarily mean that Scrum causes cowboy coding. Actually, Scrum is just a framework for project management. Continuous Integration of code, automated code quality checks and test driven development are lean coding practices that can be applied in any environment, including Scrum.

8. Scrum leaves no time to do the actual work

It is certainly not true that Scrum has too many meetings within its framework. In reality, Scrum has a minimalistic approach in terms of meetings. All the meetings within Scrum are just enough to enable the team to inspect and adapt. The key meetings that Scrum consists of are the daily standup, sprint planning, sprint review, sprint retrospective and product backlog grooming. Anything beyond these meetings are ad hoc meetings added by the team.

9. Scrum cannot work with CMMI

I have seen projects where a successful CMMI certification was recieved while following Scrum. There may be certain goverment based projects where it is a client requirement for the project to be CMMI certified. It is possible to still be CMMI Level 3 certified by making a few tweaks to the process you follow within the Scrum framework.

10. The customer can change requirements anytime, anywhere

A customer who constantly changes direction during a sprint product backlog can hurt the morale of a Scrum team. A Scrum team at least needs a full iteration to go through the whole lifecycle. This is a dangerous misconception which can be removed by conducting Scrum training for the customer.

Recap

• Scrum is by far the most popular Agile methodology, per the State of Agile report of 2013.
• No other Agile framework gives more importance to the customer.
• A few common misconceptions about Scrum are: Scrum is a process, Scrum is an acronym, Scrum is a silver bullet, Scrum means no documentation, Scrum encourages micro-management, Scrum leads to cowboy coding, Scrum has too many meetings, Scrum cannot work with CMMI, and the customer can change requirements at will in Scrum.

Misconceptions about Scrum do not really hurt Scrum but it creates loss for the customer and also the people who adopt Scrum in the long run.

Scrum may seem like a minuscule thing in comparison to the actual problems related to the product, but in reality, it plays a huge role in the quality of the end product. The bottom line is, if you follow Scrum sincerely with patience and perseverance, you will always get beneficial results!