'Promoted' to Release Manager - Now What?

Question

Background:

I work for a small, 7-person Analytics/Consulting company. Originally, I was taken on to be a data analyst, but the needs of the company changed, and the principle requested I take up the role of Release Manager and QA tester. Note that my degree is in economics, not software.

My Problem

The biggest difficulty I've had stepping into this role is managing our projects. We currently do not use a bug tracker, we do not use a project management tool, and we are struggling to find an efficient way to produce release notes and communicate todos.

We have over 150 git repositories and at any given time, 50 are being developed on. On average, each project has 3 dependencies, each with a specific development or release version. I find this to be a bit overwhelming, and our current way of communicating is to talk or print notes.

This doesn't seem efficient or scalable. A further problem is that the principle is vehemently against using a bug tracker since we're small. I find that troublesome because it means we have no audit trail, and it makes keeping track of progress difficult for me.

Going Forward

Going forward, there are two big questions I'm trying to grapple with:

1. How should I actually go about 'managing' our projects?

2. What technologies and concepts should I be familiarizing myself with to succeed in this role? Currently, I am somewhat familiar with the following tools:

   • Ant
   • Artifactory
   • Git
   • Grunt
   • Jenkins
   • Maven

Answer 1

To answer your question

Q1: How should I actually go about 'managing' our projects?

IMHO, there are few key concerns for anyone in a Release Management Role. Maybe you already have some of this under control.

1. Are we delivering the right product ( Did we get the requirements correct )

   Is there a method the team uses to effectively capture & log requirements (Need finding sessions, detailed user stories)

   How do you facilitate a change requests (Cause they do come)

   Identify a single point of approval for scope changes & anything related to scope within your organisation for each project

   Transparent communication related to all scope changes

2. Are we delivering the product right ( Low defect density, Without surprises, on time)

Q2: What technologies and concepts should I be familiarising myself with to succeed in this role?

This is where most teams spend most effort. Based on my experience I'm going to share a list of primary concepts you should be familiar with.Looking at your list of tools I assume your product is mainly Java. I will try not to talk about a specific tool.

• Release planning (A list of what will be done for a given period of time, Estimations, The team responsible for delivery)
• Version Control (Your teams seems to use Git & seems to have it in place)
• Code Review ( Static code analysis; review the code using a tool so code reviews are more productive, Coding guidelines, Peer review,Lead Review)
• Quality Assurance (Defect Tracking is only one part of QA, You need to be familiar with writing Test Cases, Unit Testing,Acceptance Testing, Mechanism to open/close QA Tickets with details on how to reproduce them a.k.a bug tracking,Test Automation, Test Coverage,Dedicated QA Environments)
• Retrospectives & Reviews ( So the team can learn & improve with each iteration)
• Continuos Integration (Very Important aspect of agile delivery but you need to have the test cases,unit tests,acceptance tests,version control[which you have] in place before you implement CI)

3.Are we within budget ? In my opinion scope creep is the primary factor that makes a project over budget

In addition to above any agile team should have

• A transparent communication model (Daily standup combined with with Emails, Collaboration Tools; what suites your team)
• Frequent reports/status updates on the current direction of project to project stakeholders & team alike

Quick Addition : If the team is reluctant to follow something that is widely accepted as a best practice (Usually they have valid points), you can request them to use it for few sprints and see if it makes sense.If it doesn't by all means try to find out why and improve.The fact that the change is temporary makes it more tolerant for members in disagreement. I was thinking you can use the same to encourage your team members to adopt defect tracking.

And good luck! :)

Answer 2

Forget about PM tools for now. I think you need to triage this situation:

• At least version control seems somewhat in place (puh!)
• Get a SIMPLE bug/feature tracker. I would start with a hosted one. Look for stuff like JIRA, Bugzilla, etc.
• Merge Bug/feature tracker with your version control (start with simple commit comments referencing to the issue number)
• Start getting data on cycle and lead time to improve the situation later on

Answer 3

Managing a Project Requires Goals

How should I actually go about 'managing' our projects?

Project and release management are complicated subjects that fill shelves of books. However, the key concepts essentially boil down to the following:

• Identifying the project's objectives.
• Identifying the process the organization will follow to meet the objectives.
• Identifying the metrics needed to track progress and resource usage on the project.
• Identifying the process controls needed to manage the project's deliverables, schedule, and budget.

Your job isn't to define all these things yourself. Your job is to help the organization (and specifically senior management) to define them, provide senior management with input into their creation of process controls, and then to provide information about the ongoing status of the project to interested stakeholders.

Technical Controls are Secondary Considerations

What technologies and concepts should I be familiarizing myself with to succeed in this role?

This is a no-op. "Technologies" are a way to implement your processes and procedures, and are not the framework itself. You must define a process before you can design effective process controls for it.

Instead, you should familiarize yourself with the business objectives (and unwritten expectations) for the project, and research project management frameworks and controls that would fit well with both the objectives and culture of your organization. The technical and administrative controls will then be designed to fit your process, rather than the other way around.