How We Structure Our Work At Mercari Microservices Platform Team

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/

Ecb3acc2d246962361a4f8b3f7a6dd12?s=128

taichi nakashima

May 22, 2019
Tweet

Transcript

  1. 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
  2. 4.

    Why Project Management? “Maximize team outputs” • = Increase developer(*)

    productivity • = Deliver better product to Mercari customers faster (*) Our “direct customer” is internal developer
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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”
  8. 13.
  9. 14.
  10. 15.
  11. 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)
  12. 19.

    Leanings From (Lightweight) Agile Agile™ is not always answer. We

    should focus on “shipping”, not velocity. We should embrace “unknowns”
  13. 22.
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 31.

    Evolution of On Support Team • 1 engineer & daily

    rotation • 1 engineer & weekly rotation • 2 engineer team & cycle rotation <- Best for now!
  21. 32.

    Outcomes From 6 Week Release Cycle Now we can focus

    on “shipping”. Our output is highest ever
  22. 34.

    Next steps • Issue-driven -> Vision-driven ◦ e.g., long term

    roadmap • Better Epic prioritization ◦ e.g., developer survey, KPI based