No agile is just micromanagement. Control every task the developer works on, make them report status on a daily basis.

Ask 10 different developers, Agile salesmen, and product owners and you'll get 10 different explanations of what Agile is.

Occasionally you'll come across somebody with a healthy dose of skepticism.

https://news.ycombinator.com/item?id=5406384

I think a lot of people are conflating Agility with SCRUM. If you look at the official SCRUM guide, you'll find ZERO references to agility. And if you look at the original Agile Manifesto, you'll find ZERO references to stories, sprints, story points, velocity, standups or any other thing that we consider agile.

For me, the essence of agility is: break down large projects into smaller and smaller projects until the "mini-project" becomes simple enough for you to execute. But each such mini-project must delivery something that works. Also, don't show documents about the software, show the software.

That is an excellent comment, thanks for sharing.

I believe the agile manifesto was written by smart people that knew what they're talking about. But what is known today as agile has nothing to do with what they really meant.

The agile manifesto says "working software over comprehensive documentation", but in practice, all agile projects I have seen put more emphasis on project documentation than working software: kanban boards, sprint burndown charts, the backlog, project planning documents... that's documentation.

The manifesto also mentions "individuals and interactions over processes and tools". Standup meetings, sprint planning, sprint retrospectives, etc. are processes. And agile practitioners I have met put more emphasis on those rather than doing something in the spirit of the manifesto, which is using reason and logic to collaboratively find solutions.

That's when done in a factory feature farm where you've already sold your control for the safety of a steady paycheck

Try selling a really agile methodology to a client of your own before you jump on the turnip truck

When done properly it gives the client immediate results with little up front commitment or risk and gives you all the control you could want as long as you don't mind being untethered from the communal trough and putting your reputation on the line at every iteration

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

That’s a really interesting perspective. I’m doing a waterfall on my current project and it just feels more right

Each software development methodology seems to be about mitigating particular risks.

Agile seems to be mitigating the customer not knowing what they want the software to do; tiny little software cycles, little steps, making the customer look at it frequently and saying what they think.

There are software projects with high-quality customers (sadly so rare) for which that risk is much lower, and as such agile is a bad fit. There are certainly software projects where waterfall is a better fit, mitigating against different risks.