I think it never had a chance. With the old waterfall model, projcet managers had some power : they could continuosly interrupt engineers and ask them to do more and more since project went in one trajectory for years. They were justified since the engineers had plenty of 'downtime'. Engineers had some power, the project never changed direction and they could work out the design and implement it carefully, managing technical risk.
When Agile came along, the idea was to change direction every two weeks, but within the two weeks the team does not take on any distractions. I suspect this delicate balance of power was created, not out of a sense of fairness, but for efficiency. But when the people in power saw this they said : 'I will take these parts of the methodology that are useful to me and ignore these parts that are not useful'. Cue the 50 point stories, sprint abortions, mid-sprint story additions etc. Question the reasoning and you are labelled anti-agile. I suppose this was the only way it could go.
[1] http://blog.toolshed.com/2015/05/the-failure-of-agile.html
I've seen the opposite more often: Many a waterfall had poor assumptions made up front without a lot of technical risk management afterwards beyond "helicopter parenting" from architects.
Most successful agile teams I run into, engineers hold most if not all of the power to design and implement - the product owner wields ultimate power over function and priority.
"When Agile came along, the idea was to change direction every two weeks, but within the two weeks the team does not take on any distractions. "
That's Scrum's approach. Modern XP Shops I've tended to see adopt iterationless approaches, where there is a retro and planning session every week or so, but not really to recognize "iterations" per se. Features are delivered when they're delivered, deployments and releases are automated so they can happen whenever the product owner wants.
Biggest point of success, however is to eliminate project management as we usually know it. There's a product owner, and a product manager and they are usually an empowered customer paired with someone that knows how to build "products", ie. A focus on learning and testing rather than the certainty demanded of most projects. Project managers become at best glue players that protect the team from organizational antibodies.
At one of the clients I was working at, they bought in Martin Fowler to the site, who was being touted as one of the 'inventors' of agile methodology. Agile was being sold as a silver bullet and thoughtworks the deliverer of the software nirvana. the irony of "Individuals and interactions over processes and tools" was not lost on anyone.
Nope, that's still the status quo. I have workd alongside them on and off for the better part of 10 years now, last time a year ago, and this happens every time on multi-vendor projects. I struggle most with pair programming - it is divisive.
That said, also last year, I worked with a guy from Thoughtworks who had real issues with stand-ups. Too much ceremoney, he said. I hoped at the time it was a bit of reality setting in, but not sure how far-reaching that is.
Definitely not NIH. Many new tools in CI/CD space clearly acknowledge Go as the one of the first tools in the pipelines and CD area. While ConcourseCI looks good, even Jenkins 2.0 cannot compare to the first class pipelines support in Go.
Disclaimer: ex-thoughtworker.
If you think Go was the first tool in the CD area, that probably says more about Thoughtworks defining CD as whatever-we-say-it-is, rather that the capabilities of a specific tool. It's not that people didn't do CD before 2010. It didn't bring anything new at the time. I suspect Go would have fared better if it was a Jenkins visualization plugin, there it could have ridden the coattails of its DSL system. Jenkins is the PHP of CI/CD and you need to go above and beyond it if you want to replace it. I would love, for example, to see Ansible/Red Hat bring their automation experience to this space. Imagine a CD Tower plugin, or a build system where not just the dependecies are declarative. I haven't had the opportunity to use Concourse yet, but I'm sure I will.
Have you tried GoCD? It has first class support for pipelines - not just via plugins, but built into the domain model.
Thoughtworks was one of the implementors and I was with another vendor. Thoughtworks had 'agile coaches' on the team who would dictate process and alienate anyone who wasn't from thoughtworks, only thoughtworks employees had access to their 'mingle' project planner where they would do all the planning. One of the main objectives of these 'agile coaches/architects' was to make sure they lock down this big client for future projects by integrating themselves deeply into clients processes and alienating everyone else. Their commercial products like mingle are explicitly designed with this in mind. Their 'take over' phase also involved binging in lots of young consultants who would work really long hours, most of them on my project were fresh college graduates from their bangalore/pune office bought overseas on L1 visas who work 12-14 hr days.
Anyone who questions them would be labeled not 'agile' enough and by extension a liability to the project. I left the project shortly because it was not my battle to fight. Employees who worked there associated agile with consulting company scam. It was disappointing to see agile methodology being coopted by consulting companies for their own ulterior motives.
Thoughtworks was just another consulting company who uses 'agile' to out maneuver their competitors. I always wondered why thoughtworks is considered to be different from other companies in the class like accenture/ibm. I've never used a product or opensource project made by Thoughtworks.
This was about 7-8 yrs ago so things might be different now, not sure if they still doing their agile stickh.