We've figured out 20 years ago that writing code, showing the resulting program to customers and getting feedback was the most effective way to find out if you're actually solving customer problems. Some group of people wrote about it in something called the "Agile Manifesto" or some such.

How do you think an author of the Agile Manifesto would respond to the original article?

Considering how companies are implementing the "Half-Arsed Agile Manifesto" rather than the actual "Agile Manifesto", I think reading this article might be what pushes them to jump off a bridge. 20 years of companies failing to understand your 4 line text, and using it to justify things that are utterly antithetical to what it stood for, has got to hurt. It's so simple:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

Sounds like an environment the author of the post would like, he even describes such an environment later on, one that he enjoys so much he overworks for no extra pay.

Then there's the twelve principles, one of which is:

"Working software is the primary measure of progress."

Another one is:

"The best architectures, requirements, and designs emerge from self-organizing teams."

Another is:

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Following bullshit company processes and pointless meetings is the opposite of the above. The one that might be contentious is:

"Business people and developers must work together daily throughout the project."

This sounds a lot like meetings, but that's the smallbrained take on it. Here's an easy alternative: Continuous Deployment in a staging area and a Slack/Teams channel for business people to comment on changes they feel are necessary. Not only does the request get recorded (often nothing gets documented in meetings) but the communication is asynchronous and doesn't require booking the entire team for hours. The discussion is also a lot more actionable because it is about something concrete.

Given the above, what do you think about how an author of the manifesto would respond?

I imagine the author of the original article works in a company which is prioritising the right hand of the principles over the left. We've all worked there, we've all hated it. I did, so I set up my own company where we'd do agile right.

Hired my own team of devs. Got no revenue, velocity was low. Ended up annoying all the devs by trying to push them to spend more on the right-hand side of the manifesto than they thought was necessary so I could figure out why nothing was getting done. Still got no revenue. Eventually gave up.

I think the authors of the agile manifesto would say that building complex software requires the business to adopt agile (real agile, not half-arsed agile) with the tech team subsequently following it. The engineers also need to deliver on their side of the bargain. That means continous value, and not just fiddling with shiny new tech and fancy design patterns. When both sides of that operation work well together, you get good software. If you've got enough good people that already know how to do this, it bodes well. But how do you find and pay for all these good people? That's why you get people that merely think they're good, but are at least much cheaper.

The engineering tendency when given freedom is to over-engineer everything, leading to disappointed clients, and a fragile system that's buggy and can't be fixed. It's one of the big reasons so many tech-led startups fail, and also why bigger businesses end up putting all these bullshit processes in place.

And that's my take on the OP. Lots of "managers bad" without recognising the faults of engineers in that process.

I'm sorry to hear that, indeed, the engineers have to follow through on their end as well. That means "working" software, minimally functional, has to be delivered ASAP, at least to be able to gouge customer engagement.

"Design Patterns" and the latest "Web Framework" fad are the opposite of delivering working software. How you find people with the right mentality? I'm not sure.

Low-level game devs tend to have that "make it work" mentality but they like to reinvent the wheel a little too much because the existing wheel is 0.1% slower than their custom made one.

Web devs are the opposite, they seem to think the wheel has manifested itself from the ether. They probably don't even know about half of the 50 wheels they brought into the project, and they'll replace them with newer, shinier wheels in a week.

I think hiring a good team lead with the right priorities is key. Not a "manager", but the team member everyone else looks up to and follows out of their own volition. It might be worth wasting a lot of money and time on finding and hiring that person at the very beginning. If you do, the rest should fall into place, as they'll hire people who work well with them, meaning same priorities.

Look at the impact someone like Jim Keller had on the companies he worked for, as an example.

Yep, both managers and contributors have a faulty model of agile. We're all guilty of it, even those of us who know it when we see it because we know the theory so well.

Finding people with the right mentality is, as you say, very hard.

The temptation of the manager is to get people with the wrong mentality and wrap them enough process that it will fix them. The temptation of the contributor is to blame the manager without looking at their own faults.

As good a solution as I can suggest is to work with people who are willing to collaborate on a positive outcome, and go through genuine continuous improvement.

And just to clarify, I've been both the "shinny new framework" and the "I can make it 0.1% more efficient" guy at different points in my admittedly short career (still a senior though). These days I'm the "make it work" guy but only after suffering the negative outcomes of the other two a little too much. You only really "get it" after doing the "wrong" way first.

I've also had to deal with the "bad" manager that gives no push (nor any time) for stabilization, leading the code to a near-project-killing state of constant malfunction. Quite a few of the principles in the manifesto are about avoiding exactly this state, but they too are not followed correctly.

The following are in a different order in the manifesto, but I think this should be the way to read them, they almost form a coherent paragraph:

"Continuous attention to technical excellence and good design enhances agility. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

This means quality needs to be considered from the beginning and maintained, but that's not contradicting the fast delivery, quite the opposite (proven by many studies on Continuous Delivery).

Quality arises from constant refactoring the working code to be better, based on the results obtained from seeing that code running. Not from planning ahead with some insane micro-service bullshit architecture 3 months in advance for a project that probably will never scale to a size that needs that nonsense (at which point you deal with it).

But you have to give time for that cleanup work, and introduce a culture that demands that quality (where quality is measured by the software working well and delivering value, not by how theoretically "clean" the code is) otherwise it simply won't happen.

I've also had to deal with the "good" manager that tries to fix the above issues (after they happened) with processes. In my experience they just slow down velocity and don't resolve any of the actual problems. It's like telling a plumber that is almost swimming in shit to read and sign a 20 page document before turning off the valve of the pipe that's spewing brown liquid everywhere. That plumber is just going to hate you.

The only thing that works is to demand both continuous delivery and consistent quality (and allow time for the latter at the expense of the former if need be), ensure you have the right lead, communicate openly and regularly, and then let the team do its thing. If the devs and PMs don't see each other as allies rather than annoyances, the whole thing falls apart.

Also all it takes is 1 bad dev to spoil the bunch, I've seen them do so much damage it's nuts (stuff like introduce some whole new web framework nobody else in the team knows on some part of the project, or rework entire parts of the code to be async even though then it doesn't work with the rest of the codebase). Code review / pair programming is supposed to prevent this but if the team lead lacks the strength to keep devs like that in line, you're screwed anyway.

"Individuals and interactions over processes and tools"

If the individuals and interactions are wrong, no amount of processes and tools will fix it... I guess companies the size of Microsoft and Google can throw enough money at the problem that things work out somehow, despite the abysmal quality of most of their software.

Pretty well since he at VFX company he seems to working closely as a team and with his customers.