How We Structure Our Work At Mercari Microservices Platform Team

Taichi Nakashima @deeeet / @tcnksm

Project Management at Platform Team? How we decide, plan, execute, control, ship and close the work of a team. Nothing is different from project managements in general

Why Project Management? “Maximize team outputs” ● = Increase developer(*) productivity ● = Deliver better product to Mercari customers faster (*) Our “direct customer” is internal developer

Important Factor We continuously improve our project management by team ● It’s not something to be forced by someone ● It’s the most important “How” you need: team thinks its outputs

History How we evolve our product management? What kind of problem we faced before?

Team growth 9 Members

Team growth No Project Management Agile 6 Week Release Cycle

No Project Management We only have single quarter milestone ● We just take a task we want from a large list ● We depend on each members task management

No Project Management ● Good? ○ We just do things ● Bad ○ We are not a team. Just individual ○ Individual task progress is invisible… ○ Too many things are listed on milestones and distracted ○ Load of support is increased

Leanings From No Project Management There is a limit to individual can build. Individual can build only small fractions of features or small tools, not large and complex system like platform. To work on ambitious project, we need teamwork

(Lightweight) Agile We have 2 week Sprints, Kanban board, scrum master ● We formalize how to structure our work ● We have Epics and divide it into actionable tasks before sprint ● We estimate & record our tasks and calculate velocity ● We balance reactive and proactive task (50% for each) (*) (*) We learn this from Google SRE practice: “At least 50% of each SRE’s time should be spent on engineering project work that will either reduce future toil or add service features”

No content

No content

No content

(Lightweight) Agile ● Good ○ (Finally) We feel we become a team ○ We can visualize our tasks and its progress ○ We can balance proactive vs. reactive ● Bad ○ We focus on velocity, not “shipping” ○ Sprint (=2week) is not suited for platform projects ○ No one can estimate task (and estimation become cost)

https://m.signalvnoise.com/running-in-circles/ Ideal Spec is fixed and correctly estimated. It’s liner labor

https://m.signalvnoise.com/running-in-circles/ Reality

Leanings From (Lightweight) Agile Agile™ is not always answer. We should focus on “shipping”, not velocity. We should embrace “unknowns”

6 Week Release Cycle What is it? How does it work at Platform Team?

https://m.signalvnoise.com/how-we-structure-our-work-and-teams-at-basecamp/

No content

6 Week Release Cycle ● We work in 6 week release cycle ● We have big Ecpic and small Epic ● We have 1-2 big Epics and 2-3 small Epics (*) ● We assign one subteam (release team) to each Big Epic ● We assign one subteam (release team) to all Small Epics ● We assign 2-3 engineers to one subteam ● We have 1 week buffer between cycles (*) Depends on the team size or situation

6 week release cycle Release team Big Epic Release team Small Epics We can release some version of any feature in 6 week Take up the full six weeks to get done Take anywhere from a day to two weeks to complete Team is 2 or 3 (no more than this). Complexity begins to increase exponentially beyond that

Principles ● Dedicated resource allocation ● Fixed budget and flexible scope

Dedicated Resource Allocation We can’t make progress if people constantly pull at their attention (e.g., bug reports or new feature requests) ● Release team must only focus on the Epic ● Release team must be protected from others by EM and TL (only management layer can do this!) + On-support Team

Fixed Budget and Flexible Scope Ship features with fixed budget and flexible scope ● Fixed budget: 6 week + 2-3 members ● Flexible scope: redefine scope while working

https://m.signalvnoise.com/running-in-circles/ We start project with a core problem and some version of the solution Release team redefine scope based on fixed budget (time and members) Release team ships some version of the solution

Principles ● Dedicated resource allocation ● Fixed budget and flexible scope

Dedicated On Support Team On Support Team helps developers to use platform and platform release subteams to focus on its delivery ● Responds all developers requests (issues & PRs) ● Handles all urgent tasks (critical bug fixes or security incidents) ● Works on technical debts when free time

Evolution of On Support Team ● 1 engineer & daily rotation ● 1 engineer & weekly rotation ● 2 engineer team & cycle rotation <- Best for now!

Outcomes From 6 Week Release Cycle Now we can focus on “shipping”. Our output is highest ever

Next Steps What’s next? What can we improve?

Next steps ● Issue-driven -> Vision-driven ○ e.g., long term roadmap ● Better Epic prioritization ○ e.g., developer survey, KPI based

Conclusion What’s the takeaways?

Conclusion Improving project management is never ending effort. Continuous improvement by team is most important “How”