The Main Misconceptions About SCRUM Methodology

The Main Misconceptions About SCRUM Methodology [Definition Included]

During our work at Elligense software development company, we noticed some misconceptions and myths that can scare off top managers who have decided to implement SCRUM Agile methodology in their projects.

I decided to gather and break the biggest ones. But before doing that, let’s remind ourselves what SCRUM methodology is.

Photo by Geoff Scott on Unsplash

SCRUM: What Is It?

The first approach SCRUM described Hirotaka Takeuchi and Ikujiro Nonaka, who noticed that small teams (5–9 people), staffed by diversified specialists, gave the best results. The most complete description of SCRUM was first introduced in the book ‘SCRUM’ by Jeff Sutherland, where he defined what SCRUM methodology is.

At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want? And question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that.- Jeff Sutherland

Jeff began his career as a military pilot. During the Vietnam War, he made more than a hundred sorties. Then Jeff was engaged in science, but the world will remember him as one of the founders of SCRUM Agile methodology.

The book begins with a real story from the life of the FBI, who spent millions of dollars on the development of an automated system designed to search and track criminals. The problem was that when the project was due to expire, the contractors showed the FBI a completely inactive product. This meant only one thing — American taxpayers spent millions in vain. The situation seemed hopeless until the FBI leadership turned to the then-emerging project management method SCRUM. This method is described in an accessible language in the aforementioned book.

Image via Wikimedia Commons

The Main Misconceptions About SCRUM Methodology

1. Total control that kills creativity

In SCRUM, the project team decides how to achieve a business goal, not the management. This approach motivates and stimulates creativity, as opposed to classical management, where employees are delegated to perform specific low-level actions. In the second scenario employees often don’t even understand why they do a certain task and how it will affect the project as a whole.

Thus, in SCRUM, the management does not control the actions of the project team, there are reports on the results at the end of each sprint (a predetermined period of time, for example, 2 weeks).

The main feature of SCRUM is transparency in the team. How is it achieved? First of all, by the daily stand-ups, at which all the team members tell what they did yesterday, what they will do today, what problems(blockers) they currently face. We at Elligense don’t miss stand-ups because they help each team member to remove obstacles in their work and devote colleagues into their plans so that everyone understands where the project is going today and realize its role in product development. For the same purpose, we use SCRUM board in Jira, where everyone can see the tasks of each team member.

With that being said, we see that SCRUM is about flexible approach, not control and stimulates creativity.

2. SCRUM deprives the rights of the most experienced engineers because they obey the decision of the team

SCRUM creates an environment in which skills and experience are more important than titles and positions. A striking example of the reverse situation is the hierarchy of the military, where power is based on position and rank. A captain can be much more talented and erudite than a colonel, but despite this, the captain must strictly obey. Such a rigid structure is ideal for extreme conditions, such as wars, where decisions must be made quickly, and their discussion leads to a delay that leads to the death of people.

SCRUM will not cancel titles. Each employee has his position in accordance with his experience and competence. However, in the process of discussing a decision, the dominant factor is a clear and reasonable position, backed up by the personal experience of the employee in the area under discussion, not his title. So, contrary to the myth, SCRUM gives power to those team members who can provide great ideas, whether it’s the most experienced engineer or not.

3. SCRUM focuses on short-term business values, not on long-term project development

It’s a real problem. Fortunately, there are answers to the question “What to do?”. We should start with the fact that this problem most likely will not emerge in the project with a duration of no more than six months.

Another thing is when the software is being developed for 2–3 years or more. There are tons of articles in which the authors pour out their pain regarding such projects. After 5–10 sprints, adding new features becomes problematic, and the further, the more critical situation becomes. SCRUM is great, but you need to think about strategy and architecture beforehand. Luckily, you can prevent this situation. How?

First, highly experienced engineers should work on the project to pass all commits to the repository through themselves during a code review (in our company team lead does that). Secondly, you should teach your junior and middle engineers software architecture, design patterns and how it is used on an existing project (at least 3 hours per week). Such classes should be accompanied by practice and a small portion of homework for better learning. Practical assignments can even be embedded in the backlog of project sprints. This does not greatly affect the profitability of the project, but it will accelerate the growth of employees and prevent potential problems with software architecture. Periodic meetups will allow project teams to learn from each other, which does not harm the quality of the software produced.

4. SCRUM does not allow engineers to grow

SCRUM assumes that all decisions regarding how to achieve business goals are delegated to the team. The product owner decides what to do, and the team decides how. The team must be skilled enough to make effective decisions. Thus, the cornerstone of the SCRUM methodology is learning. That is why in all major banks and IT outsourcing companies so much attention is paid to the employee grows: training, seminars, courses. We even do internal lectures at Elligense. Professional growth of employees is an integral part of SCRUM. Due to the fact that the SCRUM teams are relatively small, the team members have to master the whole stack of technologies within the project they are working on. At the end of the project, the engineer gets new skills, which increases its value in the labor market.

Bonus: Best SCRUM Team Management Tools

Screenshot from Wrike.com

1. Jira — we use this software in most cases. It has specially designed SCRUM boards, various reports, time tracking, sprints and backlog management, dashboards.
2. Wrike is less popular than Jira, however, it has almost the features. In addition, there are customized automated workflows and resource management tools.
3. Asana comes with great SCRUM features like kanban boards, project timeline, backlog management, meeting management, dependencies, milestones tracking, comments and file attachments.

Conclusion

In this article, I tried to break popular misconceptions about SCRUM. Let’s go through the right statements again:

1. SCRUM isn’t about total control and won’t kill creativity.
2. It doesn’t deprive the rights of the most experienced engineers as everybody is even when brainstorming the solution.
3. SCRUM can be used on long-term projects if there are strategy and architecture patterns.
4. This Agile methodology supports engineers’ growth.

Hope now you’ll be less afraid to implement this methodology in your company.