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.