Work Life: One Man Scrum (SDLC)? Maybe temporarily

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.

Interview: Job Entails More than One Role

Release management is quite time consuming, similar to project management. So I find it odd when companies feel that they need to create a role that is really two or three roles. I can understand if they were much smaller in size, but they shouldn't be expecting people to have all the experiences they are looking for. Sure, I can fake it to land the job but I am still a loser that the company cares that I be more honest but will choose the guy who was most likely faking it.

I actually had an interview with a company that was hiring a release manager but expected that person to also code, deploy, and handle change management. I made the mistake of saying that is a lot of work for a single person (I also confirmed that this is a single person role, and not a team of people sharing all the responsibilities). Oh, and I also forgot to mention that the role is also a management position that will have future direct reports in a year or two (which really means 2+ years), so they are also looking for someone with direct report experience.

In the corporate world (I worked for two fortune 10 companies), each with the responsibilities they listed are handled by multiple individuals at full-time capacity. There are people who does change management full-time and coding full-time and plenty of managers who do not do any of that level of work. Deploying is something some developers have to do if there are not enough resources, and none of them enjoy doing that. Plus, a lot of release management is also during off-business hours.

So, I was honest and explained that it was a lot of work for a single person, and that it would be difficult to find someone that really wants to do all that much less someone who has the experience of each one. Of all the release managers I have met, I think only one colleague and myself had development backgrounds. I have had no RM managers with development background, nor worked with one. We also had to work with a team of change management people.

I think I wasn't selected because I had no direct report experience even though I gave them some of my leadership roles. The reason is that seemed to be the low-energy part of the interview. The interview was at least able to fake excitement over my other skill sets.

The other day, I saw the role was re-posted again on the job boards so I guess they haven't found a person yet. A year and a half later, the position is still available.

I am a Release (noun) Manager, not Release (verb) Manager

I've been getting several calls from cold-calling recruiters for positions seeking a release manager. After a couple questions, I end up correcting most callers that they are looking for a release engineer. I rather call them deployment managers because most of them understand that rather than release engineer.

This site provides a good explanation of the difference between the two.

I am a release manager (release as a noun), not a release manager (release as a verb). In my line of work/responsibility, I do not actually release any code or compile any code or touch any code (except maybe to forward the package to the operations team which I really should not be doing).

Another way to look at it is that I am like a project manager who are managers on the project level while I am a manager on the release level. If a problem is on the project level (something wrong with project requirements) then it is managed via the project manager. If that same problem cannot be remedied within the release schedule, then it becomes a release level problem thus requiring a release manager to review the impacts.

A release (in my world) is a set of projects to be deployed within the same window. The projects may have weak or strong correlations with other projects within the same release. Not all companies require a release manager as most companies deal with only single project releases. There may be several projects but none are dependent on the other so can always be deployed independently, or small enough to be easily managed by the development teams or existing project managers.

Our releases typically have 2-4 large projects, several small projects, and other production issue patches. For us, releases require quite a bit of coordination due to limited resources including both human resource and hardware resources. Our environments are hardware dependent costing tens to hundreds of millions of dollars so we cannot just simply "spin" up another test environment.

The release manager does not (in my opinion) have the authority to make a final decision on how the new issue should be resolved. The release manager has to be capable of providing the different options and the recommended course. The product, customer, or client should make the ultimate decision.

Typical choices could be:

1. delaying all phases to accommodate the new timeline
2. removing the project from the release (there still exists risk that this still delay the deployment if there are issues removing the project)
3. do not fix and deploy with a known defect (adds risk to customer satisfaction and/or data integrety)
4. shorten the timeline of a future phase if possible (typically requiring a group to work overtime)
5. use the buffer time if one was implemented (typically adds risk to a shortened quiet period)

These terms are not set in stone as the position (to me) seems relatively new (within the last decade) as can be seen by all the recruiters that does not know the differences either. The terms have been around long enough for some stability in their usages. Truthfully, I did not know about this type of position until I was hired here, and didn't know about release engineers until the recruiters started giving me job descriptions that did not match my roles.

Reference

http://www.plutora.com/insights/2014/release-management-vs-release-engineering/