Why be "agile" when effectiveness is what counts?

It struck me today whilst talking to a colleague how the term "Agile" can easily be misunderstood.

Colleague: "Agile is SCRUM, a load of stakeholders get together in a meeting and decide by committee what development will happen the next week"

"Agile" is not just SCRUM or really any other "Agile" methodology; it seems to me more of a loose collection of principles to organise delivery sensibly and allow large companies to operate more like small ones. Agile, SCRUM, Kanban, XP are just methodologies are just tools, and as any DIY enthusiast knows choosing the appropriate tool for the job is paramount in any life or death shelf hanging scenario.

"Agile", in my opinion, has become over-used and under-understood owing mainly to the aspirational nature of the word. We've seen numerous CVs with a heavy sprinkling of "Agile" dust only to find the candidate has little or no understanding of "Agile" development practices. Worth noting it's also a very easy word for agents to substitute in before others such as project, team, architecture. Agile Architecture?!

Effectiveness over "Agile"-ness

The real goal is not to be "Agile", or adopt some set of sacred practices in the hope that this new religion will suffer none of the weaknesses of the old; but discover a software development methodology that works for your team's situation. A good place to start is by learning the principles of Agile methodologies (see The Agile Manifesto and The Twelve Principles), reading a few different books, sharing experiences with people doing it in anger and not just writers or non-practising conference circuit theorists.

If you can understand these principles, and have a broad knowledge of the tools available then you're in a place when you can start to effect change.