RSGT2021: 破？scrumからFLATを生み出して実験してみた話し / FLAT: the story of an experiment moving from scrum to our new framework

株式会社メルカリは2年前から本格的にスクラムを導入し、実践してきました。

ところが、とあるLogisticsキャンプ（同じビジネスドメインに専任をする複数のチームのこと）ではスクラムから少し離れてFLATというフレームワークを生み出そうとしていました。FLexible Agile TeamはDynamic Reteamingからインスパイアされ、スクラムパターンの「安定チーム」を意図的に反する複数なアジャイルチームのための実験的なものであった。

FLATの狙いは限られたスキルと人数でキャンプメンバーをエンパワーして、複数の新機能及びリファクタリングをより柔軟に実現できるようになること。

果たしてそれは無謀な試みなのか、アンチパターンだらか失敗はされていたのか、あるいは素晴らしい学びと成長につながるきっかけだったか、守破離の破なのか、どうなのか？！？

本セッションではメルカリのスクラム導入背景及びLogisticsキャンプで行われたFLAT実験について詳しくご紹介致します。

---

Once upon a time, about two years ago, Mercari adopted scrum and started practicing and learning a new mindset and methodologies.

In the galaxy of Logistics, a group of people decided then to move away from strict scrum and gave birth to a new framework, FLAT. FLexible Agile Team was inspired by the book "Dynamic Reteaming", and deliberately broke the sacred scrum pattern "Stable Teams" for its multiple teams.

The main goal of FLAT was to empower logistics members and give them a chance overcome their challenges, such as limited resources for specific competencies, new awesome features to increase the user experience and the product value but at the same time a lot of maintenance and refactoring work to carry out.

What will be ultimately the destiny for FLAT? Was this a reckless attempt? Was breaking a scrum pattern a guarantee to fail? Or did was this an opportunity for amazing learnings and growth?

In this session we will talk about Mercari's Agile journey, scrum adoption, Camp Structure, the birth of FLAT and the learnings acquired from this experiment.

---

https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/15033/online-interpretation-scrumflat-flat-the-story-of-an-experiment-moving-from-scrum-to-our-new-framework

Transcript

1. 1
   FLAT: the story of an experiment
   moving from scrum to our new
   framework
   破？scrumからFLATを生み出して実験してみた話し
   Regional Scrum Gathering Tokyo 2021
   2021-01-07
   

   View Slide

2. 2
   About Antony
   ● 2018: Joined Mercari as Frontend Engineer
   ● 2019: Scrum Master
   ● 2020: Engineering Manager
   Antony Chane-Hive
   French
   

   View Slide

3. 3
   What Is Mercari?
   ● Service start: July 2013
   ● OS: Android, iOS
   *Can also be accessed by web browsers
   ● Usage fee: Free
   *Commission fee for sold items: 10% of the sales price
   ● Regions/languages supported: Base specs for
   Japan/Japanese
   ●Total number of listings to date: More than 1.5 billion
   Many sellers enjoy having the items they no longer
   need purchased and used by buyers who need them,
   and buyers enjoy the feeling of hunting for treasure as
   they search through unique and diverse items for lucky
   finds. In addition to buying and selling, users actively
   communicate through the buyer/seller chat and the
   “Like” feature.
   The Mercari app is a C2C marketplace where individuals
   can easily sell used items. We want to provide both
   buyers and sellers with a service where they can enjoy
   safe and secure transactions. Mercari offers a unique
   customer experience, with a transaction environment
   that uses the payments Mercari holds in escrow, and
   simple and affordable shipping options.
   

   View Slide

4. 4
   About
   February 1st, 2013
   Established
   Tokyo, Sendai,
   Fukuoka, Osaka,
   Palo Alto, Portland,
   Boston
   Offices
   1800+
   Including
   subsidiaries
   Headcount
   

   View Slide

5. 5
   About Jb
   @yamaneco
   _agile
   UX
   

   View Slide

6. slide with multiple pieces here
   Since
   2017
   “We help build
   happy teams”
   Agile
   Coaching
   DevOps
   UX
   Design
   Trainings
   Workshops Tokyo
   Japan
   Software
   design &
   development
   

   View Slide

7. 7
   Agile is not the goal!
   Photo by @thematthoward - Unsplash
   

   View Slide

8. 8
   Our Agile journey
   Photo by @jerrykavan - Unsplash
   2018
   2019
   2021
   Adopted
   Scrum
   Camp
   Structure
   Introduced
   2020
   FLAT
   created
   Magic
   happens
   Cross
   functional
   teams
   

   View Slide

9. 9
   ● The Agile journey in Mercari - getting started with Agile and
   scrum
   ● The Camp Structure - progressing towards cross functional teams
   ● FLAT (FLexible Agile Team) - an attempt to break team silos
   ● Our experiment and learnings with FLAT in Logistics Camp
   ● Conclusion
   Agenda
   

   View Slide

10. 10
    How did this all start
    Mercari and the Agile journey
    

    View Slide

11. 11
    A few small teams deliver value quickly!
    

    View Slide

12. 12
    Then the Company grows...
    Photo by @beastydesign - Unsplash
    

    View Slide

13. 13
    ...and problems emerge
    - Hundreds of employees
    - Transition to Microservices
    - New management roles needed
    - Diversity and inclusion
    - Communication with native English speakers
    

    View Slide

14. 14
    How can we bring back the momentum?
    We need more structure and
    standardized processes!!
    We need to be Agile! We need
    scrum!
    We may want to have some scrum
    experts help us on the way...
    Oh, I know a group of Agile coaches I
    worked with before, let me get in touch
    with them!
    

    View Slide

15. 15
    Spring 2019, getting serious with Scrum
    

    View Slide

16. 16
    Agile coaching expectations
    Start with a few teams
    who are willing to
    progress with scrum
    

    View Slide

17. 17
    Agile coaching expectations
    Organize trainings and
    workshops as necessary
    

    View Slide

18. 18
    Agile coaching expectations
    Coach teams and the
    organization
    Coach in both English
    and Japanese
    

    View Slide

19. 19
    Mercari strategy for adopting scrum
    Stage 1
    Understand the basics of Agile/scrum.
    Organize team backlogs and run scrum ceremonies.
    Stage 2
    Ready to start continuous improvement based on metrics.
    Work is written as User Stories, and is being estimated for tracking
    velocity. The Why and Definition of Done are used.
    Stage 3
    Continuous improvement on both the process, estimates, and
    quality.
    Stage 4
    Coordinate and support other teams.
    The concept of large scale Agile development can be considered.
    We are
    here
    

    View Slide

20. 20
    Stage 1 - Use JIRA!
    - Story ticket describes a single user story (no multiple stories in a Story ticket)
    - Epic ticket describes high level goal of multiple user stories
    - Task ticket describe a single task
    - Map Epic and Story by EpicLink
    - Ordered items in the product backlog by priority
    - PM finishes design(Business logic, UI etc) before Sprint Planning Meeting
    - Engineers finish Tech Design before Sprint Planning Meeting
    - Have Sprint Planning Meeting
    - Specify what stories will be developed in the Sprint Planning Meeting
    - Have Demo(Sprint Review), and the dev team demonstrate actual software
    - Have Retrospective meeting, and the team picks up some try for next sprint
    - Describe why it good or bad in Keep and Problems
    - Use WHO-WHAT-WHY user story format to describe use story
    

    View Slide

21. 21
    Stage 2 - Show us metrics!
    - WHY is clearly described and it shows real motivation or root issues of our customers
    - Clearly explained acceptance criterias (Complete condition of Done)
    - Estimate business impact and describe it in the User Story or Tech Story
    - Have the team's base line(velocity) for a sprint from past sprints
    - Estimate and assign story point to each story by the Sprint Planning Meeting
    - Specified members and set proper load factor to estimate capacity for next sprint.
    - Create tasks for story, and estimate them before Sprint Planning Meeting
    - Define scope properly by estimation of tasks and capacity in the Sprint Planning
    Meeting
    - Calculated burn-down chart by story points
    - Have 2 phases planning which are high-level and sprint level to understand overall
    release plan
    

    View Slide

22. 22
    Stage 3 - Be good at estimates!
    - Estimate story point to story/Tech Story before Prioritization
    - Estimate size of story/task
    - Record actual work volume to complete Story and Task
    - Have detail analysis for big gap between estimation and actual in hours in the
    retrospective meeting
    - Have discussion for wrong estimation and find some try to improve the estimation in
    the retrospective meeting, and run continuously it
    - Check business impact between estimation and actual based on Story, Tech-Story
    - Implement quality measurement and start continuous improvement based on it
    

    View Slide

23. 23
    How managers see an Agile transformation
    Photo by @foxxmd - Unsplash
    

    View Slide

24. 24
    How it actually turns into
    Photo by @amitjain0106 - Unsplash
    

    View Slide

25. 25
    And so we started our Agile journey and coaching
    Photo by @delfidelarua7 - Unsplash
    

    View Slide

26. 26
    - “We have too many projects!”
    - “We have too many meetings!”
    - “We have very good connections within the team, but we feel isolated
    from the other teams, and from the business.”
    - “There are problems on the organizational level, but there is nothing we
    can do about it.”
    First observations on a few teams
    

    View Slide

27. 27
    - No Product owner role in the team, multiple stakeholders!
    - No dedicated Scrum Master.
    - Frontend and Backend have been separated for the sake of
    Microservices architecture, but it makes collaboration and communication
    more difficult.
    First observations on a few teams
    

    View Slide

28. 28
    - Facilitates scrum events (facilitation)
    - Mentor Scrum Master role (mentoring)
    - Bring observations of team dynamics (feedback)
    - Teach scrum and popular patterns (trainings, workshops)
    What can we actually bring at this stage?
    Photo by @delfidelarua7 - Unsplash
    

    View Slide

29. 29
    Build psychological safety
    

    View Slide

30. 30
    Value experiments and learnings
    

    View Slide

31. 31
    Promote face to face communication
    

    View Slide

32. 32
    Our Agile journey
    Photo by @jerrykavan - Unsplash
    2018
    2019
    2021
    Adopted
    Scrum
    Camp
    Structure
    Introduced
    2020
    FLAT
    created
    Magic
    happens
    Cross
    functional
    teams
    

    View Slide

33. 33
    How did this all start
    The Camp structure
    

    View Slide

34. 34
    Why Camps ?
    ● More micro decisions to reduce the back and forth between
    Engineers and the management
    ● A better alignment between each team in terms of goals
    ● A better communication between teams working on the same
    domain
    ● A better roadmap to build our product
    

    View Slide

35. 35
    What is Camp Structure?
    Team
    Team
    Team
    Camp Heads
    （Eng / PM）
    Team
    Team
    Team
    Camp Heads
    （Eng / PM）
    Team
    Team
    Team
    Camp Heads
    （Eng / PM）
    Client
    Backend
    /AI
    Arch / MS /
    SRE
    Product Team Team Team
    Team Team Team
    Team Team Team
    Team Team Team
    Misaligned
    roadmap/OKR
    Aligned
    roadmap/OKR
    Product /Client / Backend
    system
    Camp system
    

    View Slide

36. 36
    What camp structure is trying to achieve?
    ● A PM head and a Engineering head for better leadership and
    alignment
    ● Defined by domain to improve communication and coordination
    ● Enable cross functional teams to remove competency silos
    

    View Slide

37. 37
    With Camp structure we have constraints...
    “The Camp has to develop and
    deliver many Business and
    Engineering projects in parallel
    with limited skill and people
    capabilities.”
    

    View Slide

38. 38
    But we are now ready to address them
    Photo by @sailingaroundtheworld - Unsplash
    

    View Slide

39. 39
    We have been facing challenges in 2020
    - It is difficult to contribute for another team because each team has its isolated
    Scrum implementation and ceremonies (no lightweight cross-team coordination).
    - If I am interested in a project assigned to another team, I am not empowered
    enough to decide to reassign myself where I feel I would receive growing
    opportunities and help my teammates.
    - I don’t know what is most important thing we should focus on between Product
    and Engineering initiatives.
    - I feel that our teams could be balanced in a better way in terms of skills,
    competencies, experience, and leadership.
    As a Camp member...
    

    View Slide

40. 40
    https://www.slideshare.net/lazarowolf/kanban-pmo-v-10-40119150
    

    View Slide

41. 41
    Our Camp leadership is committed build us a
    better working environment
    

    View Slide

42. View Slide

43. 43
    So how might we...
    … become an Engineering-Driven
    Camp guided by goals and
    capable of adapting quickly in
    response to the needs of
    Business and Engineering
    activities?
    

    View Slide

44. 44
    Can we break the team silos inside the Camp?
    feature feature
    feature feature
    1 large Product
    Team
    1 small
    Product
    Team
    2 products / 4 teams 2 products / 2 teams
    ?
    Scrum
    Kanban
    Scrumban
    We have too
    many Mobile
    tasks
    Can we do Mobile tasks
    for other teams?
    We want to start
    an improvement
    

    View Slide

45. 45
    And become more flexible to achieve our goals?
    Push
 Pull

    Visualized project and initiative
    priorities from which people can
    self organize around. 

    Fixed teams where we put a
    bunch of projects.

    

    View Slide

46. 46
    “Whether you like it or not, your
    teams are going to change.”
    “Team change is inevitable,
    get good at it.”
    Dynamic Reteaming is team change
    

    View Slide

47. 47
    It often results in moving people from team to team when starting projects, or crisis to crisis during
    delivery, and leads to an unstable environment with added costs of:
    - administration overhead
    - reduced efficiency from onboarding
    - exposure to Brooks’ Law
    Therefore,
    Keep teams stable and avoid shuffling people around between teams. Stable Teams
    tend to get to know their capacity, which makes it possible for the business to have some
    predictability.
    Stable Teams is a scrum pattern
    https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/development-team/stable-teams
    

    View Slide

48. 48
    What Dynamic Reteaming teaches us
    

    View Slide

49. 49
    What Dynamic Reteaming teaches us
    

    View Slide

50. 50
    Here comes FLAT
    “FLexible Agile Team”
    

    View Slide

51. 51
    https://www.slideshare.net/lazarowolf/kanban-pmo-v-10-40119150
    

    View Slide

52. 52
    Visualize projects first, then let people act
    

    View Slide

53. 53
    Camp heads shall…
    Prioritize and
    visualize all projects
    and initiatives
    

    View Slide

54. 54
    Camp members shall...
    Measure
    our
    progress
    toward
    release at
    every
    iteration
    Identify the
    needs in term of
    competencies
    and capacity in
    order to keep on
    track.
    Concert with the
    rest of the Camp
    and self assign
    before starting a
    new iteration.
    

    View Slide

55. 55
    Artefacts & Roles
    

    View Slide

56. 56
    The FLAT (FLexible Agile Team) Manifesto
    ● At any time, anyone can see all
    activities undertaken in the Camp,
    and know their priorities.
    ● All Camp members are trusted and
    empowered to self-organize and
    come up with the most effective
    team formation, and to adjust it as
    needed.
    ● Any member can propose a new
    initiative and get the opportunity
    to pursue it with motivated
    volunteers.
    

    View Slide

57. 57
    FLAT iteration flow as a Camp
    Camp
    Review
    Camp
    Retro
    Camp
    Sync
    Camp
    Sync
    • Check the progress
    of each activity
    • Share roadmap
    • Share new activities
    • Define next goals
    • Update Engineer's
    self-assignment
    Check activity priority
    Sharing upcoming
    activity
    • Check activity priority
    • Present a new activity
    by a Camp member
    • Improve the Camp with all
    Camp members
    • Participation by interest
    2 weeks
    iteration
    All Camp
    members
    All Camp
    members
    Camp Owners
    Activity Project Owners
    Does not change
    so much
    We don't want assignment
    changes every iteration but
    they are welcome
    Camp Owners
    Activity Project Owners
    

    View Slide

58. 58
    FLAT iteration flow as an Activity
    Daily Activity
    Sync
    • Share daily goal
    • Share blockers
    2 weeks
    iteration
    Activity
    Sync
    Activity
    Sync N
    • Schedule as needed
    for an activity
    • Refine, estimate and
    plan tasks
    Does not change
    so much Activity Sprint Planning is not
    mandatory anymore.
    There is a Camp Retrospective but an
    activity can run a retrospective at their
    discretion
    Maybe try Kanban for an
    activity?
    

    View Slide

59. 59
    The FLAT Manifesto
    ● At any time, anyone can see all
    activities undertaken in the Camp,
    and know their priorities.
    ● All Camp members are trusted and
    empowered to self-organize and
    come up with the most effective
    team formation, and to adjust it as
    needed.
    ● Any member can propose a new
    initiative and get the opportunity
    to pursue it with motivated
    volunteers.
    All projects and initiatives shall be visualized
    by Camp heads in a unique location so that
    anyone can refer to them and stay aligned.
    Each activity shall be provided with a
    release planning (backlog, velocity,
    burndown), and people needs so that
    anyone can decide where they can be the
    most valuable for the Camp.
    Camp sync ceremony shall be open to
    anyone to participate and propose a new
    initiative.
    

    View Slide

60. 60
    Getting started with FLAT
    - What we already have and don’t need to change
    - Camp event schedule
    - Current teams can stay intact during the first iteration
    - What we don’t have and need to do
    - Backlog and release planning for each activity
    - Needs for each activity (does not have to be perfect the first time)
    - Visualize all activities in one location and ensure it is shared to EVERYONE
    - Camp retro
    - The idea of camp wide retrospective is not accepted yet
    

    View Slide

61. 61
    FLAT Anti-Patterns
    ● Camp heads not updating and communicating priorities
    ● Camp members not building a backlog and release planning
    ● Camp members not visualizing needs for each activity
    ● Chaos fluidity: everyone goes randomly everywhere without
    consultation and taking in account what makes most sense for
    the Camp.
    

    View Slide

62. 62
    How this idea was received?
    And what went wrong?
    

    View Slide

63. 63
    A shiny new idea...
    

    View Slide

64. 64
    … and the feedback
    

    View Slide

65. 65
    We had to deliver big releases
    Photo by @nguyendhn - Unsplash
    - Teams were implementing new features with a tight schedule.
    The introduction of a new process should be done with care to
    limit the disruption of teams.
    

    View Slide

66. 66
    ● The core part of FLAT is the visualization
    of the activities and the team capacity.
    Without this information, the framework
    cannot work well.
    Did the identified anti-patterns
    Photo by @timmossholder - Unsplash
    

    View Slide

67. 67
    - We fell into a hole where we tried to imagine all interactions and
    possibilities.
    This brought too many details into the framework and a lot of
    questions by the camp members.
    Too detailed before implementing the framework
    Photo by @f7photo - Unsplash
    

    View Slide

68. 68
    ● We shared what we should change but not a clear step by step
    change to be done to achieve the transformation.
    No clear step by step migration
    Photo by @gerandeklerk - Unsplash
    - We fell into a hole where we tried to imagine all interactions and
    possibilities.
    This brought too many details into the framework and a lot of
    questions by the camp members.
    

    View Slide

69. 69
    There was some confusion by the team members about how to
    start and how each person should work to achieve this
    transformation. The communication wasn't clear enough and we
    didn't have a clear process for a proposal.
    Confusion for all Camp members
    Photo by @robert2301 - Unsplash
    

    View Slide

70. 70
    What have we observed?
    When the magic happens!
    

    View Slide

71. 71
    ● Camp members observed the need of a process to propose a new
    activity and how to accept or reject it.
    ● This proposal process pushed the Engineers to be more proactive
    and enabled more transparency
    Proposal process
    

    View Slide

72. 72
    ● The framework opens the discussion around the process for
    product development
    ● Each team had more questions around their current process
    started to change their process to better fit their needs
    Teams becoming more self-organized
    ‍
    ‍
    ‍
    ‍
    Kanban
    Scrum
    ‍
    ‍
    

    View Slide

73. 73
    ● Some teams had more than one project to achieve and decided to
    split into smaller teams to achieve their goal
    Splitting into smaller teams to achieve their goal
    ‍‍‍♂
    ‍
    ‍
    ‍♂
    ‍
    ‍
    

    View Slide

74. 74
    ● All camp members looked for visualizing our current activities
    Need to visualize and prioritize the activities
    Activity 1
    Activity 1
    Activity 3
    

    View Slide

75. 75
    Conclusion
    To be continued...
    

    View Slide

76. 76
    We failed with FLAT...
    EPIC FAIL
    

    View Slide

77. 77
    … but the magic happened
    Camp members became change agents themselves
    Discussions
    Proposals
    Ideas
    Improvements
    Photo by @taylorannwright - Unsplash
    

    View Slide

78. 78
    ...and so, FLAT helped us learn
    Propose an idea can create a change
    in people's mindset or behavior.
    

    View Slide

79. 79
    Thank you!
    Any questions?
    

    View Slide