Role-Based Management

Horizontally, we have role-based management. When individuals focus too much on delivering features within the theme, they may forget the whole picture. Its role-based lead’s responsibility to give them guidance, advice, and directions.

Leads do not actively participate in the daily scrum process. However, they should strive to understand the development contexts of their direct reports. They can accomplish this by attending daily standup or retrospective meeting as stakeholders. Or they can schedule weekly meetings with the team.

The key point is the leads should not lose sight of what’s going on in the theme team.

Every so often, role-based managers may have tasks that require help from individual members across the teams. It could be about global standards, coding styles, cross-theme architecture change etc. In this case, they should not assign tasks directly to developers. Instead, they should talk to product owners and work with them to figure out the priority. Product managers care more about features. Tech leads focus more on tech debt. We can strike the balance enforcing 80 20 rule. 80 percent of the tasks will be features and 20 percent of the tasks would be technical stories. The divide here may not apply to all companies. Actually, it is up to the team to figure out what the priority is. For early-stage startups that are fighting for survival, they may put more weight on feature developments instead of technical debts. For late-stage or established companies that seek scalability and maintainability, they may focus more on technical debt.

Once we grow to multiple scrum teams, how do we ensure what the teams deliver as a whole are what the company needs? How can we be sure that each theme will deliver things that are coherent and consistent? How to manage cross-team dependencies, if there is any? These problems can be solved by encouraging communication and collaborations between the teams.

In GOGOVAN, we depend on role-based leads to mitigate and solve these problems., because they are the ones who hold the most holistic views of the company. They need to meet regularly to avoid miscommunication and silos of themes.

Sometimes due to sudden urgent business requirements or structural changes in the organization(people leaving, taking long leaves or new employees joining), some themes may be understaffed while other themes have resource overflow. It is up to the leads to make the call on how to (re)allocate resources. The leads need to take into account the current situations as well as the opinions of different parties to figure out the final plans.

The structure of the above is missing some critical parts.

1. Architects. Some companies will put architects inside each theme team. There are a few limitations to this. Firstly, it’s costly. Secondly, architects may not have enough work to do if they are dedicated to one single team. So it’s common that some companies will have architects as consultants for the sprint team. In GOGOVAN, we want architects to play more active roles. Architects will participate in sprint grooming sessions, analyzing the stories and coming up with architecture blueprints with developers. During the sprint, the development teams can pull in architects if they have any questions. After the sprint, architects need to evaluate the implementations and see if everything is alright.
2. DevOps. There are different team structure models for DevOps. In the case of the GOGOVAN, we have a DevOps team. Thus we will go for Type 5 DevOps. The purpose of this team is to bridge the gap between devs and ops and creating a good infrastructure supporting the application from development to production.

The following is the team structure.