[throwaway202212]

Running agile in a small team is one thing, having a company do "agile at scale" is quite another (yes I realise the contradiction in terms). As someone who worked at McKinsey, on several large scale "agile" rollouts the bulk of the work was on re-organising the company (this is not an easy thing to do in companies with thousands of employees - hence bring in the consultants). The driver behind these projects was almost always cost cutting or increasing efficiency. The agile part was mostly window dressing.

[azemetre]

No not at all; this org had existed for two years already, was already using agile for said two years, and successfully delivered a multitude of projects using agile.

The driver to me seems to clearly increase complexity for the sake of it in order to push for more billable hours.

This was pure graft.

Honest Q since you're a throwaway but is this how consultants typically act? Justify simple things to be more complex to lay people and charge them out the wazoo?

I think I'm slowly starting to understand why some of my friends are creating their own dev agencies. This racket is rife with stupid money.

[throwaway202212]

That's interesting. I'm curious to know how the internal sponsor of the project sold it internally. It generally takes a lot of motivation to convince your superior (and finance team) to pay the millions McKinsey would charge per week.

At the micro level, I would agree that in some cases there was a tendency of some to make things more complex than necessary. The implicit intent here was generally to demonstrate some type of credential to lay people.

That being said, at least in my personal experience, most of the actual recommendations were backed by as much data as possible. In the projects I worked on, I don't think a single slide went by without hours of debate and critique by the partners. It was a given that any recommendation should be supported by data.

That being said, there are also lots of cases where there is no right/wrong answer - especially given the timeframe (typically 4-8 weeks). Companies basically pay consultants to come in, analyse as much data as feasible and just make some type of informed decision. In most cases the company is either unwilling to make that decision themselves or does not have the ability to do so (i.e. organisation is too complex to tackle this problem within so just get an outsider to cut across the company and get it sorted as best as possible).

[DrScientist]

> It generally takes a lot of motivation to convince your superior (and finance team) to pay the millions McKinsey would charge per week.

And an insurmountable barrier to then declare it was a waste of money.

ie once these initiatives start - they are inevitably declared successes because too much has been invested ( literally ).

So the consultants always leave with success declared, whether it works out in the long run I suspect the consultants will hardly ever know - just moving on from one declared success to another.

[throwaway202212]

Fully agree with this. That being said, a lot of companies are wising up to this and forcing consultancies to work "fees at risk" - where they are only paid based on some measurable success metric.

There are obviously lots of hacks and shenanigans around defining and negotiating these success metrics with various "levels" [1] of impact being defined and fees being released only when some stage is crossed.

[1] https://www.mckinsey.com/capabilities/rts/our-insights/keepi...

[rightbyte]

You are danger close to seem like you are defending agile. I am all in on blaming kickback consulting. But we can't blame agile's failure on consulting companies.

There was a genuine and optimistic belief in agile among programmers and management. They tried and failed refusing to admit the mistake and doubling down on all the BS.

It works perfectly fine to hire consults to do welding courses for the employees. If agile was a good idea "agile consultants" would do fine to.