Select Page


Agile Myths Debunked
By Sanjeev Singh

Below are all the Agile myths that some Project Managers believe in, and my explanation on why they’re wrong.


I must address this indifferent criticism in order to uncover the truth. In my opinion I see Agile team more disciplined compare to other SDLC. Agile study shows that team discipline and awakens about the project is one of the biggest factors for project success. Sometime I wonder and giggle about such people making baseless and irrelevant comments about Agile. I believe these types of comments must be coming from inexperienced people who may be new to Agile, Scared of learning new things, scared of accepting each day new challenges and must be finding a way to proof “not to use Agile”. From my experience I can say that Agile project is one of the best example of disciplined SDLC.

Talented Resource

I would say almost 90% this is true. Work delivery is very fast in Agile and that makes team very busy and productive. I see very minimal scope of training for any new or less talented resource. I don’t think that any Agile project can accommodate inexperienced or fresh college/school pass out. You don’t need to be brilliant, But YES Agile always welcome self learner, innovative and out of box thinker who can best fit into “Learn while you work” concept.

Small Team & Small Projects

I believe Small team has nothing to do with the size of project. Any large project can be done by small team in some larger duration. I would say that size of team matters for me and I would recommend small or mid size team which may be easy to handle in terms of day to day activity. Now days many companies are coming up with some presentation and trying to demonstrate Agile for a large project and big team. I don’t have much word to say for them other than “It is just a marketing stunt”.

Lack of Planning

I would say that in Agile we plan very aggressively but not with stringency. Agile doesn’t allow to plan straight up for the entire project. The good thing about agile is that planning is done in context of software evolution. In other words planning is a continuous process which occurs throughout the SDLC based upon iterations and releases.

No documentation

You are wrong if you believe that Agile say not to document anything. Agile talks about not documenting anything just for the sake of documentation or to show your smartness. Agile believes in tested and trusted working software. Hence use all documentation which works for your project and which can be useful in near future. You must tell your Project Manager if any document seems vague or if you think it is not working. Agile project only welcomes, working and valuable documents to be in place. If required the Project manager must take initiative with SQM or any other such process management group in organization in order to keep less and only valuable documents.

No Testers involvement

I have seen and read many posts on internet where people say that in Agile developer do all testing. I completely disagree. If developer is whole and sole responsible for testing work then for me it’s an alarming situation. I can see the fire and I need to call fire department together with Ambulance. My experience says that there must be dedicated testers to test the software. Testers are the skilled people who know how to break the system and where the problem could be.

In Agile because of frequent code movement into test environment the system under test becomes a moving target. There comes a great need of automation of regression test suites and it can only be handled by professional testers not by anyone else. It’s not only about automation. In agile Tester is a very integral part of project team member and no one can take place of testers in terms of test design, test planning, test execution…etc

Not for product development

I don’t see any reason to say “Agile is not meant for product development”. It can best fit into services and product development environment. In my opinion Agile can play and show very vital results in any product development. The reason behind is, it gives more space in welcoming the changes in today’s very frequently changing competitive market. Market is changing every day in terms of price, taxes, government new rules, and many other reasons. The bottom line is your product should be flexible enough to welcome and adopt new changes. I am sure your Product life and growth is much secured in the lap of Agile.

Not for fixed bid projects

I would say it is not always true. But I would recommend avoiding Agile into fixed bid projects. Agile welcome ideas, new requirement, change requirement, etc. If your project is very much rigid in terms of money and time then it’s good not to try or go with Agile. For services companies it may become a major issue if fixed project allows too many changes.

There is nothing wrong to play with Agile in a fix bid projects if you consider following points:

  • Your requirement is very well written, reviewed and approved.
  • Possibility and allowable limit of changing the requirement not more than 5%-10%.
  • If there is any constraint in terms of resource, time or money and the changes which are more than the aforesaid parameters then project should not allow.
  • There should be a separate system in place in order to evaluate any new changes and very strong SLA should be in place.

I have seen and experienced a very good collaboration, understanding and transparency between product owner (client) and vendor which made AGILE baby to laugh. In short I can say that it’s all about “How you negotiate with client and how strongly, clearly and efficiently both parties define and agree upon SLA”.

Project Management is difficult

In my opinion Agile project management complexity and simplicity is same as any other SDLC (Example: waterfall, V…..etc). The only difference is you need to be innovative and out of box thinker. Instead of saying “Agile project management is difficult”, one should say “Agile project management is different”.

In Agile you don’t plan straight up for the entire project. The good thing about agile is that planning is done in context of software evolution. In other words planning is a continuous process which occurs throughout the SDLC based upon iterations and releases.

All I can say is that now Agile projects are no more difficult to manage. All you need is some different tools, process, skill sets, Deliverables, matrix…etc which may be bit different from any other traditional SDLC.

As a Project manager this may be the right time and place to show your smartness. Come on you are done with traditional tested process and method. If you are innovative and accept challenges then “Agile management” is for you.

New marketing stunt and hype

I completely disagree from the people who say that Agile is just a new marketing stunt to attract some of the clients in order to get projects/business. Also it is not hype. Agile is one of the very practical, tested and proven methods of SDLC. The greatest strength of Agile is that you see your baby walking in front of you very soon after starting the project. You can show the walking baby (working product/project) to your client or product owner which will certainly help in providing much insight and confidence to all stake holders and justification in terms of money. The greatest beauty of Agile is that you can see and feel your changing baby in mother’s womb every single day, week or month. You will not be surprised with good or bad news after your baby is fully born. No wonder you will be excited to see your walking baby differently everyday.

Team does not work hard

This statement looks very funny to me. In any Agile project each and every team members are committed and devoted to their work, roles and responsibilities. Agile team members know how to work and show the result. There is no place for showoff fizz. In case anyone has finished the task, there is no question of sitting ideal. The person will take initiative to help others in terms of sharing the task. My experience says that Agile team member works at least 25% to 30% more than any other SDLC. If you still have doubt then try any project and the truth will be at your door.

Only one way to do Agile

There are many proven and defined method for Agile. Few of the examples are Agile Unified Process (AUP), Feature Driven Development (FDD), SCRUM…

In my opinion there may be N number of such hidden Agile process. The bottom line is that use whatever works for you in your Agile world. But make sure to address and keep in mind few mentioned points:

  • You and your team are focused towards continuous process improvement
  • Evolution of Agile as you learn and work better in your project
  • Team sprit in order to find the fastest way to the complete the deliverable with quality work.

I have experienced practicing Agile differently in my different projects. All I can say is “You better decide how and what to feed your pet” which should be healthy and tasty.

Sanjeev Singh has several years of extensive experience in IT industry in variety of business domains. Working with various companies and clients embellish him with abundant range of IT knowledge in terms of process, Business and many others. Saneev Singh is the CEO of Technix-India ( His interest and experience in Agile made him to start a blog (Agile Practical World) and share the Agile knowledge.

Recommended PM App

Recommended PM App