I recently read again the article Principles VS Methodology, by Javier Cañada, a reference for me. In this text, he explains how, for him, the methodology is in the background in favour of universal design principles.

He looks at it from a design point of view, but I can not agree more if we apply it also to the complete development of a product on the Internet: the methodology is only a means to obtain a result and must be subject to it.

This does not mean that methodology is unimportant. When you work as a team with a group of people, however senior you are, you need some sort of organisation and set some minimum work agreements.

That is why, inevitably, we need a methodology and, therefore, unlike Javier, I do continue to feel interested in this area, but seen from this point of view. I do not feel a fascination for the process itself, but I understand it as a means that allows you to bring greater value to the outcome of a project.

After a few years of experience, it is clear to me that agile methods, and in particular scrum, is the “least bad” methodology for addressing Internet projects. It is very far from traditional predictive methodologies, in fact, it is not defined as a methodology, but rather as a lightweight framework whose goal is to get the most out of the team and the available budget.

I especially like it because:

Agile des not mean “fast” as many customers think. If I had to summarise it I would associate it with the concepts of quality, efficiency and, above all, to maximise the delivered value.

I love this definition made by Tobias Mayer about scrum by 2009. A summary in only 4 paragraphs that emphasises its simplicity and its principles:

Scrum is a framework to improve the way people do their work, or as defined on the Scrum Alliance site “a framework based on the team to develop complex systems and products”. Scrum uses an iterative process where each iteration (called Sprint) is as short as possible, progressing at a similar pace with planning, execution, and reflection.

Scrum specifies three roles (Scrum Master, Owner of the Product and Team), and requires a prioritised set of objectives, a commitment in each sprint, and an easy way to measure progress. It uses time-limited ceremonies to plan, to inspect/adapt daily, and to inspect/adapt between sprints.

There is a clear distinction between “What to do” (the goal) and “How to do it” (the way).

Scrum requires clear focus, commitment and transparency at all levels; adopts and emphasises among others the human values of trust, integrity, courage and respect.

The real danger of any methodology is that it becomes itself a goal, making us lose the focus of the real objective (the result), to focus on meetings, dates, reports and estimates.

A few months ago, our Agile Coach, Javier, made an interesting reflection:

How many times a day do you hear the word planning and how many times a day do you hear the word value? I think there is a certain tendency to put the focus on fulfilling a planning and not on delivering value to our clients.

This tendency is the real danger to which we must not submit. We must always remember that methodology must be based on principles and be at the service of the result.

But even in the background, methodology remains very important. I agree with my partner David that: “It’s people and not methodology that take the projects forward”, but I also think that agile methods only set certain guidelines that, far from harming you, make a team give the best of itself and work as a well-geared clock, but without restricting creativity and without the need for over-efforts.

Tell us what you think.

Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.


We are committed.

Technology, people and positive impact.