Everyone claims they are following “agile methods” but few do (2018)

I am often only resourced 10% to some Agile projects, because my expertise is often only required for a small part of the project. And yes a copy writer can do my job as well, but would you really let an average electrician build the timber structure of your roof while the plumber wires your house ?

The concept of agility, with the word taken as in its common word meaning, does not actually need all that bullshit. Well, neither does the general concept of being agile in the first place, but it is harder to distinguish from the now tainted one "Agile".

The first is a fortune 500 company that is not a techy company. They have a lot crusty old infrastructure and when they decided to do agile, they hired a consultant company that came in and spent a lot of time training everyone in their "agile" methodology. I can say without sarcasm that it worked great. It was painful at first and it took probably a year for everyone to adapt, but I was very pleased with the end result. Agile didn't mean, don't do design. For us, Agile meant to always be designing. We set aside 2 hours every week to sit down as a team and design future features, as well as evaluate current architecture and propose changes. Outside those 2 hours, devs would do additional design as needed. We had one hour every week for a long form meeting for our BA's, product experts and development team to all get on the same page for business requirements and future product direction. In addition, the product team was available for consultation almost every day, and never fewer than 3 times a week. Our retrospectives were rigorous, and by the time I left the company, our estimates were excellent. We had gone from almost never being able to finish our sprint correctly to it being a surprise if every story wasn't finished on time. Occasionally business would throw a curveball at us and we would have to scramble to get our backlog and designs into place, but we were still able to finish almost every sprint as promised.

I'm a little over a year into the new place. It's also a Fortune 500 company, but it is know as techy and has a good reputation with the field at large. So far it has been miserable. They're one of those companies that does waterfall with standup. As a result, we have extended periods of torturous drawn out design (one guy went six months without writing a line of code for work), followed by a mad scramble to implement our designs as we realize we're running out of time. As a result, the documentation looks nice, but the code is a mess and doesn't always match the documentation. Since the team can't self organize, tech debt continues to accrue at a terrific rate. Small stories are awkward because the pipeline and commit process is too difficult and slow to justify it. Part of the problem is the lack of business analysts. Without that intermediate group to help manage business complexity, the developers are left doing an extensive amount of basic requirements gathering just to get started on a problem. In addition, there's no real institutional memory, and when business flows change, there's no one around to update old docs with the new changes. There's no real story grooming, so we routinely overshoot our sprints. Without a clear understanding of how product and development are supposed to interact, priorities are changing constantly and I've been shuffled between two projects almost at random.

I could go for hours about the two different companies but I think the difference boil down to one simple factor. The first company had a culture of continuous improvement. They had their share of failings, mostly related to not being a very techy company, but everyone in that company was deeply committed to constantly making things better. Pain points were either quarantined so as not to impede work, or they were called out and fixed. If something couldn't be fixed or quarantined, than it was tracked until everyone was so sick of talking about it, we'd find the time to fix it. The second company does not have such a culture. Everyone is very comfortable with the status quo no matter how much it slows things down. Things are starting to get a little better, but not much.

I think Agile worked well with the first company because everyone was already interested in constantly improving. Agile gave them a framework to evaluate their performance and improve it. Without that culture of constant improvement the second company just adopted the most cosmetic practices of Agile, without actually changing anything, or evaluating their own behavior.

How exactly are you supposed to make three whole statements per person and also leave room for helpful reactions and questions... in an average of 14 seconds per person-statement and response?

That might be how long it takes if nobody has anything to say in response, but it won't be the average, more like the floor.

Either we're not talking about the same thing, or your dev team are moonlighting as auctioneers.