What proponents of agile have a tendency to do is take anything effective and call it "agile".
I've literally had people say "you're doing agile even if you don't know it!".
You can't nail them down, it's always "oh that works? yeah, that's agile. Oh, that doesn't work? you're not really doing agile".
---
And now let me say, I don't like scrum because it's a shitty way to write software.
There's really only 2 ideas in agile that are useful.
1. iterative development, and
2. evaluate and change
That's it. The rest don't matter and are often actively harmful.
You don't need scrum masters, PO's, sprints, story points, ad nauseum.
Can they be useful? Maybe, it really depends on the scale and needs of what you're building, but I'm going to argue that outside of business analyst, these roles should be developers that take responsibilities. yeah yeah, inb4 "scrum master should be a developer!". Ask yourself this. What is the difference between a tech lead and a scrum master? answer: scrum master is considered a career, tech lead is considered a skilled developer.
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.
> 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.
I've literally had people say "you're doing agile even if you don't know it!".
You can't nail them down, it's always "oh that works? yeah, that's agile. Oh, that doesn't work? you're not really doing agile".
---
And now let me say, I don't like scrum because it's a shitty way to write software.
There's really only 2 ideas in agile that are useful.
1. iterative development, and
2. evaluate and change
That's it. The rest don't matter and are often actively harmful.
You don't need scrum masters, PO's, sprints, story points, ad nauseum.
Can they be useful? Maybe, it really depends on the scale and needs of what you're building, but I'm going to argue that outside of business analyst, these roles should be developers that take responsibilities. yeah yeah, inb4 "scrum master should be a developer!". Ask yourself this. What is the difference between a tech lead and a scrum master? answer: scrum master is considered a career, tech lead is considered a skilled developer.
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.