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.
Ofcourse you're justified in thinking that. The very fact that you're talking about "enforcing Scrum" is a blaring alarm siren.
Scrum is first and foremost about self-organisation of the team; they get to choose how to do their work and how to organize themselves. Management only has a say in what work needs to be done.
The reason why teams should organize themselves is that they are always unique, due to the different natures of the individual team members (and the people they work with) and the due to the differences of the products they work on. A practice that works perfectly well for one team, can have adverse effects on another team. That's why within a certain scope (a sandbox metaphore is often used), they have to experiment, learn and find out what works best for them.
What you need is a very competent Scrum master (one per team), who can guide a team in this discovery, but at the same time can also work with management to obtain the freedom for the team to go on that discovery.
Best Answer
Remove the parenthetical comment. What remains is "Simplicity is essential", which by the way is an application of the principle to its expression itself.
Simplicity is essential, because you have distilled what you really need, removing what is making the task at hand heavier, less elegant: complex.
I have always interpreted in the sense of Pascal's take on brevity: "I would have written a shorter letter, but I did not have the time." You have to avoid what is unneded (from the letter, from the code) and this is an active task, and not an easy one. It is not something which happens by itself.