Old-school methodologies grow until they become the proper goal of the software development process.When an old-school methodology is created, a set of rules come into existence. Those rules are believed to make the software development process successful as promised by: Professors, Consultants, MBA's, etc.Since those methodologies come with such a high recommendation they obviously become the focus of management (especially if there are Professors, ex-Consultants or MBA's in that management). Having become the focus of management, the methodology will then be mandated to the whole organization, and it will be enforced by the "methodology-police" which is often consituted by those layers in the organizational-pyramid whose jobs depend on the importance of the methodology.The people that are normally most committed to the methodology are those that are promoted to positions where they perceive having more power, power which normally comes with the following attached: "You have power to enforce this methodology. We trust you to do that and to prove that we will give you bonuses based on how your people follow the methodology". These are also the members of the "methodology-police".Once this scenario is set the real problems start. These old-school methodologies often require developers and testers to produce certain things that are not software (often called artifacts or intermidiate deliverables). These artifacts are required because the methodology-police believes that they will ensure project success per se which, of course, is many times not the case...All these artifacts bring waste to the development process, but they are still seen as a stepladder to success. Also, the fact is that the methodology-police often has a very weak link to the actual running software: they just "manage" people that do have a direct link to the software, or worse yet, they only enforce the methodology. This often leads to an artifact-led software development process, as oposed to a "running software"-led development process.Help on the way?Agile methodologies with their emphasis on "Running software" reduce the need for those artifacts, for the complexity of the methodology and in turn reduces the need for the "methodology-police". Don't get me wrong, you still need coordination (lead developer, lead tester, scrum master/agile project manager), but that coordination only exists with the goal of facilitating the most important role of the software development process: "writing working code that solves a problem for the customers/users".The conclusion is that Old-school methodologies for software development cannot be as productive as Agile methodologies because they require more waste.You may ask: but we have big teams, in many places they surely need some structure (read old-school methodologies and methodology-police).Yes, they do, but that's why you should - if at all possible - have small super-productive teams that can deliver software!Ther are other obstacles to having small teams deliver software that is very complex, but all can be surpassed. The question is: who will do it first? You or your competitor? You decide... Posted by

Old-school methodologies grow until they become the proper goal of the software development process.

When an old-school methodology is created, a set of rules come into existence. Those rules are believed to make the software development process successful as promised by: Professors, Consultants, MBA's, etc.
Since those methodologies come with such a high recommendation they obviously become the focus of management (especially if there are Professors, ex-Consultants or MBA's in that management). Having become the focus of management, the methodology will then be mandated to the whole organization, and it will be enforced by the "methodology-police" which is often consituted by those layers in the organizational-pyramid whose jobs depend on the importance of the methodology.

The people that are normally most committed to the methodology are those that are promoted to positions where they perceive having more power, power which normally comes with the following attached: "You have power to enforce this methodology. We trust you to do that and to prove that we will give you bonuses based on how your people follow the methodology". These are also the members of the "methodology-police".

Once this scenario is set the real problems start. These old-school methodologies often require developers and testers to produce certain things that are not software (often called artifacts or intermidiate deliverables). These artifacts are required because the methodology-police believes that they will ensure project success per se which, of course, is many times not the case...

All these artifacts bring waste to the development process, but they are still seen as a stepladder to success. Also, the fact is that the methodology-police often has a very weak link to the actual running software: they just "manage" people that do have a direct link to the software, or worse yet, they only enforce the methodology. This often leads to an artifact-led software development process, as oposed to a "running software"-led development process.

Help on the way?

Agile methodologies with their emphasis on "Running software" reduce the need for those artifacts, for the complexity of the methodology and in turn reduces the need for the "methodology-police". Don't get me wrong, you still need coordination (lead developer, lead tester, scrum master/agile project manager), but that coordination only exists with the goal of facilitating the most important role of the software development process: "writing working code that solves a problem for the customers/users".

The conclusion is that Old-school methodologies for software development cannot be as productive as Agile methodologies because they require more waste.

You may ask: but we have big teams, in many places they surely need some structure (read old-school methodologies and methodology-police).

Yes, they do, but that's why you should - if at all possible - have small super-productive teams that can deliver software!

Ther are other obstacles to having small teams deliver software that is very complex, but all can be surpassed. The question is: who will do it first? You or your competitor? You decide...