Agile/scrum isn't a good model under any circumstance, because, as mentioned many times at this point in many posts:
- It leads to burnout because engineers are incentivized to shorten their estimates as much as possible, so as to not look unproductive, only to eventually run into a roadblock, which is typical in any sort of engineering discipline. And maybe the managers made promises to other people based on these estimates, and that, even if you communicated the estimates weren't very accurate, they still relied on when they discussed things in their meetings, and now there's a whole lot of tension and stress for everyone.
- It pits the team against each other, because Bob wants to shine, which puts pressure on everyone else to shorten their estimates, or a tit for tat where Steve would then try to cast shadow on Bob and ask them why they estimated a ticket that Steve has better domain knowledge on, to be 3 days instead of 1 day, etc. In practice, companies work a lot better when everyone works together, not when colleagues try to pull the rug from under their own teammates. Or the workers secretly collude together to pad their estimates so that they have all this free time, at the expense of the company.
- It leads to managers micromanaging the team, and even if they're aware of the problem and try to avoid it, it'll still inevitably happen because the process and scrum are designed in such a way to lead to that sort of dynamic.
I think the industry can do a whole lot better. I have two alternative models, one that I definitely know works because I worked in that kind of environment, and the other one theoretically should work after tweaking it (I think):
1. The Polite Society Model (aka butts in seats)
- Open office
- Everyone gets assigned a task either by the PM or pulls something out of the backlog of a kanban board
- The manager knows that everyone on the team is working, since the manager can easily see that's the case since it's an open office. So if Bob is slower than Mary but faster than Lucy, and any nuance where any worker might be slower or faster on some task because of their background and individual variation, is just how it is, and is self-evident
- Once someone is done with a task, they report to the PM, and if all is well, they get assigned a new task
- No deadlines and no micromanagement necessary. Things get done when they get done. The PM might ask about a larger project that spans into more weeks or months, but this is polite society and an open office, so it's not going to be about grilling Bob on a task or anything like that, and more about prioritization. Ideally, the manager would have a developer/engineer background, and would split up a larger task into many smaller tasks, and would communicate their own estimate to other managers or investors for how long they think Bob would take to finish it, based on how he's making progress on the smaller tasks and his historical performance, making it so that there's no need to pressure Bob to give an estimate, or to micromanage Bob on progress
2. The Captain's Log (aka blinding for remote teams)
- Each developer adds their own private estimates to tickets in a kanban prioritization board. Estimates are always a range from best-case to worst-case, with a wider range communicating uncertainty. The PM can see these estimates from each dev, and prioritizes the queue periodically, once a week or two, on their own, since they're the ones that are ultimately concerned about what product features the team should work on, not the engineers. Bob might estimate a ticket more or less than Mary does, based on their own perceptions, their own productivity speed, domain knowledge, etc. Blinding also should make it clearer to the PM that there's a wide range of uncertainty in some tickets, if there's a wide range in estimates for it, which would be harder to do under scrum, where time needed would more likely get underestimated. Especially for longer tickets that can't fit in a sprint block. Also nobody knows which tickets they'll end up picking up since everyone just picks up from the top of the backlog and prioritization can theoretically change each week by the PM. Devs also should update their estimates periodically if it changed after they learned more about the problem, keeping a log of the older previous estimates that were made as well to get a better sense of the problem domain
- Each developer periodically privately logs their progress on tickets, blockers, setbacks, etc, like a captain's log, maybe once a week or two, or sooner if issues arise sooner. As soon as there's a blocker, developers need to reach out to whoever they need to for unblocking a ticket. Again, managers and PM can see the captain's log for each dev, and they don't need to "check in", which can feel like micromanagement in a lot of cases, since devs are regularly logging everything. If the log is signaling that a dev is getting bogged down or stuck with something, the manager can reach out and follow up on that, ask more about the situation, etc. Devs can only share a non-timestamped version of their logs to other devs that are working on similar or related tickets, so that the focus is more on challenges that were encountered, rather than the time it took to finish the ticket
- The team can still meet up periodically to informally chat about random stuff, for social cohesion, like a wrap up on friday where everyone asks about what they have planned for the weekend, or monday morning where everyone can ask what people did on the weekend, all non-work related
- Devs don't know other devs estimates, so devs are more focused on working together rather than some sort of pressure where they're pitted against each other when they should be working together. Bob might be the most productive person on the team, but he still needs to get along with everyone else, and Mary might have more domain knowledge and work better for a particular task than Bob, etc.