How We Structure Our Work At Mercari Microservices Platform Team

This is slides for Mercari Meetup for Microservices Platform #2 https://connpass.com/event/128017/

Transcript

1. How We Structure Our Work At Mercari Microservices Platform Team
2. Taichi Nakashima @deeeet / @tcnksm
3. 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
4. Why Project Management? “Maximize team outputs” • = Increase developer(*) productivity • = Deliver better product to Mercari customers faster (*) Our “direct customer” is internal developer
5. 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
6. History How we evolve our product management? What kind of problem we faced before?
7. Team growth 9 Members
8. Team growth No Project Management Agile 6 Week Release Cycle
9. 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
10. 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
11. 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
12. (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”
16. (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)
17. https://m.signalvnoise.com/running-in-circles/ Ideal Spec is fixed and correctly estimated. It’s liner labor
18. https://m.signalvnoise.com/running-in-circles/ Reality
19. Leanings From (Lightweight) Agile Agile™ is not always answer. We should focus on “shipping”, not velocity. We should embrace “unknowns”
20. 6 Week Release Cycle What is it? How does it work at Platform Team?
21. https://m.signalvnoise.com/how-we-structure-our-work-and-teams-at-basecamp/
23. 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
24. 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
25. Principles • Dedicated resource allocation • Fixed budget and flexible scope
26. 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
27. 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
28. 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
29. Principles • Dedicated resource allocation • Fixed budget and flexible scope
30. 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
31. Evolution of On Support Team • 1 engineer & daily rotation • 1 engineer & weekly rotation • 2 engineer team & cycle rotation <- Best for now!
32. Outcomes From 6 Week Release Cycle Now we can focus on “shipping”. Our output is highest ever
33. Next Steps What’s next? What can we improve?
34. Next steps • Issue-driven -> Vision-driven ◦ e.g., long term roadmap • Better Epic prioritization ◦ e.g., developer survey, KPI based
35. Conclusion What’s the takeaways?
36. Conclusion Improving project management is never ending effort. Continuous improvement by team is most important “How”