Agile Myths and Misconceptions

There are many Agile myths, in my opinion most people forget that its a ‘framework’, a model to be tailored to your needs. If you take an Agile guidebook, and try to apply it ‘by the book’, its probably not going to fit your company or needs 100%. Below are some of the main myths and misconceptions:

Agile will solve all your problems

Agile is not a silver bullet, and it probably won’t solve all your problems. Alights will say that the success rate on an Agile project is a lot higher, and they may be right; but an Agile projects can still fail — and with them being incremental will fail a lot faster. Agile promotes the following values:

• Focus on business needs
• Collaboration
• Innovation
• Open and clear communication
• Self-empowerment

If your team does not support or adopt this philosophy or attitude then this approach will not work for your company.

Agile says I don’t have to document anything

This is absolutely not correct, and does not make much business sense. The manifesto states:

“Working software over comprehensive documentation”

Agile does not state you do not have to document, or is ant-document, it states do not create lengthy documentation for the sake of it. Documentation should be treated like any other deliverable. It should be prioritised and estimated like any other user story. The point is, documentation can lean away from communication. Why create a long document or email when talking to someone will suffice and will likely be a lot faster.

Agile says I don’t have to plan anything

Agile doesn’t state you don’t have to plan; its actually quite the opposite. It may different to more traditional methods of project management in the sense that traditional approaches expect all the planning to be up front. This is actually quite unrealistic. The amount we know about a new development or project is actually at the beginning. Agile planning is much the same as its delivery, continuous and iteratively. Planning can consist of:

• Daily 15 minute stand up.
• Bi-weekly sprint planning and sprint retrospective meetings.
• Release planning where scheduled.

Agile has no discipline

Agile actually requires a lot of discipline. Many teams will take the easy parts such as the daily stand ups and iterative planning, but its not much good if you don’t also take on board the more difficult aspects such as actually delivering a product at the end of every sprint and testing. The discipline actually requires you to:

• Test throughout.
• Give regular feedback.
• Regularly ship software at the end of every sprint.
• Change and update the plan where needed — don’t be afraid of change; embrace it.
• You have to deliver bad news early.

Agile has a lot of change, meaning lots of rework

Yes ok, there is some rework, but this is not a bad thing. Imagine with more traditional methodology where you do your big plan up front. You get 60% through the development and realise there is a fatal flaw in your plan. You have to go back to the beginning or scrap most of the work that you have done. With Agile, your plan is continuous; and development in iterations, so if you need to make change you can.

There are two main areas of rework are:

• Requirements — you need to refine and rework requirements with the customer.
• Software — the development team will learn and come up with new ways to develop.

That being said, this needs to be balanced. You can’t allow the customer to keep changing their mind, and the development need to create a finished product. Burn down charts track progress and allow teams to asses where they stand.

Agile doesn’t support architecture

With Agile, it says that you shouldn’t build it when you don’t need it. In the past, we used to develop over complicated, expensive and hard to maintain systems. With Agile you can keep it simple only use what you need and learn from what you know and have done in the past.

Agile can’t scale with my large projects

Scaling is hard, no matter what project methodology you use. If there is a lot of teams that need co-ordination, complex systems with multiple parts, and get everything going in the same direction.

Agile, actually tries to get you to scale things down, to break up large projects into small pieces and deliver in iterations.

In Summary

Agile can solve a lot of problems, but its not the ‘kill all’ to everything. Adapting agile is difficult, takes time and work. There are a lot of myths and legends surrounding agile, but the best way to find out for you is to put it into practice, and learn as you go along.

This post was originally posted on: full-stackagile.com
Please check my site to get the latest articles first!

About the Author

Ashley-Christian Hardy
theproducthub.io

Product Leader. Over 10 years in product development; with experience in product management, UX & UI, product design, product & delivery methodologies and product leadership. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research, putting an emphasis on a customer centric design and approach.

Website: www.theproducthub.io

Twitter: www.twitter.com/achardypm

Facebook: https://www.facebook.com/theproducthubio

LinkedIn: mt.linkedin.com/in/achardypm

Medium: medium.com/@achardypm

Instagram: https://www.instagram.com/theproducthub.io/

Pinterest: pinterest.com/achardypm

SlideShare: slideshare.net/ashlychrstn