Search

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. Myths and Legends of Agile- only software? via @adrian_stalham #waterfall #scrum #agile pic.twitter.com/TDXFrSthUC — Pat Lynes (@patlynes) 10 October 2017 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 4.0/5 based on 20 customer reviews
10 deadly myths of Agile and Scrum 354
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.


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

Abhinav Gupta

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 *

Suggested Blogs

The Project Manager’s Role In Managing Scope Creep

Managing Scope is one of the most important responsibilities of a project manager as well as a business analyst. As per PMBOK® guide, managing the project scope is the sole responsibility of the project manager. Similarly, according to PMI’s guide to business analysis, the responsibility of managing product scope lies with the business analyst, with some amount of overlooking required from the project manager. The knowledge and capability of managing project scope are thus important elements of a project manager’s day to day tasks and an important knowledge area for anyone preparing for the PMP® or CAPM® exams. What constitutes project scope? PMBOK® guide refers to scope as the project’s boundaries. It defines the work that will be done during the project lifecycle.  The project’s boundaries are defined with respect to specific project goals and objectives, milestones, deadlines and project deliverables, tasks to be performed and resources required and the relevant project costs.  So, what is scope management? Managing scope entails a set of processes and activities required to effectively manage project scope from start to finish. This includes activities to define project scope and relevant parameters, SLAs in managing scope, planning scope management, controlling project scope elements defined on a daily basis, managing changes up until delivering the project and reporting on project scope. It helps project managers to allocate the correct amount of work and resources required to complete a project successfully. What can go wrong? What is scope creep? The uncontrolled growth in project scope at any point after the project has begun is known as scope creep. Scope creep is actually the negative effect on time, cost, and resources, resultant of the addition of additional features to the scope.  Project manager deal with Scope creep can occur when a project scope is not properly defined, documented or controlled and is also known as function creep, feature creep, requirements creep and more metaphorically as “kitchen sink syndrome”. This product scope creep will have adverse effects on project constraints such as time, cost, resources, and quality, and requires to be managed properly. Scope creep may happen naturally. The client may want more features for the same price where the project manager may just bow down to keep the customer happy. Similarly, the implementation team themselves may add more scope by trying to gold-plate or when they try to make things more visual by prototyping. So, it’s clear that project scope may increase knowingly or unknowingly. Importance of managing or avoiding scope creep It is important for a project management professional to avoid possibility of scope creep in order to increase chances of delivering project on time and on budget. Delivering a project on time will depend on how many features are taken up for each milestone or iteration and how the team can work efficiently to achieve the same. Managing scope is thus an important competency for a project manager. Predictive projects may follow formal Change Control Processes through a Change Control Board (CCB) to validate and bring in changes. Adaptive agile projects can be more complex with requirements needed to be groomed and managed as a product backlog. Tips for project managers to avoid or manage scope creep  Understand project goals & objectives It is extremely important for the project manager to be aware of the client’s vision for the project and for the product. The project manager must understand how the project objectives tie up with the corporate vision and strategy. The old adage goes, as ‘Something well begun is half done’. Thus a good understanding of what the client wants will help define what and how to manage. Understand solution requirements Project managers of yesteryears considered that the understanding of the functional and non-functional requirements is not their problem. But now,  it is imperative and the project managers understand the requirements and how they are related to goals and objectives so that they can plan the work and manage it properly. Understanding of requirements will allow the project manager to decompose requirements down to task level, identify milestones and resources and thus assist in keeping the project on track. On Track!  From day one of the project, the project manager must manage project scope and take necessary steps to avoid scope creep. The project manager tracking the requirements and change requests properly will assist in this case.  Devise a bullet-proof process for managing change requests A well-defined process to identify changes, report or take in change requests, evaluate them (evaluating the change, effort required, impact of change etc.) and to select and implement them is an important aspect in scope management. The project manager is responsible for defining this process, executing it, educating the team members on the process and on evaluating the process progress from time to time. In predictive or in adaptive projects, it is always good to limit the authority to request and to approve change requests.  Its alright to say ‘No’ Finally, the project manager as well as the team should be capable of saying no to unreasonable or unrealistic requests.  The project manager must be able to explain to the requester as to why a certain request is rejected with proper facts.  It is always important to avoid gold-plating. If things go wrong or are not possible within the current scope it is always important to say ‘No’ rather than getting into trouble later on. Sometimes it may be difficult to say ‘No’ to client stakeholders. The project manager’s negotiation and facilitation skills come to the fore-front in this case where he must be able to say ‘No’ with a positive manner as well as be able to convince client stakeholders by providing a prioritized list of features and so on. What’s next? As discussed in the introductory section, the responsibility of managing product scope lies with the business analyst. So, await my next article on the business analyst’s as well as the project manager’s responsibilities in managing product scope. Stay tuned!!  
The Project Manager’s Role In Managing Scope Creep
Author Image
Rated 4.0/5 based on 20 customer reviews
The Project Manager’s Role In Managing Scope Cre...

Managing Scope is one of the most important responsibilities of a proj... Read More

Scrum vs Kanban: Deciding New Agile Benchmark

Today in the rapidly changing market, software development is changing its list of requirement every now and then. As we all know, Agile is one form of software development methodology which mainly focusses on continuous delivery of project with client satisfaction. Agile always accepts the change and works on complete specifications to turn the project into a deliverable product. In the recent times, Kanban software development methodology is in the limelight for its ability to enable DevOps. Many of the organizations are moving from Scrum to Kanban for better results. So the question arises, which Agile methodology works better? And  Scrum vs Kanban becomes the essential question. The key differences between Kanban and Scrum depend on the Rules of using the methodology and the workflow. GOLDEN RULES Both Scrum and Kanban have a list of mandated and optional rules for their implementation. According to the Agile advice list for implementing Scrum, there are around 23 mandatory and 12 optional rules. Here are few examples: Teams are functioning in a  cross-functional manner During sprints, Interruptions are strictly avoided Work is always time boxed Scrum meetings are held on  daily basis To measure progress a burndown chart is used Firstly, the problem arises when organizations follow “Scrum But”- which is basically ignoring some specific set of rules for internal reasons. The next issue arises with timeboxing, which forms the core of Scrum. It allows the developer to define milestones for the stakeholders to evaluate and guide their project. Now in the case of Kanban, the rules are comparatively less restrictive. The principal rules are- Limiting the  work in progress To Visualize the workflow Kanban is a flexible and an open methodology that can add rules as needed, borrowed from Scrum depending upon the requirement. In Kanban, the focus is mainly on the flow and not on the timebox. This feature makes Kanban a very appealing choice to use with DevOps. WORKFLOW METHODOLOGY For Scrum: If we take the case of Scrum, every feature is decided before and it is ensured that it will be completed by the next sprint. After that, the Sprint is locked and work is finished over a couple of week, that is, usual sprint duration. The locking of the sprint is done to make sure that the team is getting enough time to make last minute changes depending on the requirement. There is a feedback session for reviewing the work accomplished. This helps to ensure that the delivered amount of work is approved by the stakeholders and is enough for directing the project as per business requirement. For Kanban: In the case of Kanban, the priority is to focus on the workflow and not on the time. The limitation is only regarding the size of the queues. Kanban’s main focus is on the productivity and the efficiency of the product. This allows them deliver superior  quality work items. In addition to this, concentrating on the workflow will keep things moving. In Kanban, there is an extended feature known as stakeholder participation. If your team is responsible for enhancing the feature development feedback of the stakeholder, then go for Scrum. But if your team is in charge of maintenance and requires to be more reactive, then you have to consider Kanban. Eventually, the need for every team is different and depending upon the requirements, methodologies need to be decided for the achievement of the goals.
Scrum vs Kanban: Deciding New Agile Benchmark
Author Image
Rated 4.0/5 based on 20 customer reviews
Scrum vs Kanban: Deciding New Agile Benchmark

Today in the rapidly changing market, software development is changing... Read More

CSM or CSPO: Which Certification Fits Your Requirement?

Agile methodology has been gaining a lot of clout in the IT Industry recently. With so much attention and talks around it all companies big and small are making themselves agile ready to deliver better sooner. Some common Certificate courses on Scrum methodology have also gained popularity because Scrum is the least restrictive of all agile approaches. CSM and CSPO are two such known Certifications that are often thought of as next steps in career progression introspection analysis. While both grant the benefit of knowledge, it is important to analyse what Certification makes more sense and can help better in future growth.   CSM Certification: It is for professionals seeking the Certified Scrum Master Certification. Its course work is educative to learn about how Scrum methodology works. Moreover, all the principles and practices around scrum are discussed in detail to lay a sound foundation of its conceptual framework. This certification is beneficial to gain an understanding of Scrum for all present and future scrum projects. Gaining a CSM Certification would benefit individuals who would rather want a Certification that validates their scrum knowledge. Hiring decisions based on Certifications are usually a motivator for professionals pursuing the Certification. This could also lead to challenging opportunities in a space that may interest professionals. Also, professionals seeking to change their present roles can also benefit from this certification to project their interest in this field. Other benefits of CSM could be acceptance in scrum based teams based on scrum knowledge. Also since a lot of organisations tend to portray to their respective client base they own the skills and knowledge to deliver, they also rely on certified professionals to join them so that they may use this as their asset over competitors. Another reason to pursue CSM could also be to expand ones’ knowledge of scrum methodology to be at par with peers. Since existing technical courses do not teach these new methodologies in courseware, pursuing a course about Scrum can help deliver work better if you have recently joined a scrum team or if you plan to join one. So, it is beneficial not only for professionals seeking knowledge as fresher but also for experienced professionals who seek work in scrum space. CSPO Training: CSPO is a common IT Certification acronym for Certified Scrum Product Owner. CSPO Certification is beneficial for professionals who are closer to business.  This course is also useful to give an end to end view of the feature that traverses from conceptualisation to deployment or ideation to a minimum viable product. Also, aspects related to understanding stakeholder interests in each functionality are reiterated in this course. Also, because a Product Owner’s role is critical for any organisation they tend to seek candidates who can genuinely guide the team well. While Certification is a way to project, that relevant knowledge is present and make way for a baseline to set that a candidate has genuine interest in the area and that they are focused on continuous growth. A Certified Scrum Product Owner training is also a good to have training to be able to handle the work as a Product Owner better. While a lot of professionals learn on the job, this certification is from the very Scrum Alliance dedicated to set guidelines that can help smoothen the learning curve. A Certification decision is hence usually based on career goals, present career role, and future possible roadmap. Having knowledge is always good and to keep refreshing basics helps revisiting decisions and making teams and individuals in scrum space more effective.
CSM or CSPO: Which Certification Fits Your Requirement?
Author Image
Rated 4.0/5 based on 20 customer reviews
CSM or CSPO: Which Certification Fits Your Require...

Agile methodology has been gaining a lot of clout in the IT Industry r... Read More