One of the reasons Agile (with a big A) is so successful is that its peddlers have convinced everyone that there are only two options: Agile and waterfall. When you're up against a strawman, it's easy to win. But it's absolutely a false dichotomy.

There's a quote in the article that I like:

> Find me an actual tech company that talks much about Agile, and I will be astounded.

In my experience, people at tech companies (at least the FAANGs) rarely talk about Agile, although they do talk about things like continuous integration/testing/deployment. They do not obsess over methodologies for how to move post-it notes around a whiteboard (Scrum vs Kanban) or agonize over how to word a user story narrative, or other parts of Agile Theatre.

People at some non-tech companies, especially those supposedly going through a "digital transformation", seem to have fully bought in to the crap that Certified Agile consultants are selling though.

So a superior alternative to both Agile and waterfall is what's in use at a lot of the big tech companies. For example, the engineering culture at Google, which relies on design docs and a very good set of developer tools and infrastructure. It's not perfect, but it's far, far superior to Agile.

And before anyone makes the argument that those non-tech companies are not doing "real Agile", but Google is, let's be linguistic descriptivists and accept that Googlers don't call their methodology "Agile", whereas the Scrum consultants at big corporates do.

That said , plenty of tech companies have inconsistent practices that don’t necessarily lead to great success. To say Google’s methods are “far far superior” to Agile assumes they’re uniform, portable or relevant externally, or that they lead to above average success. That’s debatable given Google’s reputation for abandoned half-built products and an almost comical lack of customer focus.

It was utterly frustrating to be powerless to improve specification quality and find out you built exactly what was asked but you were asked for the wrong thing.

The silos were horrible. Devs were often as bad as BAs, dev’s just were just crapping on the testers instead. Spare a thought for the production ops person at the very end of the chain. Here comes 3 months of developer work in one weekend and no it doesnt work but we’re still going live because the entire tech org is invested in this release. Now you have smaller squads, you can postpone a release without it looking bad on the top person and thus affecting your career prospects.

In agile models you have the power to fix crap processes that don’t work. You can call out any BS on the retrospective and make it super visible when things are being swept under the rug.

I worked on the customer delivery side of a $750M software project that was a steaming pile of shit, with critical defects that were known for a year with zero effort to address. The integrators were paid to deliver a spec, and it took about a year to get change orders created to diverge from the spec.

The old school waterfall outsourcing models are truly awful, but you don’t really understand how bad unless you’ve lived it. Stupid agile religious practices are dumb for any startup type org, but are probably better than the alternatives in many big enterprise scenarios, where the goal is chunk up the work so marginally qualified people can do something.

The goal of Agile is to let smart people work incrementally towards a somewhat nebulous goal. The ceremony that's arisen around that tends to be put in place by people who feel the need to manage, but don't know how to help their developers achieve that goal.

The alternative, as far as I've seen, is to hire smart, curious people, let them work closely with the end user, and pay them a lot of money. In this situation, the engineers will typically self-organize effectively.

Now it’s 100 people across two countries, expected to collaborate closely with sibling orgs. Management philosophy has shifted to “we will ask a few handpicked experts to write down the best way to do a thing, and then everyone else is a machine for executing that procedure.”

If software engineering worked like that, we would have automated it.

Assembling a talented team that ultimately delivers nothing of value is practically a cliche in this industry.

Give individuals ownership over different parts and then let them self organize, that is all you need if you hire competent people. I'll never work at a place which doesn't work like that again.

QE is a direct transfer of wealth from dollar holders to investors and banks. No way around that.

Gambling with unlimited amounts of other people's money is going to be profitable.

https://www.rollingstone.com/politics/politics-features/2008...

You don't need to buy entirely into a single methodology. When people say Agile in software today, they really mean the Jira-flavored Scrum. Some now claim that they've abandoned Scrum and you hear more about Kanban. Sometimes they really are switching, other time they're really just doing Scrum with a Kanban board. But again, they're often falling into the same traps of forcing solutions, rituals, and processes they might not really need into their flow.

You want to be Agile? Start small. A simple checklist is a good way to start.

I think part of the issue is that Agile is meant to be a Process imposed from top down to improve productivity by X%, a way for management and a small army of backlog/task managers to say they are doing Something and having impact (or literally the only thing they actively do). Not only can it easily get in the way of that, it almost always fosters an environment of shaming and lack of trust, because it is too tempting for estimates to be taken too seriously or productivity/performance measured "objectively" by invoking the task-tracking system (in which case you incentivize only taking on very easy, very well understood tasks). It doesn't always devolve to that, but I think at many places if anybody Important up in the management chain starts thinking that way, it will inevitably trickle down. Thus any sufficiently large organization will corrupt Agile.

Perhaps some companies need that level of accountability and visibility, even knowing and disliking the drawbacks, but not all of them. I am honestly not convinced that a rigid process is necessary at all. Yes it makes sense to have a system where you keep track of things that need to be done, but if there's a culture of trust, I don't think the system needs to be gamified or fetishized as much as it usually is.

> Now, continuous delivery is what’s expected, and the industry is ready for the next thing. But that next thing shouldn’t be another methodology, according to Mary.

> There is no methodology in my field of software engineering that can conceivably last more than five to eight years,” she said. “Everything that is 10 years old is obsolete. Everything that is 20 years old is archaic.”

> Furthermore, she said, methodology requires codification. Beginning with the Capability Maturity Model (CMM) in the ‘90s, software development methodology meant developers had to show they had standards and that they followed them, rather than demonstrating that their standards were constantly in flux depending on consumer needs. That’s the definition of quality standards lean manufacturing practitioners in Japan originally espoused, Mary said, and they’re not compatible with methodology. Instead, they’re all about learning.

> To that end, Mary is excited about all the ways artificial intelligence will allow software engineers to learn better and faster. Automated testing, continuous deployment and cross-functional collaboration are now table stakes, Mary and Tom agreed. Cutting edge companies will discover the next great approach through an engineering mindset and a willingness to learn.

___

Consider that Mary and Tom Poppendieck were responsible for many of the Lean inclusions of the agile movement, which (largely) came from watching plant manufacturing at Toyota. Similarly, much of the DevOps movement was tied to this as well. If you want to talk about what is next, it is likely taking a first principles look at what we're doing today, questioning best practices again, and saying, "if we were going to make a manifesto in 2020, what would it look like?"

The only "strawman" here seems to be taking my point about pre-Agile methodologies out of context, and using it to dismiss the entire idea that this article is unconstructive/has no actionable solutions.

> “I don't care if it’s Lean or Agile, there’s no silver bullet where if you just follow this formula that somebody else followed, you’re going to be great,” she said. “So today, my favorite word is ‘engineering.’ Just let engineers be engineers.”

Maybe we need to call it the Lego process. SCRUM is Duplo. Waterfall is worse Duplo. Start there if you need, but get to Lego instead. Maybe Duplo is enough for you.

The criticism in this comment thread was that their advice wasn't actionable, not that actionability was a prerequisite in order to criticize Agile at all. There was no false dilemma here because there was no choices provided (false or otherwise), merely a weakness in an argument raised.

Which is not entirely true since some of the best parts of Agile are XP practices that almost everybody does by default now...

Someone once said that the only successful Scrum projects are also doing half of XP (as in, things Scrum doesn't prescribe but are essential anyway). I am still looking for a counterexample.

I suspect that most knowledgeable developers rolled their eyes when Agile was "invented". It's a mish mash of a lot of things that were already obvious at the time and some weird kool-aid like pair programming. And just one more in a long line of consultant enrichment schemes.

The big drawback to good managers is that they stand up for their teams and don't kiss boot the way bad ones might.

"Individuals and interactions over processes and tools"

Agile would work much better if every implementation stated upfront, "Does not work right out of the box".