« How to Start Your Project?
Organization Structures in Project Management »

Agile Myths Debunked

October 13, 2009 | Author: PM Hut | Filed under: Agile Project Management

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.

Indiscipline

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 (www.technixindia.com). His interest and experience in Agile made him to start a blog (Agile Practical World) and share the Agile knowledge.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Tuesday, October 13th, 2009 and is filed under Agile Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 people have left comments

Sanjeev, you make very valid points. I’m currently involved in a large multi-phased fixed-price U.S Federal Government project. It’s my job to represent the U.S. Government and ensure the vendor is implementing Agile properly and adhering to industry best practices. Too many times, organizations get caught up in the project management process. I think what people fail to realize, when saying you can not use Agile in such an environment, is the goal is to deliver value to the customer. Focus more on how it CAN work and less on why it can not. I do believe your listed myths are the primary reasons Agile isn’t more broadly adopted in the Federal sector. I’ve heard them listed in meetings as though being read directly from this blog post. Only by educating clients and debunking these myths will we see more adoption.

Regards,
Derek Huether
http://twitter.com/derekhuether
http://thecriticalpath.info

Derek Huether wrote on October 15, 2009 - 9:07 am | Visit Link

Unfortunately software suffers from more fads than management does. The processes described are very rational but need to be placed in context.

For example, Sanjeev makes the point that Agile should generally be avoided in fixed cost projects. Well, guess what? That is the majority of commercial projects.

Many things that are claimed under the banner of Agile/agile have been around for years prior to the marketing people getting wind of a new process to run seminars on, e.g. paired programming, TDD, small interdependent teams, emphasis on communication, etc.

I have worked in Telecoms, Automotive, Defence and Maritime industries with everything from large-scale, real-time high-availability systems (30 minutes down-time max. in a 24/7 operational year) to desktop PC-based software that runs the odd operator calculation. We used waterfall, interative development, staged deliveries, and evolutionary prototying, etc. And the choice of process and desired outcome all depend on the technical and business context.

Believe it or not, waterfall actually works well if the system is well-architected, i.e. truely modular with low coupling, despite the customer not always knowing what they want or need. Change can be managed reasonably well in a system that supports flexibility of development.

Agile works best when the project team doesn’t actually know what it is doing or if the problem to be solved is genuinely unconstrained. Ever heard of a throwaway prototype, for heaven’s sake, instead of sticking the development organization or the customer with a half-baked accumulation of releases.

And I’ll scream if I read another agile enthusiast compare agile to Toyota’s kanban. It displays yet more ignorance amongst the Agile community given that Toyoya’s philosophy of development and manufacturing is a true example of a systems approach to a business outcome. Kanban is merely one aspect of that system.

David Pletcher wrote on November 30, 2009 - 8:00 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories