And my team thrives because of it
When our organisation decided to embrace Scrum our leaders had the impression that the process to release software changes was too complex to be picked up by the teams. This is why a function was introduced to manage the change deployment.
There were several reasons why the organisation saw the need:
The people needed to deploy the changes were outside of the team.
The people that did the final test were outside the team.
The change management procedures were very complicated and required focus.
My function
Here’s what my function entailed:
Accepting the items from the teams
I needed to understand which roles were required to deploy the code, if there were dependencies and what the priority of the item was.
Plan the items to be released to pre-production
I aligned the dependencies with other items, which required discussions with other coordinators. I also needed to request availability of the people who did the deployment.
Do the administration of the deployments
I registered the items for deployment and tick the right boxes.
Informing the stakeholders
I informed the stakeholders of the planned releases and also afterwards about the actual deployments via e-mail.
Chase CAB approval
I had to ensure that the CAB approvers assessed the item within the SLA.
Plan the items for final testing
I needed to coordinate with the people that did the final testing and needed to ensure that the right people were talking to each other (Scrum Team and tester outside the team).
Plan release to production
This entailed all the activities required to go to pre-production, but then to move the item to production environment.
It was important to have this specific function. Teams could focus on creating “Done” increments and then I came to make sure that the remaining steps took place. However, we also looked at how we could make the function obsolete.
Milestone: deployment and final testing within the team
After a couple of months the Scrum teams became responsible for deployments and final testing. It effectively meant that the teams were extended with the people that do this work. This was all part of a bigger plan from our department to make the Scrum Teams autonomous. Autonomy for us means that you build it, you deploy it and you run it. This requires cross-functionality.
This step allowed me to empower the team to plan and execute everything between themselves. They could take ownership. As a result I now didn’t need to coordinate between different parties involved to progress our increments.
Milestone: coordination with stakeholders simplified
Then there was the jumping through administrative hoops to get changes planned, approved and executed:
Change registration and status updates
CAB approval
Daily meetings to align with other coordinators
Informing the stakeholders about the changes planned and executed
I discussed with the Scrum teams which I serve how we could move the roles that I do within the team. Our objective was again to come to autonomy, allowing the team to do everything necessary to build, deploy and maintain the code. We concluded that the change registration and CAB approval management could immediately be picked up by the team.
When we decided to work this way we noticed that the coordinator function apparently brings a certain status. People see it as a big thing that ‘puny’ Development Team members get the rights to register and update change tickets. Which I found odd. It took some convincing, but I got management to see that bringing these tasks to the team enhances autonomy. so they granted several team members these rights.
That left me with the daily meetings and the information e-mails. People within the Scrum team were hesitant to do the mails because to them it didn’t seem the most practical way to provide this information. They took it upon them, but decided to look for more efficient ways. They found that an intranet page which shows the planned changes for the day, automatically updated, was the best alternative. It was simply a matter of informing stakeholders of the existence of this page.
Now that all the capabilities were in the team to plan and execute changes the daily meeting was deemed not needed by the team. So they decided to inform everyone that we consider the meeting as not required for us anymore.
This was the last step to bring the responsibilities of my function within the team.
The positive results
Now that my function is dissolved you may think: what are you going to do now? Where you fired? Well… no. I was given the opportunity to expand on what I like most: the Scrum Master role.
The team is also very happy. They got rid of a proxy — me — and are far more effective than before. My function was required at the start, but together with my team I made it obsolete.
Lesson: you’re not a function
Many people fear the prospect of making their function redundant. Because what if the organisation thinks you make yourself redundant? Don’t give them a reason to think like that. Project what role you could play that would be a good fit with the organisation (or society) and expand on that while you are making your function obsolete. I allowed me to move from this coordination function to a coaching function.
My twitter profile is https://twitter.com/WJAgeling