Apart from the fact that most software companies claim to implement agile methodologies, there are still common misconceptions and myths about Agile that are necessary to debunk, now and forever.
This would not only help the ones already implementing agile to avoid common pitfalls, but it will make companies understand agile more, realize its benefits, and embrace the change and ultimately improving prototyping process.
#1 Agile Projects don’t give Budget Estimates
As in traditional development methodologies like Waterfall, when projects are scope boxed, given the list of requirements along with their estimates, the schedule and budgets are derived from these estimates completely.
Since the waterfall model focus end to end development and delivery, estimation is provided without going much into details, those estimate are provided beginning of each phase.So the risk is, if those estimation are wrong, which is normally the case, normally iteration cycle is really long. Since estimations can not be totally accurate, if end middle of each iteration something need to be re-do or extend the scope it takes longer to re-focus and re-estimate, which makes the projects delay longer then if Agile methodologies was used. Its easier to do detail planning for next few weeks then for few years. That’s the main difference between Agile and Waterfall when come to estimation.
#2 Agile is not for fixed bid projects
Fixed big project is where product/service need to be delivered on agreed cost or budget.
Agile fit well with this kind of projects, because of agile methodologies characteristic of having short and quick feedback loop with the customer, since cost is fixed, so we need to make sure that what every scrum team is working on is still within the agreed scope. Regular sprint demo, close cooperation of production owner with customer, help to narrow the gap which enable the team to focus completely on product.
#3 Only a technical person can become a Scrum master
In reality 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.
#4 Agile means no Planning
Planning is very crucial in agile projects, but there is less upfront planning and agile generally does it differently than in the traditional waterfall approach. Planning is not done one time (following build, deploy, run phases), but continuously (e.g. every 7 days), usually in a very structured manner and having the long-term vision in mind. The more underlying information you have, the better you can refine your original plans. This is heavily dependent on early feedback. Fail often, but fail early. So initial requirements, prioritizations, estimates and time plans are constantly refined based on feedback.
#5 Work is assigned in Sprint Planning
Adjusting to changes is the essence of Scrum and Agile. If every team member has all the tasks assigned during the Sprint Planning, they are not able to respond to changes. If unexpected tasks come up during the Sprint or someone is under performing the workload cannot be flexibly distributed among other members of the team and the Sprint Goal will not be achieved.
#6 Agile Projects don’t involve Business Analysts
Scrum does not use business analyst term, and instead refers to the product owner. This leads to a single point of contact for the team when they have questions regarding anything. This does not mean Business Analysts are not included in agile projects. In contrast, the domain specific knowledge that business analysts have is an essential asset to the product owner. These experts help compose the backlog items and assist in concluding priority and order.
#7 Scrum projects are faster to produce output and cheaper to execute
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.