Let's flatten five agile fallacies!

 

In 2015 I wrote an article intending to debunk some common myths about project management. Like many of you, I spent a reasonable amount of time during my first few years participating in online forums correcting agile misconceptions. Unfortunately, just like lopping heads off the Hydra, every time I'd address one myth, a short time later it would re-emerge. Recognizing the futility of trying to permanently suppress fallacies, I stopped responding to such discussions. However, as I would still like to help, writing an article on five of the most common agile myths will give me a reference to provide to folks in the future.

Agile projects and agile methodologies

There's no such thing. You can have projects which get delivered by teams using an adaptive life cycle or in which the team elects to use certain agile tools and techniques but unless the project itself is suddenly going to become sentient, it can't be agile. Agile is not a method (which is what most folks mean when they use the word "methodology"). A team or a company can create a delivery method based on agile values, principles and practices but that is just a single instance of an infinite variety of ways of delivering projects.

We need to do agile

Agile is an adjective, not a noun. Becoming (more) agile should also never be the goal of a team or organization but rather a means to achieving one or more goals. Make it a goal unto itself and the downstream impacts might result in worse outcomes than your current state.

Agile started with the Manifesto

The Manifesto for Agile Software Development is a curation of specific software delivery values and principles. None of these values and principles were revolutionary or novel in 2001 as they had all been identified before in one body of knowledge or another. Concepts, tools and techniques associated with agile have been used for decades and many popular delivery frameworks such as Scrum and XP were published before the Manifesto was written.

To be agile, you must be/have/do "X"

Whether it is sprints, story points, user stories, product owners, servant leadership or any one of a myriad of other roles, tools, techniques and buzz words, the agile community has become really efficient at dividing and conquering itself. Being agile needs to be assessed by outcomes and not merely by how those outcomes were achieved otherwise you risk sliding down the slippery slope to cargo cult.

Agile delivery is better (or worse) than waterfall

Context counts. There is a wide range of possible life cycle choices from fully adaptive to full predictive and very few projects fit cleanly at one end or another of the spectrum. Profiling a project to learn where it falls along this continuum is a critical step for teams to take when tailoring their approach to find better ways of delivering that specific project.

Any others I've missed? Feel free to respond in the comments and I'll add them to the list!