Methodology or dogma in software development, a plea for common sense

Alarm bells ringing….. “ did I really just hear a scrum master say, in a discussion about the duration of a sprint, that it should be in weeks and not in calendar months because in scrum sprints are in weeks???”

Do you really only want to do something because it is written in a book? History proves it is risky business if people apply a dogmatic approach and follow books or ‘leaders’ blindly.

Of course it is perfectly logical that people seek ‘guidance’ when they try to accomplish an objective. Therefore it is also logical that systems (like methodologies) have emerged to help people.

Why are there methodologies?

Most of the time people do not do things just randomly, but have a goal they want to achieve. In order to achieve any goal, one has to perform several actions. The quality of performing these actions that you perform these actions can determine the success rate in achieving the goal.

People generally don’t just start doing something in an effort to accomplish a goal, but they use a methodology that offers structure and support. A methodology combines a combination of methods in order to do so.

Methodology versus framework

So far I have only used the term methodology, but the terms methodology and framework are often used interchangeably However, there is a clear distinction:

• Methodology: a set of principles, tools and practices which can be used to guide processes to achieve a particular goal.
• Framework: a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.

The main difference is that a methodology is much more prescriptive than a framework, it has a more clear set of rules which should be followed in a particular order.

A framework on the other hand is of a more liberal character and offers more room for creativity, with the result that it is more ambiguous.

Why I prefer a framework

I personally favour a framework, as the key component in the definition is the word “supporting”. It should help you achieve a certain goal. It should provide you with guidelines on how to approach the process, or offer elements that can be helpful.

It should not dictate which steps should be followed. Use the elements that help, and discard the ones that do not.

In my opinion, this gives you more adaptability in contrast to a more rigid methodology.

Most of the time, our environment and the discipline we work in is of a complex nature. The rigidity of a methodology is in my opinion a limiting factor. The flexibility of a framework offers the agility needed to adapt to this complexity.

So what now?

Abundance is everywhere in the western world. If you don’t believe me, take a look at this (undoubtedly incomplete) list of Android based smartphones: https://en.wikipedia.org/wiki/List_of_Android_smartphones

The same goes for methodologies and frameworks in (project) management and software development, and the overlapping realm. Over the years, countless new methodologies have been introduced, sometimes based on new insights or in order to adapt to a changing world. But often it is merely old wine in new bottles. The sheer abundance should be a clear sign that no single methodology offers you the holy grail.

Besides that, methodologies are big business for a lot of consultancy and training firms, creating so called “certified” specialists, blabla masters, ninjas, evangelists etc.

The sign of a money generating business is when they are treated like a religion.

There are some elements that I often use

• Think for yourself, be a freethinker
• Use what helps YOU to achieve YOUR goal
• KISS (Keep It Simple Stupid), or as Einstein said: Everything should be made as simple as possible, but not simpler.
• Use books and its rules as inspiration, not as a dogma.

In other words, use common sense (or “boerenverstand” as we call it in Dutch). I think it is important to think for yourself. The grey matter in your head should be used for being open minded, being critical and being inquisitive, instead of being used to just blindly follow someone else’s ideas.

This blog represents my personal opinion based on over 25 years experience in (project) management. You are free to disagree and I welcome discussion, as long as it is of constructive nature.

Jeroen Vossen, Team manager @ Maatwebsite