Agile was supposedly a very good approach and a highly promising one when it came in several years back.
And it appeared as if the software world had finally found the "silver bullet".
But that was not to be.
What has happened to the good, old agile? Is it dead now?
The die-hard agile enthusiasts always used to write it as Agile (with capital A) but now they don't mind using agile (with small a).
This is a seemingly simple yet a very powerful change.
Agile originated with its own peculiar contradictions.
This is clearly reflected in agile manifesto which has undoubtedly been crafted very beautifully but has an adversarial tone.
For example, saying "people over processes" has a fundamental flaw. Both are important and the right approach would be "people using processes".
It is important to always remember that "processes" are created by people and have no intelligence of their own other than what the people defining the process put into them!
So if there is any issue with the process, it should be fixed by the people who are supposed to use it and by those who are responsible for maintaining it.
Also lack of commitment to the process and the needed competency to follow the process should not become excuses for giving a bad name to the process.
Never forget - process by itself is completely dumb!
People, however, should not be dumb. By not following a process they act like one.
A process is simply a path you take to go from one state/place to another state/place.
The key success criteria as you travel on the path as captured in the process are related to certainty and consistency of the outcome.
In the software world the biggest challenge has always been this - most of the practitioners undermine the value of a systematic and structured approach to writing software.
Writing software is seen as a creative activity like painting or sculpture. That is not totally right. Writing software should be seen as an engineering activity like building a bridge.
The initial part of the software writing which has to do with software architecture does involve some creative thinking but this needs to be necessarily within the boundaries set by technical feasibility of the proposed solution and the business context where the software will eventually fit into.
More than a software development approach, agile became a symbol of anti-establishment and its premise was primarily to correct what was wrong with the traditional approaches.
There were many traditional approaches when agile came in, but waterfall symbolized this so called "evil" affecting the software world and became a favorite punching bag of the agile enthusiasts.
The other issue with agile has been too much focus on rituals. Statements like "if you are not doing daily scrum you are not doing scrum" cause more harm than benefit.
Blind insistence on following rituals and minimal or no willingness to accommodate appropriate tailoring in accordance with varying situations in each project can result in process rigidity.
At the same, allowing too much of flexibility under the garb of "being agile" can lead to lack of a basic operating structure and eventually chaos.
The best approach is to mandate a certain core structure and set of practices that give a solid foundation.
Examples would include the following - having a plan/WBS, insisting on weekly status reviews (details of the how can be left to the judgment of the project team).
The remaining processes and practices should be evolutionary and should be adopted to ensure the objectives of the project are met.
There also there should be extensive guidelines and operating procedures that can be leveraged by customizing them appropriately in line with the project-specific needs.
The good, old agile may be dead.
Or may be not.
Because even before agile came into being there where many approaches with a similar philosophical outlook like incremental, iterative, spiral, etc.
The term agile was surely new but the underlying principles were not.
Since agile was never born, it will never die as well!
The core objectives of any engineering endeavor (quality, scope, time and cost) as well as the fundamental principles and foundational elements of how to do good engineering including writing software has been there since centuries.
And they would not undergo any change. Why should the basics change?
And it appeared as if the software world had finally found the "silver bullet".
But that was not to be.
What has happened to the good, old agile? Is it dead now?
The die-hard agile enthusiasts always used to write it as Agile (with capital A) but now they don't mind using agile (with small a).
This is a seemingly simple yet a very powerful change.
Agile originated with its own peculiar contradictions.
This is clearly reflected in agile manifesto which has undoubtedly been crafted very beautifully but has an adversarial tone.
For example, saying "people over processes" has a fundamental flaw. Both are important and the right approach would be "people using processes".
It is important to always remember that "processes" are created by people and have no intelligence of their own other than what the people defining the process put into them!
So if there is any issue with the process, it should be fixed by the people who are supposed to use it and by those who are responsible for maintaining it.
Also lack of commitment to the process and the needed competency to follow the process should not become excuses for giving a bad name to the process.
Never forget - process by itself is completely dumb!
People, however, should not be dumb. By not following a process they act like one.
A process is simply a path you take to go from one state/place to another state/place.
The key success criteria as you travel on the path as captured in the process are related to certainty and consistency of the outcome.
In the software world the biggest challenge has always been this - most of the practitioners undermine the value of a systematic and structured approach to writing software.
Writing software is seen as a creative activity like painting or sculpture. That is not totally right. Writing software should be seen as an engineering activity like building a bridge.
The initial part of the software writing which has to do with software architecture does involve some creative thinking but this needs to be necessarily within the boundaries set by technical feasibility of the proposed solution and the business context where the software will eventually fit into.
More than a software development approach, agile became a symbol of anti-establishment and its premise was primarily to correct what was wrong with the traditional approaches.
There were many traditional approaches when agile came in, but waterfall symbolized this so called "evil" affecting the software world and became a favorite punching bag of the agile enthusiasts.
The other issue with agile has been too much focus on rituals. Statements like "if you are not doing daily scrum you are not doing scrum" cause more harm than benefit.
Blind insistence on following rituals and minimal or no willingness to accommodate appropriate tailoring in accordance with varying situations in each project can result in process rigidity.
At the same, allowing too much of flexibility under the garb of "being agile" can lead to lack of a basic operating structure and eventually chaos.
The best approach is to mandate a certain core structure and set of practices that give a solid foundation.
Examples would include the following - having a plan/WBS, insisting on weekly status reviews (details of the how can be left to the judgment of the project team).
The remaining processes and practices should be evolutionary and should be adopted to ensure the objectives of the project are met.
There also there should be extensive guidelines and operating procedures that can be leveraged by customizing them appropriately in line with the project-specific needs.
The good, old agile may be dead.
Or may be not.
Because even before agile came into being there where many approaches with a similar philosophical outlook like incremental, iterative, spiral, etc.
The term agile was surely new but the underlying principles were not.
Since agile was never born, it will never die as well!
The core objectives of any engineering endeavor (quality, scope, time and cost) as well as the fundamental principles and foundational elements of how to do good engineering including writing software has been there since centuries.
And they would not undergo any change. Why should the basics change?
