I don’t believe in sprints

> Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.

One of the things that usually happen when they push and push and push for some feature to get rolled out in the next quarter is that it often turns out to be a gigantic flop. Engineers are forced to spend hours they can't get back at the whim of management for something that was a complete and utter failure. I could imagine few things more demoralizing than this.

Agile is really meant to be about self organizing teams that take ownership of their own work and deliveries. The scrum master and product owner are just there to facilitate that.

When a team hits a blocker on a tight schedule -- particularly across third party teams, it's up to the management to figure out a solution -- even if it means gasp delaying the release by one sprint.

Agile means everything is up for being changed as makes the most sense, so in the (rare) event that you really have a task with 0 sensible deliverables you would indeed likely do longer sprints or no sprints. If that's not mutable because of some management mandate your not really doing Scrum, your doing "process inspired by Scrum" and saying you are doing Scrum.

That said your description of "read and synthesize a 10k+ smorgasbord" is nowhere near descriptive enough to answer your question or have any kind of estimate on how easy/hard this work is. It could be anything from I'll have it done in a couple hours this afternoon to a year long effort by multiple devs.

The best I can say is in the real world it's pretty rare to have a huge task that doesn't have sensible subtasks. In the case of ingesting a large mess of data like you are describing this could mean identifying and ingesting the data from system X, or processing event Y. These are steps the developers is going to go through anyway, and in many cases are even going to be deployable and useful on their own! Even if they aren't individually deployable they represent useful landmarks allowing for the understanding how work is progressing, readjusting estimates as necessary, and determining if the entire design needs to be reconsidered due to violated assumptions.

OP doesn't care about building software (innovative or otherwise). He cares about getting his quarterly bonus, which is based off of meeting deadlines, because that's what can be easily measured. Delivering a quality product is much harder to measure.

Yup the other stupid thing that kept happening was sizing the work to fit the model. Medium sized tickets were least controversial in 3 hour backlog refinement meetings. Therefore every ticket began to ranked at that level. Which then beget us chopping up anything larger into these medium sized tickets, and avoiding creating any too-small tickets.

So instead of "ticket: make pasta for dinner" it was like "ticket 1: purchase prego & pasta from instacart" , "ticket 2: boil water & get out the jar opener", "ticket 3: cook the pasta and sauce", "ticket 4: place the meal and serve".

Zero chance all 4 finished in the sprint, in fact they were rarely even all planned for same sprint.

It became impossible to express to users what they were getting at the end of each sprint. "OK, so you've.. purchased ingredients, when do I get to eat?"

This happened with multiple product managers, agile coaches and tech leads so it wasn't just a single person forcing stupidity on the process..

> That's it. The rest don't matter and are often actively harmful.

Oh, ok. It's a terminology thing. We're actually in agreement. It was very hard to see that from the article because it's only negative.

> The problem is creating these roles puts barriers between people. It prevents developers from developing an understanding of what they're actually doing. None of these roles are useful outside of QA and business analyst, and even the BA role can be done by developers if they have communication skills. All a BA is going to do is ask questions of the business.

Small-a agile prescribes no roles at all, so I can't say whether a BA would be useful or not. Scrum (which is the Big-A Agile I have most experience with) also doesn't define a BA role and broadly agrees with you: get the devs doing that work. It also doesn't make any distinction between "designer", "architect", "copywriter" or "engineer". They're all "developers" in Scrum, as far as I understand it from the course I did, and repeatedly re-reading the guide. Neither agile, nor Scrum talk about story points, JIRA, user stories. Scrum recommends you estimate, so that you can fit things into a sprint (so it can be released), and so you can measure your team's own sense of sizing. Those tools (story points, etc) are extras, often prescribed by businesses that aren't as agile as they'd like to to believe... but can still be useful so long as they're used well. Use them as guides, signals for internal team use, not to share outside the team, not to be held accountable. That's what the planning + review are for. Those are your accountability points.

Honestly, I think the bigger problem with trying to use Scrum is continuous integration. If you're releasing often, faster than your sprint cadence, you're bound to come unstuck with your sprints and they'll feel like a hinderance. I'm not saying "avoid CI", I'm saying "if you use CI, and you should, modify your definitions a bit, find a way of working with the accountability system; share that organisational burden with the wider company".

One problem with agile I've seen is that business priorities often change before work can be completed. You _should_ respond to the changing environment (e.g. new compliance, new customers etc), but it can be very very distracting when you have longer-form projects to complete.