Comment by mattbrewsbytes | Hacker News Reader

Comment by mattbrewsbytes | Hacker News Reader

The process that comes with it is there to organize the work and align it with the organization's goals. It can be agile, kanban, waterfall with big upfront design, it doesn't really matter what methodology is used, its there to organize the work. For large and/or existing systems, without that glue there would be programmers running amok solving problems they like to solve with whatever shiny things they want to use. I'm sure without guardrails there are a lot of engineers that would re-write all the code they didn't like, building their own bike sheds all over the place.

Sounds like maybe startups would be your jam. Not a lot of legacy stuff to work on, lots of bouncing around to different types of tasks, shit breaks a lot, etc.

The other idea is more of devops/systems stuff working with the cloud. Lots of solving problems with code (orchestrating cloud resources w/code) with not a lot of Project Manager overhead in the right environment. Lot of incident response.

That's called code review, you don't need any "agile" for it. Agile is used to micromanage engineers to push out crap features, optimizing for the two week return, with poor results in the longer term. The people running amok are layman "agile coaches", "business analysts" and "product owners". While poor engineers are prevented from doing necessary non-feature work.

You can get benefits from small-a agile in the sense of organizing the work in small chunks that can be put into production when ready using CI/CD. If done right, you end up not doing work on things that aren't needed vs. in a waterfall model with large specification docs you end up with feature bloat in a product. Forced two-week cadence and preventing non-feature work indicates poor management.

I don't like SiverBulletCo coming in with tools and trainings and This Is The Only Way™ bullshit either. Maybe lean development is a better wording than agile? Its more about small work chunks and deploying them when ready vs months long projects with Gantt charts. Kanban seems to be the best way to organize work to me. However, letting a team of people align on what process they want to use with what makes sense plucking concepts from agile is fine.

> Agile is used to micromanage engineers to push out crap features, optimizing for the two week return, with poor results in the longer term

More correctly, organizations micromanage engineers to push out crap features, optimizing for the two week return, with poor results in the longer term, and call it 'agile'. They wouldn't know the nature agile if it fell on their heads.

If I could upvote this a thousand times, then I would. Bad management makes any development methodology suck.

Reply on news.ycombinator.com