10 deadly myths of Agile and Scrum

Agile and Scrum have been conquering the minds of engineers, managers especially from software industry, quite effectively since last few years. The impact is so much so that every software engineer thinks that if he/she is not working on an Agile or Scrum project, their career is stuck. It surely is, but so is the reality of this fact. Agile and Scrum have become so pervasive in our thought process that we, as engineers or managers or product owners do not stop to ask ourselves once if we really need any Agile methodologies to complete the project at hand or not. We simply assume that we are going to follow Agile and Scrum.

These bad practices or even myths [as we can safely call them due to lack of a better word] have crept in due to our insufficient understanding of the manifesto or Scrum alliance guidelines owing to the rush of getting onto the Agile train before it leaves us high and dry. And the impact of this short sightedness is the fact that we are adhering to mistakes in project execution techniques based on some popular concepts, because no one knows they are myths and have no resemblance to truth.

10 Deadly Myths of Agile and Scrum

Myth 1: Anybody Can Become a Scrum Master

Reality: A Scrum Master is supposed to be the person who does not involve personally into the discussions going on in the sprints and daily stand-ups and keeps his eyes on the goal even when emotions are running high during the Scrum meeting. So yes, anybody can become a Scrum Master playing many roles as long as they have emotional intelligence to deal with the varied opinions, discussions, and tendencies to derail the team away from the goal.

Hence, in reality, emotional intelligence is the most important prerequisite to become a Scrum Master.

Myth 2: More Meetings Mean Scrum is Going Well

Reality: Scrum was supposed to be meeting-free except for the five known time boxed events [kick off, planning, scrum status, review, and post-mortem]. Apart from this, there are no more meetings required. And if your schedule is filled with multitude of so-called short meetings, then it is a clear sign that something is not right in the way Scrum is being done in your team.

Hence, the reality becomes, more meetings mean your Scrum is going ‘into’ the ‘well.’

Myth 3: Daily Scrum Meeting is Same as the Status Meeting

Reality: Nothing could be further from the truth and intention if we think that daily scrum meeting is same as that of status meeting. It is not!

You must have seen multiple instances where team members give updates on what we did yesterday and what we plan to do today; they discuss issues and leave, assuming that today’s scrum was successful. In reality, that is a failure.

Scrum meeting is supposed to get together and quickly review the overall progress of the project based on efforts till last night against the end goal of project and quickly gauge if we are on track or not. That is followed by status meeting, where today’s tasks are quickly distributed along with the status check of in-flight items.
That’s how it should be.

Myth 4: Velocity and Value are the Same Thing

Reality: This is so wrong on many fronts. This assumption implies that if a work is being done quickly, then it is taking us towards the end goal. Is that true?

Say a team member is creating automation with high velocity. But is it taking you closer towards shipping the product by the end date? No right?

Similarly, during Scrum meetings, we focus on the Value of work being done. It is possible that 100% of yesterday’s efforts might have contributed to 10% of total value. That is fine, as long as your idea of velocity and value is clear. Velocity is checked during status meeting, just to be clear. Velocity leads us to Value.

Myth 5: Only a Technical Person Can Become a Scrum Master

Reality: I want to correct that statement by saying a technical person can be made a Scrum master as long as they can ensure that they do not let their technical impulses interfere with their duties of being a Scrum Master.

If that cannot be guaranteed, then it is better to choose a non-technical person to be a Scrum Master because they can then ensure that the discussions do not cross the time limits and the meeting’s focus remains sharp.

Myth 6: Sprint 0 is a Must

Reality: These days it has become a norm to have the first sprint as a “blank Sprint” to allow teams to do dry runs and become accustomed to the system. This is a bad practice that has come into being due to the fact that the client, leadership and sometimes the managers put unfair and immense pressure on engineering teams to start delivering from day 1 or week 1. So the concept of Sprint 0 crept in where these stakeholders are given the confidence that something is happening and the team is buffered from pressure.

So what should be done in such cases? It is better to open a dialogue with stakeholders and take time for planning rather than calling it as Sprint 0, which actually goes against the values of Agile and Scrum.

Myth 7: Scrum Projects are Faster to Produce Output and Cheaper to Execute

Reality: Yes, this is true. But only if you are using them in the right environment. If you implement these practices for a wrong project, you can be assured of cost and schedule overrun to happen with a lot of production bugs.

For example, you can use Agile and Scrum for mobile App development, but it is not a good fit for Operating system development. Or it can be used for road construction projects, but it cannot be done for Dam construction projects.

Myth 8: Sprint Backlog is a Commitment That has to be Honored in all Circumstances

Reality: Sprint backlog is a collection of work items that you wanted to complete in each sprint, but it is not mandatory to finish it 100%. This means you need not make weekends working or force people to spend long hours in office to complete the sprint backlog. If there is a Sprint backlog remaining at the end of Sprint, then it simply means either the planning was not correct or there were unexpected capacity issues in the team and you need to fix them properly.

In such cases, the backlog moves back to Product backlog to be considered in future sprints based on its priority.

Myth 9: Quality Can be Compromised for Faster Deployment or Shipping

Reality: We all have been seeing this around us, sometimes in our own projects. Yet we choose to look other way and claim that quality was ensured throughout the process. Don’t we notice that these days softwares has way too many bugs? We brush them aside by saying that software has become really complex these days, so this is expected. But in reality, this is a direct outcome of our rush to deliver earlier than we had time to make it properly. Quality should not be compromised in lieu of shipping the product.

Always set the KPIs before the start of project and ensure quality measures up to those KPIs [Key Performance Indicators] throughout and especially before shipping the software or product.

Myth 10: 0 Backlog Means Scrum was Success

Reality: If this was the case, then why did that product fail to make any money? Running through the complete list of to-do items and getting a sense of accomplishment is one thing, but it does not ensure success unless you made all along the way that you were doing the right thing. And that is measured by the concept of value and quality, and this is where Scrum Master and Product Owner play the most important roles.

Unleash your potential with our project management certification training. Boost your career and become a confident leader.

Difference Between Agile and Scrum

Agile and Scrum may seem like interchangeable terms, but there are distinct differences between the two project management practices. Both approaches are based on an iterative and incremental approach, but they have different characteristics and principles. 

Agile	Scrum
Agile is a development methodology that is best suited for small, expert project development teams.	Scrum is one of the vital implementations of agile methodology, in which incremental builds are directly delivered to the customer every two to three weeks.
In the Agile process, the leadership plays an indispensable role and there is not much room for frequent changes.	Scrum is ideally used in projects where the requirement is rapidly changing.
Agile involves collaborations as well as face-to-face interactions between the members of various cross-functional teams.	Scrum fosters a self-organizing, cross-functional team, with a fixed role assigned to the scrum master, product owner, and team members.
Agile can require lots of up-front development processes and organizational change.	The biggest advantage of Scrum is its innate flexibility, as it quickly reacts to changes.
The agile method needs repeated and frequent delivery to the end user for their feedback.	In Scrum, collaboration is achieved in daily stand-up meetings, and a build is delivered to the client after each sprint for their feedback.
Each step of development like requirements, analysis, and design, are continually monitored during the lifecycle.	There is no team leader, which means that the entire team pays heed to the issues or problems collectively.
The Agile method has a positive attitude towards feedback at the time of process from the end user, in order to make the end product more useful.	Daily sprint meetings are conducted to review and provide feedback to decide the future development of the project.
Deliver, improve, and update the software on a regular basis and design as well as execution should be kept minimal and simple.	Design and execution do not have to be basic, it be innovative and experimental.
The Agile method prioritizes satisfying the customer by providing constant and continuous delivery of necessary software.	Empirical Process Control is a the core philosophy of Scrum-based processes, and working software is not an elementary measure.
Working software is the most elementary measure of progress, and face-to-face communication is encouraged.	The Scrum team focuses on delivering maximum business value, from the beginning of the project and throughout.
Agile principles include welcoming changing requirements, even late in development, attention to technical excellence, and self-organizing teams.	Scrum principles include self-organization, collaboration, time-boxing, and iterative development.

Conclusion

Agile and Scrum are undoubtedly the most widely adopted methodologies in software development today. However, there is a lot of confusion surrounding Agile and Scrum's true value concerning project management. Many of these misconceptions originate from misunderstandings about Agile and can have disastrous consequences for development teams if not managed properly. Hopefully, this blog has helped clear up some confusion surrounding these approaches. Go for the best Agile certifications and master the agile methodology.