Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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/

taichi nakashima

May 22, 2019
Tweet

More Decks by taichi nakashima

Other Decks in Technology

Transcript

  1. How We Structure Our Work
    At Mercari Microservices Platform Team

    View full-size slide

  2. Taichi Nakashima
    @deeeet / @tcnksm

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  7. Team growth
    9 Members

    View full-size slide

  8. Team growth
    No Project
    Management
    Agile
    6 Week
    Release Cycle

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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”

    View full-size slide

  13. (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)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  19. 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

    View full-size slide

  20. 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

    View full-size slide

  21. Principles
    ● Dedicated resource allocation
    ● Fixed budget and flexible scope

    View full-size slide

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

    View full-size slide

  23. 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

    View full-size slide

  24. 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

    View full-size slide

  25. Principles
    ● Dedicated resource allocation
    ● Fixed budget and flexible scope

    View full-size slide

  26. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. Conclusion
    What’s the takeaways?

    View full-size slide

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

    View full-size slide