Agile sucks for software development and I’m tired of pretending it doesn’t

It's meant to build cross functional teams of people who can produce predictable amounts of output such that people in Product Management can build roadmaps and concoct release schedules.

Not to mention, once a company has successfully implemented Agile (and its inherent trade-off of dev speed vs. predictable minimums) that company may now replace any person on any team with any other person. Nobody wants to say it but Agile is about hiring low rate contractors instead of expensive FTE resources.

An often overlooked part of Agile is that if you're an experienced dev who's also lazy is that this method provides a lot of cover to hide in. It's about predictable minimums. A clever dev with some talent can work about 4h/day and still outwork some of the less clever cohorts who may work many more hours.

Also, you seem very angry and thats a sign you probably care a great deal about what you're doing at work. Maybe its worth looking for something else to do where things operate more to your liking? Stress really is a killer and few things are as stressful as hating the way your job works every day of your life. Reading your story I think I'd be angry too in your position.

Finally, repeat after me here - "Agile is for MANAGEMENT - Agile is NOT for developers". The Happy Agile Developer is one who's figured out how the game works and uses that understanding to work less.

1) keep your stands below 15 minutes. Always. There should also never be more than 15 participants in your stand.

2) The EM/PM/SM or all of the above should be writing high quality tickets that are discrete units of work (they can be tested and have some tangible output). They should never be so large as to take a single developer the entire length of the sprint.

3) Do a single weekly grooming/pointing session. This should take less than 2 hours assuming management did their jobs

4) EM/PM/PM/SM need to actually keep the backlog organized. Don’t make devs sit thru meetings where you slowly drive Jira

5) Do demos, retro and planning in a 3 hour time block with breaks. Balance what went well with what speed bumps you encountered and call out exceptional work done by team members

6) Make judicious use of doing “proof of concepts” to help spec out features/APIs/Integrations before running off to plan larger initiatives

7) Appoint an “Epic Captain” to each epic (group of related tickets). This is dev who is the subject matter expert and has some decision making authority. Defaults to the EM but they should appoint other devs to take proactive ownership over things

8) Proactively track and discuss technical debt and raise it during retrospectives; EM follows through by ticketing it up.

9) Actually do planning when launching major initiatives. A few discussions between devs before leaping into several weeks long project won’t make you waterfall and will actually reduce meetings in the future

For us, the average time per week an engineer spends in meetings is less than 5 hours total, or <1 hour per day on a team of 8. Kinda high but things run smoothly and nobody is out of the loop

> How does that get to 4 hours a day