Introductory article on "Critical analysis of Agile Manifesto by a Serious Software Engineer"
The current article is first in a series of discussion on "Agile Manifesto" by serious Software Engineers for Software Engineers. I want to be all of the following in my current discussion: 1. Direct 2. Serious 3. Formal 4. Critical 5. Humble (Antonym of Arrogant)
What am I talking about?
I am a part of a study group that pursues Data Science seriously. In our last meetup we were discussing the Agile Manifesto besides other things that we are serious about and something stirred within me. This article is a result of that stir.
One might wonder what else is being discussed here besides the "Agile Manifesto"; after all, it takes two things for stirring and keeping a sane answer to one obvious question - "If you are stirring, then what are you stirring? Follow up question - with what else?".
For our serious group of thinkers #DataScience is important. In our group we are stirring Programming Business Communication andStatistics.
- In our group, within #Programming, there is #"Agile Manifesto", #"AWS Services", #"Python" and #"Object Oriented Design". And yes, we also discuss #PoliticalCorrectness.
- Within #Business is #"Key Performance Indicators" and #Reporting #Analysis #Visualization
- Communication and #Statistics can stand by themselves without explanation. I have written another article about Statistics.
- The rest of this article can be seen as my act of #Communication. You tell me about what you think in your comments to this article and the phenomenon called communication will happen.
Why So Serious and Direct?
Here's why : I am contemplating about launching an informal club of serious software engineers who pay to be a part of our group. Our learning group meets in Vancouver Downtown, BC; every Wednesday. I think people will pay; would pay because we are spending our focus and attention on them when when you have to speak about something serious with us. Our topic is "Data Science". For speaking about your pheromones and hormones and your dogs and your cats you can always find another group of people who are not us; serious and direct people.
This club will have only one KPI - "Overall growth in KPIs of individual growth of our members". Our guiding principles would be:
- Seriousness in Software Engineering.
- Adhere to Agile Manifesto
- Strive towards maintaining a gender ratio of 1.
- For improving representation in software profession
- Strive towards maintaining cultural diversity index of 1.
- For improving representation in software profession. 
Why seriousness matters
It can be safely assumed that the Agile Manifesto forms the basis of shared opinion among the community of software engineers . One can read about the Agile Manifesto to understand the guiding principles for Software Engineering profession.
The first lesson backed by serious software engineers is "Individuals and interactions over processes and tools". This will be the topic of our first critical analysis of the Agile Manifesto. because "Processes and Tools" are essential for serious Business thinkers, on the contrary "Individuals and Interactions" are valued by serious Programmers. Who should win?
Avoid leading to busted Myth
As an act of caution I want o highlight that - "Individual and Interactions" over "Processes and Tools" doesn't mean that Design and Architecture are insignificant. As a matter of fact, Design and Architecture needs a balanced amount of interacting individuals. Here's a quote to bolster this claim so that one can avoid the trap of falling into a Myth-Hole :
Agile does no design/architecture: This is a myth perpetuated by lazy developers who want to “build code like free-form poetry” (to quote my friend James King). The reality is there are some design aspects which need to be identified early in the project – what Philippe Kruchten calls the “architecturally significant non-functional requirements”. Any initiative which doesn’t have clear architectural guidelines from a very early point is setting itself up to fail. In Agile projects we try to defer making expensive to change decisions until as late as possible (keeping our options open) and we use the term “last responsible moment” a lot. Please note – there is a big difference between “last responsible” and “first irresponsible”! Another characteristic of good Agile practice is making architecture real as soon as possible – architecture is not a set of Visio diagrams or a PowerPoint deck, it’s a slice of the product built and proven to meet the important functional and non-functional needs of the product.- an excerpt from https://www.softed.com/news/what-agile-means-to-me/
Please share your comments. Let's communicate.
#update : I communicated on instagram
With tools such a #journals and #in-person-meetings, #intent  can be kept healthy in a cost effective manner. So, tools and processes are important and the argument is - ""Tools and Processes" for communication among "Individuals of a Team" are equally or more important than "Individual and Interaction"".
Sé, “Agile principles as software engineering principles: An analysis,” in International Conference on Agile Software Development, 2012, pp. 1–15 [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-642-30350-0_1
P. Kruchten, “The frog and the octopus: a conceptual model of software development,” arXiv preprint arXiv:1209.1327, 2012 [Online]. Available: https://arxiv.org/ftp/arxiv/papers/1209/1209.1327.pdf
J. Loh and D. Harmon, “A global index of biocultural diversity,” Ecological indicators, vol. 5, no. 3, pp. 231–241, 2005 [Online]. Available: https://www.terralingua.org/wp-content/uploads/2015/07/IBCD_ICE1.pdf