Top Ten Misconceptions About Agile Development

Below is an excellent comment on the common misuse of agile methodologies in some organizations (see my post from 8/1/10 “Agile does NOT mean no planning or testing!!”).

From Wittawat Chaisaraseree at DZone.com

Agile Development is a powerful approach, particularly in IT. It can help produce quality products in a quick, efficient manner. However persuading people to be “Agile” usually involves overcoming a number of common misconceptions.

1.) “We don’t need to plan on Agile projects.” Yes you do! Coordinating work so that it can finish within short sprints needs careful planning. Tools like burn down charts help monitor whether we are on track by providing estimates of how much work remains.

2.) “Agile is a sloppy, ill-disciplined way of developing.” I would say the reverse is true. Agile engineering practices such as test driven development, automated builds and continuous integration create a very focused, transparent and efficient way of building a product.

3.) “Agile projects deliver sooner” This could be true, especially if we are used to creating large, superfluous artefacts like requirements documents. It’s also certainly true that in Agile we are trying to deliver something sooner than a more traditional waterfall method. However we may need to go through a number of iterations of delivering interim deliverables and getting feedback Keeping the client involved in these iterations should produce a higher quality product.

4.) “Agile is easier for the client.” Actually in some ways it is harder, as the client needs to be more heavily involved in developing requirements. Unless the benefits are properly explained (i.e. better end products) this can lead to irritated customers.

5.) “Agile will be too chaotic to track progress.” Actually Agile is completely transparent. For example it is very easy to know what each developer is doing via the daily Scrums and the burn down charts. It is also simple to know quickly whether the system works by building it automatically and running automated tests against it.

6.) “We don’t need testers in Agile Development.” One of the features of an Agile approach is to blur the distinction between testing and developing. For example, developers write unit tests focused on the structure of the code. It is still important that testers carry out business-focused tests, non-functional tests such as performance and load testing, and put themselves in the mind of a user by doing manual tests. See the excellent Agile Testing by Lisa Crispin for a full discussion on the testers role in Agile.

7.) “We don’t need business analysts in Agile Development.” Wrong. Because clients will be more involved in Agile Development, the skill of helping them articulate their needs and explaining and selling to them why they need to be more heavily involved is more important than ever.

8.) “You just need a Scrum Master Certification to implement Agile.” Well it certainly helps, but Scrum only tells half the Agile story. It focuses on management practices such as using sprints, product backlogs and allocating different roles to stakeholders. What it doesn’t look at are the engineering practices such as test driven development, automate builds and continuous integration. To get an understanding of these you could look at Extreme Programming by Kent Beck.

9.) “Scrum teams are never disturbed once they start a sprint.” Keeping the team away from interruptions so they stay focused is an important part of the managing with Scrums. However common sense should always prevail over blindly sticking to a process – there are times when Scrum teams need to be redirected during a sprint.

10.) “Agile is always the best approach” For large project with many team members, one final end deliverable and a low risk of misunderstanding what the client needs, a more traditional Waterfall approach might be more applicable.

Share