top

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 not going anywhere! Sounds funny, right? 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. While I do not have any problem with Agile or Scrum as such, I do have concerns when I see people following things that are wrong; wrong as in incorrect even from an Agile manifesto perspective. 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. It is possible that these mistakes might be causing the issues in your project execution. Through this article, I am trying to share with you some of the most common myths or misunderstandings that people have with respect to Agile and Scrum. <blockquote class="twitter-tweet" data-lang="en-gb"><p lang="en" dir="ltr">Myths and Legends of Agile- only software? via <a href="https://twitter.com/adrian_stalham?ref_src=twsrc%5Etfw">@adrian_stalham</a> <a href="https://twitter.com/hashtag/waterfall?src=hash&amp;ref_src=twsrc%5Etfw">#waterfall</a> <a href="https://twitter.com/hashtag/scrum?src=hash&amp;ref_src=twsrc%5Etfw">#scrum</a> <a href="https://twitter.com/hashtag/agile?src=hash&amp;ref_src=twsrc%5Etfw">#agile</a> <a href="https://t.co/TDXFrSthUC">pic.twitter.com/TDXFrSthUC</a></p>&mdash; Pat Lynes (@patlynes) <a href="https://twitter.com/patlynes/status/917702415314546688?ref_src=twsrc%5Etfw">10 October 2017</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> Do go through them and let me know your take on this. Let’s start! 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 5 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: Wrong! 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. Don’t bite more than you can chew! 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 are having 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 properly make it. 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 making 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. So the next time you are going to start a project and want to use Agile and Scrum, step back and analyze the scenario. Ask yourself about the best fit for the project and make sure you don’t fall into these traps of Myths. All the best!  
10 deadly myths of Agile and Scrum
Abhinav Gupta
Rated 0.0/5 based on 0 customer reviews
Sort by :

10 deadly myths of Agile and Scrum

Abhinav Gupta
Agile Management
04th Jan, 2018
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 not going anywhere!

Sounds funny, right?

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.

While I do not have any problem with Agile or Scrum as such, I do have concerns when I see people following things that are wrong; wrong as in incorrect even from an Agile manifesto perspective.

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.

It is possible that these mistakes might be causing the issues in your project execution.

Through this article, I am trying to share with you some of the most common myths or misunderstandings that people have with respect to Agile and Scrum.

<blockquote class="twitter-tweet" data-lang="en-gb"><p lang="en" dir="ltr">Myths and Legends of Agile- only software? via <a href="https://twitter.com/adrian_stalham?ref_src=twsrc%5Etfw">@adrian_stalham</a> <a href="https://twitter.com/hashtag/waterfall?src=hash&amp;ref_src=twsrc%5Etfw">#waterfall</a> <a href="https://twitter.com/hashtag/scrum?src=hash&amp;ref_src=twsrc%5Etfw">#scrum</a> <a href="https://twitter.com/hashtag/agile?src=hash&amp;ref_src=twsrc%5Etfw">#agile</a> <a href="https://t.co/TDXFrSthUC">pic.twitter.com/TDXFrSthUC</a></p>&mdash; Pat Lynes (@patlynes) <a href="https://twitter.com/patlynes/status/917702415314546688?ref_src=twsrc%5Etfw">10 October 2017</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
Do go through them and let me know your take on this.

Let’s start!

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 5 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: Wrong! 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.

Don’t bite more than you can chew!

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 are having 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 properly make it. 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 making 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.

So the next time you are going to start a project and want to use Agile and Scrum, step back and analyze the scenario. Ask yourself about the best fit for the project and make sure you don’t fall into these traps of Myths.

All the best!
 

Abhinav
Blog Author

PMP, has 12+ years of experience working in Information technology sector and has worked with companies like Infosys and Microsoft in various capacities. He started his career as a manual tester for a world renowned software product and grew on to become automation champion in both functional as well as UI. He has worked with Healthcare units providing various software solutions to companies in North America and has worked with search engine based groups to enhance their experience and provide more bang for buck to their customers.

Leave a Reply

Your email address will not be published. Required fields are marked *

SUBSCRIBE TO OUR BLOG

View All Topics

Follow Us