Agile Sprints Criticisms

Gitlab you are not a startup, don't make me laugh.Here's a good tip for managers of engineers. Don't be GO all the time. Let your team work on non-roadmap items every sprint. Every last Friday or whatever.Don't give your team huge high stakes tasks every time. Give them candy in between to relax a bit and recharge. This job will break your mind if you don't cool off.

AFAIK building software is a collaborative event. What I mean by that is, most of the time, we learn what works better as we get into the process of building it. So, the ideal world you are expecting is not practical. Even if some work can be specified to that level of clarity and details, it is better to build a tool that takes in this structured spec and build the feature.But, I hear your concern about working in a setup which feels ineffective. My suggestion would be to pick teams that are

Try looking into agile methods, might be exactly what you need.

Sounds like the problem is having "sprints". As far as I know, most teams at Google and Meta don't.

Product sprints aren't going to run themselves

How I build software quickly: get rid of team members first, communication slows things down.

1. Daily chats one on one, unscheduled time, with them showing me what they are doing in the editor. This time is used for code review. Sometimes it turns into pair programming for training. Text messages over teams as needed. Open voice channel where I sit on mute a few hours a day they can drop into to ask questions. They can similarly drop in and wait for me to show up if I'm afk or focused on something else.2. Ad hoc chats with manager, he is hands off other than twice weekly meeting

Easy. Have them to daily standups, sprint planning every two weeks and a day of retrospective and soon their producticity will be rockin'.

How much time before you boss says: "OK, during the last 3 months you told me that all these tool would save you in total 1 dev/year... so I will reduce your team by 1 dev but keep the work and deadlines" ? ;-)

For a pretty crazy take on this, take. A look at BaseCamp’s “Shape Up” philosophy, They do not have a backlog. Period. To them, they work a little slower and expect to give enough time to a task to ensure zero bugs instead but then have cycles of bug-fix focus. Additionally, something I found interesting is that every dev is expected to understand the complete stack, that way any dev can fix any corner. Sure this might not work in a larger company without strong levels of splitting up the produc