What comes first, feature creep or agile?

I would say that agile has helped create the conditions for the proliferation of tech debt mills, because it empowers product people while disempowering engineers.

"Rapid and flexible response to change" is really just bruteforcing ideas leaving a trail of tech debt that makes developers miserable.

This has less to do with agile and more to do with the company culture, processes, and probably the people involved. Agile isn't a cure to these problems, it's a tool used by people who "get it" to communicate effectively and to empower everyone to do their jobs.

Thanks to agile I am directly involved in evolving the product I work on and providing information back to the product owner and anyone else involved. I regularly make suggestions that are listened to and I get feedback on my work several times a week. The changes I make are released to users rapidly and regularly and we gain insight from that to make our next decisions.

I also openly discuss the compromises I make in terms of technical debt and I'm given the freedom to clean it up when it makes sense for the business.

The business would not be able to innovate as quickly if it weren't for agile. I would be less empowered and performing suboptimal work if it weren't for agile.

Tech debt "just get it done" style management with egos too sensitive for candid feedback will always exist and the way the work is defined will have little effect. It's unfortunate that you work for such managers, but please don't blame it on agile.

And the way engineering culture contributes to this toxic ecosystem is by perpetrating the myth of casual professionalism thereby selling ownership by avoiding responsibility and taking perks over substance in the bargain

You sound like me a couple of years ago until I realized I was the problem the whole while

Why was I contributing to this madness when I knew better?

So I took the show directly to the client and never looked back

I'd love to elaborate but it sounds like you have a journey ahead of you before you can appreciate what I have to say

What you describe makes me think that you pivoted from an engineering role into a product role in order to make agile to work for you. This only reaffirms what I said, because if agile really empowered you as an engineer that transition would not have happened.

No. I went directly to the client and sold them on the idea of iterative process from first principles

The difference is that the emphasis is on knowledge creation and relationship building

Believe me that there is a way to do the right thing by everyone but most people set themselves up for failure at the outset

It's both way simpler and much more complex than most people can truly appreciate

By the way the word pivot is largely misunderstood

It means to change the approach while maintaining the vision and values

My values have always been on teamwork and knowledge creation and I pivoted in the sense of changing the approach but not in the sense of changing the vision