My new boss wants me to also use scrum to track the side projects that I have been working on. I am the only person in my "team" (which begs the question if a team can be one person). So I will be the developer, product owner, and scrum master.
My initial thought is that this is just a waste of energy and time. All the ceremonies are quite useless in a single person team (SPT) except maybe the retrospective. But this all basically falls under personal software process.
If I were to be forever on my own, I would suggest Kanban.
But I do not wish to be the only person to support an ever growing teams that I support. I basically have these side projects just to keep up with the work load. Managers keep promising new member(s), but it has been over a year.
So I got to thinking that a One Man Scrum (OMS) is feasible. I also think the important part is that it is an individual that is strict with themselves in maintaining best practices. This is not a thing that any manager should just ask an individual if they can manage it (why a manager would ever trust in individual like that is beyond me but that is besides the point). My people I know would not have the discipline to do it.
In some ways, the individual needs to be able to act like split personalities. Act as SM when it doing SM tasks, developer when doing development tasks, and setting objectives when doing PO tasks. Most people I explain to can barely understand most of the roles much less all of them.
Although not related to OMS, I have to continually explain to them why I can or why I cannot because of other roles. For example, I have to continuously push back that testing is required. People are always pushing changes to production as quickly as possible and always seem to want to skip QA testing. At most the developer who created the change says they tested the code. I even give them the option to "skip" testing by having QA sign off on not testing. QA almost always say they will not sign off. They also complain that they are pressured to move things out faster too. I tell them that they should get sign off from managers to skip testing if they need to expedite the process. And when this occurs, manager also almost never signs off. Then suddenly everyone agrees on a real time-line. I have to explain this every time, many times to the exact same group of people.
Back to OMS, the important thing is that the "process" is maintained. Yes, the process can change but it should change like a normal scrum team. The goal is that when there are new members, the process does not need to be defined at the point of time. It would move forward like any new member of a scrum team.
Perhaps a better way to explain would be to imagine an ideal scrum team and keep eliminating a person until there is a person left with potential replacements in the future. I have not thought this one completely through.
