Inception of rotating roles

Welcome to Episode 2 of Packit’s journey in managing development and operational duties. In the first article, we introduced the problem space, highlighting the multitude of tasks involved in overseeing an open-source service. These tasks include managing code, monitoring production deployment, reviewing pull requests, and making releases. Each of these activities can be complex and challenging to handle effectively.

Let’s dive deep into the solution our team pursued.

When we started this process we were using both Jira and GitHub to track work. Scrum was our methodology of choice (we didn’t know other) and it was done all in Jira. There was a service that would mirror GitHub issues into our Jira board that streamlined the process. Our users would usually open GitHub issues and that’s where we interacted with them. Jira board was handled only by team members.

Roles and their rotation

We knew we had work that needed to be done every sprint. But how to incorporate that work into our scrum process? We compiled a list of these recurring tasks. Subsequently, we organized them into thematic roles. It’s impossible to do this right from the start. We iteratively refined these roles, taking into account feedback from team members, until we reached a consensus that left everyone satisfied.

So here is the initial list of roles with a short description for each:

1. Sentry master — role including checking alerts in Sentry, the monitoring application we use; making sure new bugs are correctly triaged and potentially fixing the easy ones.
2. CI master — person with this role would make sure our CI is green across our projects — no false positives and if needed, contact the support team to resolve any issues.
3. Prod images & packit.dev blog #1 — as we updated our service every week with new code, this role was in charge of building production images. This person was also responsible for writing our weekly blog post about the updates.
4. Release Packit — releasing one of our projects that meant doing the release on GitHub, PyPI and Fedora.
5. Scrum master — pretty self-explanatory, this role included all the responsibilities of the scrum master, e.g. leading the meetings and paying attention to the Jira board.
6. Prod images & packit.dev blog #2 — same as point 3. Since we used to have sprints that took 2 weeks and we did the production service updates weekly, we needed 2 of those.
7. Release Ogr — same as point 5, for another one of our packages.
8. Community master — person with this role would be mainly responsible for responding in chat and making sure new issues were triaged.

This was merely a brief overview of each role. However, the important part was to precisely define each role, and provide links to documentation so even a newcomer on the team could perform it. To illustrate, let’s consider the Community Master role as an example:

Description of the Community Master role

In terms of project planning, we created a single ‘big’ issue titled Maintain Packit project within Jira. It contained subtasks for every single role. Every sprint we would clone the big one and rotate roles. Cycling through roles allowed each team member the opportunity to take on the responsibilities of being a Scrum Master, Community Master, Release Person, and so forth. This rotation allowed us to promote cross-functional skill development and team collaboration.

And since we are obsessed with automation, we scripted the process of rotation. As we were using an internal Jira instance, we’ve never made that script open, here’s how it worked:

1. Either find the last ‘big’ Jira issue or take it as an input
2. Clone it
3. Put it in the next sprint
4. Rotate assignments
5. Print link to the new Jira issue

Every sprint, the future scrum master would run the script manually. Then, during the planning meeting, we went through the assignments, made sure everyone was available during the sprint for their role and potentially did swaps if needed. So what changes did we encounter and how did this affect the team dynamics?

Benefits and effects

Initially, there was some apprehension, especially among the more reserved team members, about stepping into roles that required increased visibility and interaction. However, as the weeks progressed, a remarkable transformation started happening. For example, when it came to the scrum master role, everyone started bringing their unique perspective to the table. What used to be a regular routine, with the same scrum master every time, changed into more engaging discussions that injected an element of fun and novelty into our frequent stand-up meetings. Similarly, when the responsibility for answering user questions and tickets was shared among the team, it revealed our diversity in approaching communication. Everyone had a chance to interact directly with our users, and it was fascinating to see how each team member approached this interaction differently, enriching our user engagement efforts. Additionally, this rotation also enabled team members to gain knowledge and experience in various areas, such as the release process and deployment procedures. To sum it up, this experimentation with shared roles not only ensured a fair distribution of responsibilities but also promoted a more dynamic, knowledgeable, and engaging team dynamic.

Besides that, introducing shared roles within our team has led to other key benefits:

1. Enhanced transparency: The introduction of shared roles has brought transparency to our task assignments, eliminating the ad-hoc nature of our previous approach and making task responsibilities clear and visible to the entire team.
2. Reduced SPOF (Single point of failure): Previously, some tasks heavily depended on specific individuals, creating single points of failure. Shared roles have mitigated this risk by ensuring that each member was able to handle each of the tasks (with a little bit of help from other team members in the beginning).
3. Improved documentation and visibility: Creating the subtasks forced us to make clearer task guidelines and processes, enhancing documentation and making critical information more accessible. This has helped onboarding and knowledge sharing within the team.

Overall, this process worked well for us for quite some time. It was a bit inconvenient to always run the script but we lived with that. Stay tuned for part 3, where we’ll reveal how we improved everything and made it public on GitHub. This will include sharing direct links to our GitHub issues, giving you the opportunity to see the present form for yourself. We hope it inspires and guides others in their collaborative journey.

About authors

This post was written in collaboration with Tomas Tomecek. Tomas and I both work in the same team at Red Hat and share passion about open-source.