Agile: Guidelines or methodology?

Another discussion on LinkedIn, this time about whether Agile is a methodology or just guidelines. The consensus seems to be guidelines, which seems to reflect the spirit of Agile better.

But at the same time, this view seems only to address Agile in the abstract, not Agile (or any other delivery model) as implemented in any real organisation. Which is a pity, because it is at that point that the strains will start to be felt if Agile remains no more than guidelines. On the other hand, to convert it to a formal corporate methodology would not only defeat much of its underlying philosophy and approach but also lead to Agile being ossified in the same way that waterfall – which was never inherently rigid or bureaucratic – was ossified by immature implementations and too much top-down corporate management freakery.

And of course, there always been legitimate management reasons why Agile cannot be left to go its own way, any more than any other management tool. There will be inescapable (and entirely reasonable) reporting requirements, stakeholders will often want to know what progress is being made in non-Agile terms, and so on.

So, for any organisation that does not want to see something as promising as Agile degenerate into either paperwork or making it up as you go along, it is necessary to be rather more specific about how either a Agile-as-methodology or Agile-as-guidelines is implemented.

So even if Agile is to be forced into the mould of a corporate methodology, any self-respecting implementation can features that prevent it from becoming a rigid, inappropriate and self-defeating. For example:

• It will be specifically tailored to the type of work that is really being done.
• It will be abstract enough to permit considerable leeway for professional judgement.
• It will be fully scalable (no, not just big, medium and small).
• It will include user-friendly mechanisms for granting exceptions and waivers.
• It will include wide-ranging but rigorous (the very opposite of rigid) ranges of meaningful options.
• It will be implemented through training and tools, techniques and templates that make explicit the team’s authority to vary, depart from or just plain ignore the ‘rules.

And so on.

I don’t see that any of this gets in the way of Agile, or how any complex organisation could safely or profitably implement it without at least a few of these quite standard methodology components.