Don’t fall for these agile methodology myths.

Myth #1. Agile = Scrum

What’s the first thing you think of when you hear the word agile? For many of us it’s a standup meeting. Or maybe it’s creating a backlog of user stories that get delivered in a two-week sprint. Fact is, these are all elements of Scrum, a popular project management methodology used by many agile teams. Scrum is a framework for developing and managing work, while agile is an umbrella term for approaches like Scrum that share a common set of principles. Scrum is just one of many methodologies that build on agile principles (others include Lean, Kanban, Test-Driven Development and Xtreme Programming). Simply “doing Scrum” doesn’t mean you’re practicing agile management.

Myth #2. Agile Means “We Don’t Have a Plan”

Equating agile methodology with a lack of planning is one of the more pervasive agile myths. While it’s true that agile approaches trade the lengthy, up-front planning process for a more adaptive, iterative process, planning is a very important agile tenet. It’s just that instead of making one grand plan once a year and hoping that it’s still on target six months later, you’re dividing your planning (like the work) into smaller chunks and committing to reviewing your plans on a regular basis. 

Myth #3. Agile Doesn’t Need Project Managers

This might be one of the most fear-provoking misconceptions about the agile process (at least if you’re a project manager in a non-agile environment) and it reflects a fundamental misunderstanding about the roles on agile teams. The truth is that agile management needs project managers, but it won’t be your job to tell people what to do or when to do it. That’s because agile methodologies value self-managing teams—whose success relies on collaboration, localized decision making, regular communication and tools for visualizing and sharing work in process.

Myth #4. Agile Doesn’t Believe in Documentation

It’s true that the Agile Manifesto values “working software over comprehensive documentation.” However, this doesn’t mean documentation has no place in agile processes. Instead of just assuming a project and its associated processes require comprehensive documentation, you should undertake and design project artifacts because they provide value. You don’t need to draft pages and pages of documentation, use cases and process rules, and then spend time in requirements management. Instead, think about the minimum viable information that needs to be captured, with whom it needs to be shared, how to document it in a collaborative way and how that documentation might help you continuously improve.

Myth #5. Agile Only Works for Developers/Software

Agile may have started out in the technology realm, but like any set of effective practices, it has evolved and taken hold across a much broader audience. From finance and healthcare to communications and manufacturing, non-software companies—now finding themselves driven by software—are using agile approaches to improve their delivery, customer experience and innovation. Organizations buoyed by the success of agile processes in their IT or engineering groups also have invested in extending agile principles and approaches to leadership.

Myth #6. Agile Will Fix All Our Problems

You know better than to fall for this one, don’t you? No one thing is going to fix all your problems. Pinning all your hopes on a magical methodology is going to doom you to disappointment. Just as doing standups or buying an agile tool doesn’t make you an agile company, integrating agile practices into your IT group isn’t, by itself, going to turn your enterprise company into a nimble startup.

Bust Your Own Myths

If you’ve encountered any of these myths about agile processes, it might be time to brush up on what you think you know. 

This blog is syndicated from CA Technologies.  Read more on Highlight, the CA blog.



Hello Ms. Slade, Thank you very much for posting this information; it is an important clarification for individuals that don't have the real concepts of what it means to be Agile. I have worked in traditional project for more than 10 years. Now, in a Master degree class I have begun to become involved in the concepts related to Agile management. It is a challenge to change how I understand things from traditional to Agile, and it is changing my concepts such as: “Resources” in traditional is everything, and in Agile “Resources” do not refer to people. As per your experience, what do you recommend to make a smooth transition between traditional and Agile methodology? Best Regards, Honorio Daboin

Hi Honario, thanks for your comment. We've seen many companies make strong transitions from traditional to agile approaches by doing a few important things: 1) they have executive-level support for the change, so that commitment to it is never questioned; 2) they communicate clearly and intentionally; 3) they provide ongoing support and training for employees across roles and responsibilities; and 4) they treat the transition itself as an agile project, which allows them to stay adaptable and to reflect on their progress.

Hello Jenny Slade, First of all thank you for the information. This article resume well a semester of agile lessons and brought more light to me. I like the principle of agile but at first i thought working in an agile environment might be very chaotic. Then i realized that it's all about mindset. In fact, to be successful in agile, executive management, and everyone in the organization that may be affected should embrace totally the concepts of agile and learn to be agile. As Honorio noticed the transition from traditional project management to agile project management is very difficult. people are afraid of change and of the unknown. The bottom line is you need to manage people and their emotions; whatever approach you use make sure everyone is 100% on board and motivated, have a clear vision/mission, and communicate well. Roni
Request a Call

Looking for support?

Send Us Your Feedback

Provide us with some information about yourself and we'll be in touch soon. * Required Field