In the last decade or so, Agile and Scrum have effectively conquered the minds of Software Managers and Engineers to a great extent. So much so that, if their respective projects do not involve Scrum, they feel that their career is doomed.
It might look amusing; however, this is what the plain truth is!
It is the very reason why a few myths have crept inside the systems. First, a proper CSM course is required to help you get a grip over things. Just being in the field, without having good credentials like CSM training as a backup won’t be able to lead you far.
Yes, Agile has got the highest efficiency and productivity rate and is being followed worldwide; however, it cannot do you much good if you are not working on a sound foundation without clear basics. As, a result of short-sightedness, mistakes are committed in the project execution. And, blindly following a few myths, further proves highly damaging.
First and foremost, we must dispel the false information doing the rounds so that we can concentrate on the right ideologies of Scrum. Here are a few of the widely believed and circulated myths.
- Anyone can be a Scrum Master: A Scrum master needs to maintain his/her cool even when the emotions are running high during the meetings and discussions.
You need to deal with the varied level of opinions, behaviour and tendencies on a daily level.
Yes, anyone can become a Scrum Master and there is no denying the fact, however, you need to have a certain level of emotional intelligence in order to manoeuvre the challenging scenarios that will present themselves in front of you.
An ability to remain emotionally detached during the whole process is a major trait of a successful Scrum Master.
- The Success of Scrum Is Directly Proportional To The Number Of Meetings Conducted: And, the reality is the opposite! As a reality check, Scrum is largely off meetings except during the crucial timelines like project initiation, planning, periodic status, review and finally the post-mortem.
If there is a dire need of conducting the meetings at frequent intervals, several times a day, that’s a big pointer that all is not well with your Scrum project!
- Daily Scrum Meeting and Status Meeting, Are Both Same! If this is what you are doing or believe in, then you are totally wrong here.
It is not an uncommon sight to see the project members gather daily and discuss what was done yesterday, what is in the plan for today, take on few issues and finally disperse thinking the meeting has been completed successfully.
This is not how a Daily Scrum Meeting should be!
The main criteria to be discussed during a Daily Scrum Meeting are to check the progress until the previous evening and compare the same with the final goal. It is used as a measuring scale to check if the progress is on track or not.
Next, the Status meeting comes in line. Here, the task distribution takes place alongside checking of the status of the jobs that are still under execution.
- You need to be from a technical background to be a Scrum Master: There is no such rule which says so! In fact, it is highly required that a technical person, if hired for this role, must keep his/her impulses in check while handling the position.
Hiring a non-technical person can be a better choice as this will keep all the discussions regarding the technical aspects of the job, out, keeping the meetings crisp, sharp and to the point.
- Agile Projects Provide Faster Output And Are Inexpensive To Execute: This statement is not entirely wrong but it is subjective to few conditions!
You need to apply Scrum in the right projects and under the right kind of the environment too.
For example, if you are using Scrum for a road construction project, it can be highly successful; however, we cannot say the same for a project which involves the construction of a dam over a river.
Similarly, using it for a mobile phone application development is a great idea but, it may not work that well for the development of an OS.
- It Is Okay To Compromise On Quality If You Meet The Deadlines: This we may not acknowledge consciously and openly but, in a project phase, several instances come where minor issues even on being noticed are brushed aside. This is mainly done to meet the committed timelines.
However, this is what this leads to is a substandard product that doesn’t quite meet the quality parameters.
Quality parameters need to be set during the project initiation phase only and these should be followed without a miss, throughout the project life cycle.
The goal is to ensure customer satisfaction by providing a quality product, duly meeting the delivery timelines, too.