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

  • 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

“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

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

Agile has no discipline

  • 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

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

Agile can’t scale with my large projects

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

In Summary

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

About the Author

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

Product leader. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research.

Product leader. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research.