Methodologies without dogma

In the working world there are people who talk about methodologies the way others talk about football teams. The “agile” ones see planners as fossils; the planners see the agile ones as reckless amateurs. It is a debate that wastes a lot of time and has never finished a single project.

A methodology is a set of principles, rules and practices for organising work. Some are only principles (like Agile), others are complete systems of themes and processes (like PRINCE2), others again are bodies of standards (like the PMBOK) or simple processes (like Scrum). None is right in absolute terms. Each is right for something.

Before the method: the life cycle

Every project goes through five phases: initiation, planning, execution, monitoring, closing. What changes from one approach to another is how you go through them.

Life cycle	How it works	When it makes sense
Predictive (waterfall)	The phases are crossed once, in order. Everything is planned at the start	Clear, stable scope, a single final delivery
Iterative	The phases repeat, and the solution is refined at each round	Scope isn’t clear, but you want to reach the best solution
Incremental	One working piece is delivered at a time, each complete	You need to deliver early, and the rest can wait
Agile (adaptive)	Iterative plus incremental: short cycles, each with its own feedback	Change is likely and feedback is essential
Hybrid	Approaches are combined, phase by phase	Almost always, in real life

The most widespread methodologies

• Waterfall. Detailed planning, sequential phases, documentation. It promises predictability on time, cost and scope. It works when requirements are stable; it suffers when they change halfway.
• Scrum. A small, cross-functional, self-organising team working in short cycles (sprints, usually one to four weeks), starting from a prioritised list (the backlog) and closing each cycle with a review and a retrospective. It works when you can deliver in pieces and the client takes part; it hollows out when only the ceremonies remain.
• Kanban. Makes the work visible on a board, limits work in progress, improves flow. It has no fixed cycles: it is ideal for continuous work, like a creative department that receives requests every day.
• Lean. Eliminate waste, maximise value, keep improving. It is more a philosophy than a method, and it was born on the factory floor, in the Toyota Production System.
• PRINCE2. Defined stages, roles and responsibilities, constant control: PRojects IN Controlled Environments. It works in large organisations and in projects where every step must be accounted for.
• Crystal. People and interactions at the centre, rules adapted to the size and criticality of the project.

The agile manifesto, in brief

In 2001 seventeen software developers signed the Manifesto for Agile Software Development. It says it values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. And it adds a sentence the fans often forget: while there is value in the items on the right, the items on the left are valued more. It is not a manifesto against planning: it is a manifesto about priorities.

How to choose

Before choosing a method, it pays to ask six questions about the project.

Question	If the answer is…	…it leans towards
Is the scope defined and stable?	Yes / No, it will change	Predictive / Adaptive
Is the team large or small?	Large, with different roles / Small	Predictive / Adaptive
Does the client take an active part?	Only at the start and end / Yes, often	Predictive / Adaptive
Is the budget fixed?	Yes / There is flexibility	Predictive / Adaptive
Are the deadlines rigid?	Yes, with a single delivery / We can deliver in releases	Predictive / Adaptive
Can we think in terms of an MVP?	No, everything is needed at once / Yes, we start from the essentials	Predictive / Adaptive

The answers rarely all point the same way. That is where the hybrid approach comes from, and it is the rule rather than the exception. A common example in agencies: contract, scope and main milestones managed predictively, because the client needs firm dates and costs; production organised in sprints, with frequent reviews; ongoing requests and small maintenance handled on a Kanban board.

The most common mistakes

• Method as identity. When a team defends its method more than the result, it has stopped working for the project.
• Ceremonies without substance. Stand-ups, sprints and retrospectives held out of habit, without anything changing. Agile in name only.
• Method as an instrument of power. Rules used to control people, not to help them work.
• The rigidity of those who foresaw everything. In Waterfall, anything that wasn’t foreseen becomes a weak point. The plan is needed; the unexpected comes anyway.
• Switching method halfway without saying so. The client thought they were buying a defined result and finds themselves inside an iterative process, or vice versa. The methodology must be declared, in the Statement of Work.

Learning from mistakes, together

The last thing methods have in common is the most important: they only work if you look back. Retrospectives, debriefs, lessons learned: whatever you call them, they are the moment when a team decides what to keep and what to change. That is where a method stops being a dogma and becomes a way of working.