Scrum, Kanban or any other Agile methodology is primarily a methodology focused on software development projects. In other words, it is a project management practice by its very nature.
As much as you desperately want you and your team to be doing project work, you will find that Agile will just simply not work in your organization because of the fact that you really are not doing "project" work or devoting yourselves as a team to a "project commitment".
You may organize a mini project around a complex feature, but in reality you have no connection to business analysts or the end users so how can you verify that you are delivering on User Stories when you have no way of really knowing what it is the user wants?
Your only stakeholder is your boss, and he basically ensures that your team doesn't exist to serve the other stakeholders of the project, you exist as a team to serve him and his needs regardless how this affects the other stakeholders.
On top of all of that, he is giving individual tasks to individuals and probably reprioritizing things immediately as he decides that they should go. You can't function in an Agile project methodology if individual project resources are going to reprioritized at a moments notice, or if the sprint will be put on hold.
It is not supposed to work like that
A sprint is a commitment by the entire team to deliver a subset of user stories by a specified date. Once started, a sprint should be gone through to completion before any reprioritization or changes are to occur. How is a project supposed to be managed when run in such a chaotic ad-hoc environment?
You don't work in an environment that is conducive to Agile project management methodologies. You don't even work in an environment conducive to Waterfall methodologies. You work in a monarchy and you are merely the kings pawns doing his bidding and putting out fires.
This is not the makings of a software development project team.
So in a very obscure way I am answering your question in saying that in your situation that it really doesn't matter if individuals are playing multiple roles. You have much bigger problems on your hands. You are asking how to get water stains out of carpet on a house without a roof.
One of the main principals of Agile Development is customer being part of the team. It takes both parties to adopt Agile, so:
STEP 1
Get the customer on your side before proceeding. Agile is not about your team, it's about collaboration between YOUR TEAM and CUSTOMER.
Secondly, Agile is a methodology, it's not perfect, it's not a panacea, it's merely another way of doing things, that happens to work well for small teams with clients sitting beside them.
STEP 2
Learn the agile methodology and determine if it will REALLY make things faster and apply it to your customer. Large corporate clients are hard to get involved into projects, they tend to drag their feet and require comfort with plain old waterfall.
STEP 3
Probably go back to step 1 because your client is still not clear what is agile and why they need it... speaking from 6 years of experience with huge corporate client.
Some of the problems you are going to face:
- Client has been working with waterfall for years and is not willing to change, because waterfall gives them sense of security when they have timelines in advance(although timelines get blown out of proportions by 300% by the end of the project, but no one seems to see that)
- Client doesn't understand how agile works and agrees to it, then immedialy requires an L1 estimate provided by Monday next week.
Your team has no idea what agile is, and process will be a constant struggle to connect people together while trying to get client on board as well.
I know agile could help us to give a quicker turnaround but I'm trying to picture how we can replace these unwieldy documents today with short user stories that get fleshed out via customer collaborations.
You would spend a LOT of time trying to convert client to use agile and then the quality of user stories would be extremely low.
The right course of action in my opinion:
- You know what Agile is and how it is applied very well.
- You spend time and teach your corporate client overtime while helping them hire a couple BAs who are agile-savy.
- BAs become product owners on the client's side and start EFFICIENTLY working with your team.
- You break your team into smaller groups per area of the client's system and each team has own BA as product owner.
IT is also questionable if you can do agile remotely. I have seen some teams do it, and others have failed miserably.
Conclusion:
Take your time, and make changes slowly. Pick a hybrid process that works for you and YOUR client. Collaborate with client and don't try to stick to a methodology 100%. Where there are people, there are adjustments to be made to yield efficiency. Don't strive to switch to Agile because "all the cool kids do it".
Best Answer
It's a common mistake to think that Scrum is equal to Agile.
Being Agile is following the four principles of the Agile Manifesto. Scrum is a project management process consistent with those principles but it's not, in and of itself, being Agile. XP (TDD, pair programming) is a development process, also consistent with those principles, and consistent with Scrum, but it is not being Agile. Continuous Integration, Continuous Delivery, DevOps, all consistent with the Agile principles.
Follow the principles, first and foremost. All of these buzz-phrases are just methodologies that people have found successfully help them to follow the principles. But the main part of "being Agile" is being able to adjust your processes at will where they don't follow the principles of Agile.