Team Structure and Development Process in GOGOVAN
How to organize a company so that it can scale out is a challenging problem.
As the competition becomes more intense, business comes up with more and more user stories, application grows both in size and complexity, the tech teams accumulate so much tech debt that it becomes very hard to add even a small feature. Stories are buried deep in backlog. Developers are stressed out. No one is happy. It becomes obvious that something needs to be changed.
The first problem that needs to be solved is the team structure.
When a startup is small, it’s typical/economical/efficient to have one single team working on everything. It works perfectly until it doesn’t.
Spotify comes up with a good approach to solve this problem. However, its structure is a bit overkill for medium-sized or small companies.
Taking into consideration the situation in GOGOVAN, the following structure is implemented.
Theme-Based Development + Role-Based Management
Theme-Based Team
Vertically, we have themes, which we’ve explained the reasonings previously.
We use SCRUM within the theme.
In SCRUM, we have roles of a product owner, a scrum master, and developers. The product manager of the theme-based team will take the role of product owner. Any team members that are experienced enough can be voted to be scrum master. The team will be cross-functional. We will have IOS developers, Android developers, web developers, backend developers, QAs, designers, product managers, data analysts sitting in each team. The team should be small enough that they can be flexible and efficient but big enough that it can develop most, if not all of its own features.
For years, there are a lot of debates on how UX designers, data scientists, and other non-developers can fit into the scrum process. The reason why this is hard is that there is no rule that plays wells in every situation. Every sprint may require different levels of involvements from these parties. Let’s say if the sprint goal is to develop a new UI for the IOS application, the team may require designers to have prepared for the wireframes and mockups before the sprint starts. During the sprint, the designers need to stand by and answer questions raised by developers and product owners. In another sprint of which the goal is to make the data-driven dispatch service more efficient, we may require much help from data scientist, while requiring no service from designers.
The theme-based team will allow this flexibility. People of different roles may opt out of the scrum and serve as stakeholders if the team deemed it appropriate. The following is an example setup. This setup may vary from sprint to sprint. The bottom line is people shouldn’t be forced in or out of the scrum. It should be an informed decision driven by common sense.
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. It’s 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. Scrum of scrum is one approach to solving these problems.
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.
- 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.
- 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.
Summary
While our team structure and process are different from Spotify, We do share their objectives. We want to build up fully autonomous teams that have end-to-end responsibility. We want the teams to be loosely coupled and tightly aligned. We want to reduce hand offs and dependencies.
The above setup is by no means perfect. We will encounter difficulties but we will learn from the lessons and adapt if necessary.
