Project Management

Let's flatten five agile fallacies!

From the Easy in theory, difficult in practice Blog
by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

Securing contingency reserves is the responsible thing to do!

Let's flatten five agile fallacies!

Planning for those project disasters that no one wants to think about

What's the link between emotional intelligence and psychological safety?

How do you build your brand as a project manager?


Categories: Agile, Project Management


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!

Posted on: September 13, 2020 07:00 AM | Permalink

Comments (12)

Please login or join to subscribe to this item
Kiron,
thanks for setting this straight.

I totally agree with you Kiron especially on the first point as many believe Agile is a Methodology and I see this a lot.

We need to be agile first to do agile.

Profoundly stated Kiron and Thanks.

Thanks Eduin! Thanks Eduin! :-)

I'll admit to channeling John Boyd here. Getting quickly to what's usable quickly and then updating one's thinking for the next advantageous iteration perhaps is the Agile point. Rami's comment is similar to a state of being instead of a methodology.

Thanks, Kiron.
Something I have seen too often is speaking of Agile and Scrum interchangeably. I also see a weighted perception that Agile is specific to, or can only be adopted in the software industry or information technology.

As usual, great article Kiron. Some companies just want to get the job done, and label their tasks as being Agile, without really looking at the intimate details. You explain what makes the project Agile. Thanks.

Please Login/Register to leave a comment.

ADVERTISEMENTS

It is better to ask some of the questions than to know all the answers.

- James Thurber