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. 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”
  13. None
  14. None
  15. None
  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/

  22. None
  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”