Stop Using /That/ Methodology

A methodology doesn’t describe what you should actually do to reach a solution, but how to move through space towards it.

Effectively, methodology defines how you should approach situations. It’s up to you to apply the methodology to reap its benefits in this reality, leaving you with a cornucopia of fun time at work, great productivity and an assortment of good feelings.

how a beautiful methodology (top) manifests into the world of the living bottom)

Dogmatic or pragmatic?

Let’s put our compilers aside and look at project management. The words that are most likely to come to your mind – Kanban, SCRUM, XP, Iterations… – all stem from the overarching concept of “Agile”.

Agile, the undying project management buzzword, refers to a simple series of principles that challenge traditional thinking as to what is most valuable when trying to deliver a software solution.

Deceptively simple, it was born in direct opposition to the Waterfall way of building software, which was the way “it had always been done”. The market was full of eager consumers and businesses couldn’t spare the immense up-front monetary and temporal costs of a Waterfall approach. Results needed to be delivered right now.

Agile promised to bring a product’s owners and builders closer together and move them away from a thoroughly detailed and rigid blueprint, and towards a perpetually evolving but responsive iterative process.

The Waterfall approach was, and is, dogmatic. Well defined stages flow from one to another, never going backwards or sideways, encasing the results in crystal as they move along. Deviation from the methodology is not welcome and, in tighter declinations, such as PRINCE2, not tolerated.

Agile, at first sight, looks pragmatic. It’s refreshingly uncluttered and is focused on delivering real value while constantly adjusting the course to the much coveted “Final Solution ”.

Still, as soon as Agile is implemented, it becomes every bit as dogmatic as waterfall, with well-defined roles, rules and ceremonies; a network of definitions and constraints that is, for the most part, mandatory, if the methodology is to produce proof of a project’s worth.

While delivering results seems to require a pragmatic approach, measuring results constrains us to dogmatic rules and procedures.

Is there any middle ground to be found?

The Dogmas of project handling

Depending on a project manager’s favourite flavour(s) of methodology, many different statements are enshrined and wrapped in trading card foil to become fundamental tenets of the project’s spiritual landscape.

Some or many of these statements make perfect sense until the next one is read:

• You shall not backtrack to amend your development once you’re done and testing, or else you’ll be testing a new system, which means testing it from scratch (Waterfall)
• You shall modify your development as soon as new requirements come in, or else whatever you’re developing will quickly diverge from what your client is expecting (Agile)
• You shall have a complete outlook of all your processes and eliminate anything that constitutes unnecessary overhead (Lean)
• You shall organize everything that comes through the workflow, no matter how minute it is and what the impact is, because if you don’t you might create unnecessary stopping points (Kanban)
• You shall set a stopping point to always have a quick meeting that will address the prior and the coming days, ensuring the time and duration are consistent regardless of what has happened or will happen in those days (Scrum)

None of these are optional in their specific methodologies and taking them out would deprive the methodologies of a significant pillar and undermine several other of their parts.

In short, without several, specific dogmas, many project management methodologies are just not sustainable and will let the project manager down on their promises (less blocks, better flow, faster delivery, pick one or several); this will in turn motivate the project manager to acquire a good whip and teach the dev team how to comply in a Friendly Manner.

And if the dogma doesn’t feel right to someone, disaster starts building up.

Failure to follow is just built-up failure

Any methodology, and especially any strict methodology, fears noncompliance above everything else. In fact, with regards to one of the benchmarks of strict definitions, the ISO standard, noncompliance is the key factor that determines failure, regardless of the actual result.

A methodology doesn’t tell you which actions you should take, but rather sets boundaries and guidelines on which actions are best taken in which circumstances. So if you explicitly ignore those recommendations, then your actions will, more often than not, result in an outcome that your methodology doesn’t consider… viable.

You can achieve any result, but if you haven’t kept to your duties and dogmas, there is no value or insight that your methodology can give you. Worse still, you’ll be on your own the next time, none the wiser.

The reason people embrace methodologies is the promise of bringing order into the chaos of project management (or lack thereof). But embracing something without paying the correct tribute, be it time tracking, documentation or stand-ups, is just additional chaos, and it’s far better to think about leaving out something than regretting not living up to it.