Reiterating what gp said , not all dev is like that, lesser you are doing IT and more comp science or any unfamiliar territory really it is harder to break down ahead of time .

Many times I can’t tell you what tasks need to done let alone how much time is needed and break it into smaller chunks during planning phase.

If planning has to work you should be familiar with what you are building , with poor information on the bug/ code / stack planning agile is just useless overhead . it works great for yet another CRUD app where you know the requirements to the dot and know exactly how to build or fix not always , most management fail to differentiate

All the reasons in the TFA are also why it is hard to estimate , what and how much time will take .

When you’re doing exploratory work, the discipline of stopping, examining what you have learned already, deciding whether the goal still makes sense, and correcting course and reprioritizing seems even more important to me. You don’t know what you will be doing more than a few days ahead? Then your sprint length should be a few days and at the end you recombine and replan.

I mean obviously this only makes sense as a way of organizing a team who are trying to build something exploratory - that’s what scrum is meant for. If you are trying to pursue a solo research project within a team the rest of whom are doing scrum then... that’s not a problem agile can solve.

It is not just only research that is exploratory, even the kind of bug fixes the article talks about can be hard to predict. replication of an issue or understand a new module can be uncertain, race conditions or data specific issues are uncertain too.

Identifying and solving something similar to [1] with a team is not simply possible when you plan with agile. I am likely going to go the next item once I mitigate the effect without bothering to dig deeper just because someone is clocking me on a timeline I committed.

It kills all the joy and fun, work becomes boring, this is by design, it is hard to run an organization unpredictably. If only management trusted you to deliver without looking over shoulder constantly ( when the situation warrants it)..

It is not only a engineer's gripe, it applies to management too, the board/ market forces them to be very short sighted, unless you are musk/jobs/buffet it is hard not to buckle to market pressure and invest in longer term opportunities.

The point is not that planning is bad, it can do a world of good in many including unpredictable situations, it is more that blinding pushing a framework especially agile because it worked somewhere and everyone says so, or the manager can't be bothered or won't risk doing something different as the situation warrants.

[1] https://cloud.google.com/blog/products/management-tools/sre-...

Ah - you’ve been subjected to management-by-scrum. I am sorry.

Scrum is a collaboration hack for creative problem solving teams, not a managerial accountability tool. The version of scrum where stand ups are for checking on the team’s progress and velocity is reported on up the org is using the tools of scrum to solve a very different problem than the one that it was designed for.

I’m sorry you don’t believe it’s possible but I can tell you from experience that it is possible to use the processes of scrum and the principles of agile to help a team collaborate on open ended creative problem solving tasks.

Maybe it's finally time to give up on Scrum. Whatever good intentions the original inventors had, whatever idealized situations it may work with perfect unicorn teams, the general experience in the wild of this benighted framework is a tool in the hands of mediocre, inexperienced managers to micromanage, infantilize and monitor developers. It's essentially warmed up command-and-control Taylorism with some feelgood buzzwords and neologisms thrown in. I would even prefer the old horrible Waterfall approach, at least we didn't have all the endless, pointless groomings, standups and retros to attend along with the "we so agile" gaslighting.

And if you are that familiar, why are you building instead of buying?