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

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

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

E8fe0220162ea15aab7ec96690cc437a?s=128

Jean-Baptiste Vasseur

January 07, 2021
Tweet

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
  2. 2 About Antony • 2018: Joined Mercari as Frontend Engineer

    • 2019: Scrum Master • 2020: Engineering Manager Antony Chane-Hive French
  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.
  4. 4 About February 1st, 2013 Established Tokyo, Sendai, Fukuoka, Osaka,

    Palo Alto, Portland, Boston Offices 1800+ Including subsidiaries Headcount
  5. 5 About Jb @yamaneco _agile UX

  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
  7. 7 Agile is not the goal! Photo by @thematthoward -

    Unsplash
  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
  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
  10. 10 How did this all start Mercari and the Agile

    journey
  11. 11 A few small teams deliver value quickly!

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

  13. 13 ...and problems emerge - Hundreds of employees - Transition

    to Microservices - New management roles needed - Diversity and inclusion - Communication with native English speakers
  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!
  15. 15 Spring 2019, getting serious with Scrum

  16. 16 Agile coaching expectations Start with a few teams who

    are willing to progress with scrum
  17. 17 Agile coaching expectations Organize trainings and workshops as necessary

  18. 18 Agile coaching expectations Coach teams and the organization Coach

    in both English and Japanese
  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
  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
  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
  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
  23. 23 How managers see an Agile transformation Photo by @foxxmd

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

    Unsplash
  25. 25 And so we started our Agile journey and coaching

    Photo by @delfidelarua7 - Unsplash
  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
  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
  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
  29. 29 Build psychological safety

  30. 30 Value experiments and learnings

  31. 31 Promote face to face communication

  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
  33. 33 How did this all start The Camp structure

  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
  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
  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
  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.”
  38. 38 But we are now ready to address them Photo

    by @sailingaroundtheworld - Unsplash
  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...
  40. 40 https://www.slideshare.net/lazarowolf/kanban-pmo-v-10-40119150

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

    working environment
  42. 42

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

  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
  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
  48. 48 What Dynamic Reteaming teaches us

  49. 49 What Dynamic Reteaming teaches us

  50. 50 Here comes FLAT “FLexible Agile Team”

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

  52. 52 Visualize projects first, then let people act

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

    initiatives
  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.
  55. 55 Artefacts & Roles

  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.
  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
  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?
  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.
  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
  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.
  62. 62 How this idea was received? And what went wrong?

  63. 63 A shiny new idea...

  64. 64 … and the feedback

  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.
  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
  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
  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.
  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
  70. 70 What have we observed? When the magic happens!

  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
  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 ‍ ‍
  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 ‍‍‍♂ ‍ ‍ ‍♂ ‍ ‍
  74. 74 • All camp members looked for visualizing our current

    activities Need to visualize and prioritize the activities Activity 1 Activity 1 Activity 3
  75. 75 Conclusion To be continued...

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

  77. 77 … but the magic happened Camp members became change

    agents themselves Discussions Proposals Ideas Improvements Photo by @taylorannwright - Unsplash
  78. 78 ...and so, FLAT helped us learn Propose an idea

    can create a change in people's mindset or behavior.
  79. 79 Thank you! Any questions?