Lucian Whiteman wrote:I have over 10 years in the industry,
I have 30. I am a junior compared to some of the people here. Shared wisdom helps us all! :-)
Lucian Whiteman wrote:yet only today I got to read that agile manifesto.
I think this is a great point to start from - since you are admitting that you are new to the agile manifesto, I suspect that some of your misconceptions can be easily corrected.
Lucian Whiteman wrote:i) Individuals and interactions over Processes and tools.
Individuals = conflicting interest, conflicting visions, different capacity, egos. Why is there no mention of that ?
Interactions = on the fly decisions, inability to research the experience of others, the idea with most followers gets automatically chosen
It is important to realize that the manifesto is not suggesting we do away with the items on the right, or that the items on the left do not happen in other development models.
You have individuals in waterfall, and you have interactions in waterfall. The same problems you mention can also occur in a waterfall environment, however they are often mitigated in waterfall by a "my way or the highway" attitudes - something that can result in bad solutions being developed without consideration for better solutions.
Processes and tools also exist in agile environments. However the idea is that they are considered less important than actually talking with people.
Lucian Whiteman wrote:ii) Working software over Comprehensive documentation
Working = it works today, what about its technical debt ? What about its efficiency ? What about its modularity ? Why is there no mention of that ?
Documentation = straw man fallacy. How stupid needs one be to compare software with documentation ? Why don't they compare working software with free of bugs software, or with durability optimized software, or with cheap but buggy software ?
What about technical debt in a waterfall environment? It doesn't matter what process you follow, there will be technical debt. It is up to the company to manage that.
What about efficiency and modularity? There is nothing to say that you cannot be efficient when following agile or waterfall. There is nothing to say that you can, or cannot, write modular code in waterfall or in agile.
It sounds like you have not worked in a documentation heavy company - good for you! I have worked in companies that used the waterfall model, and some of the documentation was amazing. At one company, they had documentation for the project in six large binders before they wrote a line of code. And the documentation turned out to have made some unwarranted assumptions, resulting in reworking of both documentation and coding later.
Again - it is not that documentation should never exist. The authors are simply suggesting that getting the code written is more valuable than writing documentation.
Lucian Whiteman wrote:iii) Individuals and interactions over Processes and tools
You already mentioned this as your first point
Lucian Whiteman wrote:iv) Customer collaboration over Contract negotiation
Client has conflicting interests and vision with software firm and developers. Thus client cannot be best friends with dev. Why is there no mention of that ?
What about conflict situations and unpredicted difficulties ?
Who is responsible for what and who gets blamed for failures ?
The idea here is that we, as developers, should be partners with our clients. We should be working towards a common goal. Contracts still exist, and can define who is responsible for what. Resolution of problems still exist. But the guiding principle is that the customer is a collaborator on the project.
Trying to clearly define who is to be blamed for failure before there is a failure seems to be approaching development from the wrong perspective.
Lucian Whiteman wrote:v) Responding to change over Following a plan
Plan means initiative + research + agency + purpose. Why is there no mention of that ?
Again, there is no suggestion that you should not have a plan. A plan is a good thing. But if you cannot adapt your plan when things go wrong, then you are going to end up in trouble.
Lucian Whiteman wrote:Responding = passive + lack of ownership. How is that better ?
As before, there is a plan. Responding to problems is not lack of ownership.
Imagine if someone was driving down a road, and a child jumps out in front of them. The plan is to drive down the road. Responding to the change means swerving and/or using brakes.
Lucian Whiteman wrote:What causes this change ? What sort of change are you talking about, Obama ?
If we knew everything that could possibly change with the project, then we could cater for it. Can you imagine developing code 30 years ago and being tasked with writing it so that it supports mobile devices? Change happens!
Lucian Whiteman wrote:Where is the big picture and who has the general vision when this change happens ?
The team typically has a decent picture. They are typically working in collaboration with the client, who usually has a bigger picture.
Lucian Whiteman wrote:Following = someone else is responsible for that plan. Responding = someone else is causing your actions yet you are responsible for the outcome.
This feels to me like an antagonistic start to the project - I will do what I am told without worrying about whether it is a failure or not, as it is someone else's plan!
Lucian Whiteman wrote:“That is, while there is value in the items on the right, we value the items on the left more.”
Not enough courage to claim that the things on the right are of less value (to them) than the things on the left
That is exactly what the "we value the items on the left more" says.
Lucian Whiteman wrote:How much more value is one item on the left is worth than one on the right ? left = 101% right or left = 237% right ?
How much value ? How is this relevant to our daily work ?
Who cares about precise percentages? The manifesto is talking about a philosophy. Not 1001 rules that must be met exactly.
I'm stopping here for now, but hopefully this gives you some food for thought.