SDLC stands for "software development life cycle" or sometimes "system development life cycle," and it refers to the process that you follow for developing your product. There's no single SDLC process that everyone follows -- you're free to define your own, and to change it as the project (or your organization) grows. The point is to have a defined process, preferably one that's written down, that you follow for the work related to development and maintenance of your project. The alternative is to work by the seat of your pants, making things up as you go along.
So, if you want to use Scrum or some other "agile" methodology in your process, that's perfectly fine. Just write it into your SDLC and you're good to go.
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.
Best Answer
The answer to this can be found in the Scrum Guide.
There are three roles in Scrum: Product Owner, Development Team, and Scrum Master. Although not explicitly stated in the Scrum Guide, it's recommended that the Product Owner and Scrum Master are different people, since some of their responsibilities may be at odds at certain points in time. This alone implies that you need at least 3 people to conduct Scrum.
However, the section on the Development Team adds additional guidance. A Development Team that is smaller than 3 people doesn't take full advantage of the ceremonies and artifacts defined by Scrum. At the same time, a Development Team with more than 9 people requires more coordination than Scrum allows for. Therefore, a Development Team should be between 3 and 9 people.
The smallest feasible Scrum Team is 4 people: a Product Owner and a Development Team of 3 people, where one person from the Development Team is also a Scrum Master. The largest possible Scrum Team is 11 people: a Product Owner, a Scrum Master, and a Development Team of 9 people.
As presented by the creators of Scrum - if you have 3 or fewer people, you should be looking at something other than Scrum to manage your project.