Perhaps the thing that frustrates me the most about the contemporary business culture is just how much dishonesty and outright gaslighting has become entrenched practice when talking about methodologies for working.

A great example of this is "Agile". In 2001 the Agile manifesto was written. That sparked many discussions about what the best way to deal with projects that had a significant amount of uncertainty in terms of the scope. To understand anything about what this was about requires understanding the context. The Agile manifesto was written by software developers talking about how to develop software. Developing software is very much unlike developing many other sorts of projects. Software projects offer almost unlimited opportunities to attempt to make changes as the project progresses. The costs of changes to software vary enormously, some changes are almost trivial but some seemingly trivial changes can be incomprehensibly difficult and expensive from the perspective of an outsider. Because change management is so fundamental to all software development and maintenance projects it makes sense that an approach that puts change management front and center would be a natural outcome.

Adopting a methodology centered around reducing the costs of making changes is not always appropriate. There's many examples of projects where you do not want to make many changes after you start, and those sorts of projects are unlikely to be well served by a naive attempt to implement vague ideas that are "agile". Where costs of changes are high you should immediately be questioning if agile is appropriate.

Last year I saw a project proposal where in response to questions about the project management methodology being used on the project a word salad answer was to say that the project was using PMBOK, waterfall, scrum and Agile was thrown in as a bonus buzzword. The insanity here is that these different methodologies are mutually incompatible and not just in a minor way. But this sort of insanity is now quite common. In retrospect this was a massive red flag, the sales lead on that highly technical project was dangerously clueless and basically threatened the entire project by making word salad types of responses about very important aspects of the project without consulting the technical implementation team first. To many of these charlatan types throwing in "agile" is just a get out of jail free buzzword and is used as such in this empty manner.

More often is something I saw when I was working in Brisbane at a consultancy firm, they said they were doing agile to their clients while they really were just bastardizing scrum to get as many billable hours extracted as possible from their staff. I remember being in over 40 hours of meetings one fortnight with this company. Nothing says "we aren't lean on management" like 20 hours of meetings a week. Of course this was not agile in any sense of the word, it was an excuse to have as many meetings with as many staff as possible on high billable hours. But with any sort of entrenched dysfunction like this it takes two to tango as they say. The client went for this for some reason, it quickly became painfully clear to me that they also had no idea what agile development looked like. For a term used so frequently these days it seems it is frequently misunderstood. There are whole groups that deliberately misinterpret and misrepresent themselves as being "agile", they do this because at least for now it makes them money. If the buy side becomes more aware of this grift the profitability of it will decrease and eventually the term will fall out of favor, but we aren't there yet. We now have whole frameworks like SAFe, the so called "Scaled Agile Framework" which is anything by agile and certainly is anything but a good idea. The agile principle of valuing "individuals and interactions over processes and tools" is trampled over by just about everything in SAFe. The SAFe framework appears to be successful because it takes a currently popular buzzword and bastardizes it entirely to just tell dysfunctional middle to upper management exactly what they want to hear. Essentially its a highly bureaucratic framework with a buzzword tacked on in such a way as to make Orwell proud of their linguistic achievement in doublespeak. As a cynical exercise in selling consulting services SAFe is a masterpiece but this is not an agile methodology as per the agile manifesto.

External consultant charlatans and grifters love things like SAFe and other agile grifts because they make a ton of money out of it, and disappear before the terrible results manifest later. But why does agile gaslighting happen internally in organizations? implementing "agile" approaches, and in particular terrible systems like "scrum" is often used as a path to micromanagement and overworking staff without explicitly saying so. This has an appeal to certain archetypes of bad management, you can take good old micromanagement and death-march project management and throw it behind a linguistic facade that says you are doing something else. Because people aren't always on top of manipulative word games like this you can buy some time before people notice what you are doing has nothing really to do with agile, if you get lucky nobody informs themselves and this can carry on for a long time. The SAFe framework is a perfect example of this insanity being distilled into a bureaucratic process. SAFe is as far as I can tell just a micromanagement framework sold as "Agile to check some boxes on the buzzword checklist. But there's a lot of home cooked versions of this insanity. I worked at an engineering consulting firm in 2016 that had their own version of "agile" insanity, they took Scrum and completely bastardized it. The way they did this was to effectively remove real retrospectives instead replacing them struggle session like meetings where the CTO would shame and abuse staff who's billable hours had dropped for any reason. This included situations where programmers had worked on internal projects at the explicit direction of management, and he'd often abuse them too without checking if they were actually doing what they were told. He was one of the most hideous CTOs I've seen in my career. The firm used sprints as a way to overwork the consultants and provide two week billable hours updates to the customers. They made sure they never took action any customer feedback whatsoever unless it made them considerably more money and they'd time those changes in the most cynical ways possible. They had daily "stand up" meetings with the team, and had daily "stand up" meetings with the clients, all billed hours of course so any attempts to make these meetings efficient would be avoided. Then to top it all off they deliberately played the "lets abuse the clients by playing the expensive change requests" game. Franz Kafka would be proud of how twisted they were with this version of Scrum. One thing they loved was "sprints" and telling the customers about what's in the next "sprint". This was a perfect way to ensure maximum billable hours and of course staff burnout for anyone who didn't pad their work to meet the unrealistic and entirely arbitrary timelines that now were applied to everything. The change requests game in this case involved understanding the clients requirements, not to actually implement those changes early on sprints but rather to wait to the client was near the deadline to extort the client with expensive change requests that would be done only when the client couldn't cheaply or easily back out of the deal. Its hard to think of anything less in line with the spirit of the original Agile Manifesto. The whole thing honestly was fraudulent and I'm glad I don't work there anymore. But of course this company told the world how "agile" they were and unfortunately some of their customers believed it, some of their customers deserved to be defrauded however as they were just as dishonest, sometimes it really does take two to tango. Around this time Ron Jefferies published his article about "Dark Scrum" which left an impression on me be because I'd just been subjected to it. I think this was around about the time I realized I never wanted to waste any of my time on any of this nonsense in the future and I'd tender my resignation quickly if upper management wanted to impose Dark Scrum on me or my team.

The real reason why that particular company did anything was simple, it was just about extracting as much money as they could whenever they could. Short term thinking was the only thing that mattered. They didn't give a shit about any of the values they stated they had whenever even the smallest amount of resistance would arise. The whole point about values is that values are valuable because they are expensive. Usually there's a cost associated with upholding values.

Good video here about "agile signalling": https://www.youtube.com/watch?v=1VZcOpXyS8A

Much like other forms of signalling sometimes organizations will attempt to send a signal that their internal processes are something other than what they really are. Effectively they will only engage in this active dishonesty if they see it as being in some way beneficial for them to do so. Because a lot of people uncritically assume that agile is a panacea we will continue to see businesses claiming to engage in agile processes, even if they don't actually use them internally.