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.