The “FAST” Option for Autonomous Scaling from an Engineering Manager's Perspective (English ver.)

This is a talk given at Regional Scrum Gathering Tokyo 2025, about the story of an engineering manager facing organizational autonomy through the adoption of FAST.

Note: This is a translation of: https://speakerdeck.com/yoshikiiida/rsgt2025

Speaker:
- Yoshiki Iida (Loglass, inc.)
- Takeo Imai (Bonotake / National Institute of Informatics)

Transcript

1. 1 Regional Scrum Gathering Tokyo 2025 The “FAST” Option for Autonomous Scaling from an Engineering Manager's Perspective (English ver.) Yoshiki Iida, Takeo Imai 2025.01.08 ※ These slides are translated to English after the talk. The original version was entirely in Japanese.
2. 2 Self Introduction He joined Cloudworks, Inc. in 2015. After working as an engineer, scrum master, and product owner, he has been overseeing the development department as an executive officer since 2019. In 2020, he joined Loglass Inc. as a software engineer. After working in product development, he became the first engineering manager, designing the organization, building the management structure, hiring engineers, and promoting recruitment PR and branding. He became VPoE, Business Executive Officer, in November 2024. Loglass Inc. Vice President of Engineering Yoshiki Iida
3. 3 Self Introduction He was engaged in software engineering research at a research institute of a major electronics manufacturer, and later worked as an engineer and researcher at several start-up companies. After that, he began focusing on Scrum and Agile, and is currently working as an independent Agile coach, providing support for Agile implementation and associated product management support to various companies, as well as coaching on organizational design and organizational transformation for product development organizations. In addition, as a researcher at the National Institute of Informatics, he is conducting research on the relationship between Agile and product management. Works as a Translator: “Software Abstractions” / 『抽象によるソフトウェア設計』 (2011) “Types and Programming Languages” / 『型システム入門』 (2013) “The Heart of Innovation” / 『なぜイノベーションは起こらないのか』 （2025） Agile Coach / Software Engineering Researcher Takeo Imai (Bonotake)
4. 4 About Loglass Inc.
5. 5 What to talk / not to talk today What to talk: A story of an engineering manager facing organizational autonomy What not to talk: Detailed description of FAST
6. 6 FAST in a nutshell • Framework inspired by OST • Developers gather around a proposed item form a team ◦ Fluid teaming ◦ Collective intelligence determines “What to develop” • Requires individual autonomy of the members ◦ Much less rules, much more freedom From: a blog post “動的なチーミングと自律 MAXで組織をスケールさせるアジャイ ルフレームワーク FASTとは？” https://prd-blog.loglass.co.jp/entry/2024/09/12/181043
7. 7 Disclaimer • Loglass is not stopping Scrum, since FAST is practiced only in one product, and other products are developed using Scrum. • Engineering Managers at Loglass are centered on People management out of People, Product, Project, and Technology, and covers other areas as the situation requires. ◦ In the following slides, an “Engineering Manager” is referred to as a “Manager”.
8. 8 1. Why we started to think scaling 2. From study of scaling to adoption of FAST 3. Managers’ position 4. What FAST has given us 5. What FAST is interesting Agenda Reflections from Manager Commentary by Agile Coach
9. 9 01 Why we started to think scaling
10. 10 History of Team Structure • 2020〜2022: One Scrum team grows to Three • 2023〜2024: Need for inter-team collaboration to scaling Why we started to think scaling Team A Data Import Team B Master Data Setting & Data Conversion Team C Data Analysis & Output One shared codebase, three area with three teams
11. 11 Issues from Manager’s perspective • Reducing cognitive load by separating area and teams led to coordination costs for collaborations for knowledge sharing and communication • Organisational growth of fast-growing startups brought difficulties with the existing structure ◦ Scrum has limitation on the number of team members and reteaming Why we started to think scaling
12. 12 Assumption for self-organization We assumed that most collaboration problems could be solved if the individual Scrum teams self-organised well. In practice, however, each team has developed its own culture (e.g., some teams have a leader and others do not, etc.), which led to difficulties in collaboration. Why we started to think scaling
13. 13 Problems occurred: from Agile Coach’s Perspective (1) Excessive siloing • Provided intra-area development, we had no problems. • Once we started inter-area development, various problems emerged: ◦ Culture gaps b/w teams brought frictions and conflicts ◦ A joint kick-off was required every time we embarked on one epic, and coordinations occurred from time to time. • It was as if they were setting up cross-departmental projects every time on each epic. Why we started to think scaling
14. 14 Problems occurred: from Agile Coach’s Perspective (2) Lack of a holistic view to the product Each team's area ‘chopped’ the user journey, preventing developers from getting a holistic view of the user experience. Therefore, they were: • Prevented from true product understanding. • Unable to build quality for the total user experience. ◦ Only suboptimizations were possible User Journey Team A Data Import Team B Master Data Setting & Data Conversion Team C Data Analysis & Output Why we started to think scaling
15. 15 Summary of Background • Challenges: ◦ Capturing holistic values of the product across the areas ◦ Collaborating between teams ◦ Coordinating staff increases and transfers • Goals: ◦ Tackling with holistic solutions to business issues ◦ Adapting with agility to changing circumstances We can now think about how to be agile in each team. From here, we should think about scaling from a higher perspective. Let's face the issue of cognitive load head-on again! Why we started to think scaling
16. 16 02 From study of scaling to adoption of FAST
17. 17 Collaboration between teams Discussions were already taking place with scaling in mind in January 2024. There was a growing momentum to learn about scaling in order to make inter-team collaboration work. From study of scaling to adoption of FAST ※1. Translated from original Japanese messages. ※2. “Fugaku” and “Polaris” are team names. If we're talking about breaking down silos, right now, Fugaku is handling items from Polaris as part of the ongoing XXX response. And while there were some concerns, they seem to be managing it reasonably well (at least for now). On top of that, we're seeing more dialogue between Fugaku and Polaris than ever before. So, instead of treating this kind of reaction as just an emergency response, maybe we could incorporate it into our regular workflow little by little. Just throwing out an idea here, but what if we held a marketplace once a month where all teams come together to actively take on or swap items from other teams?
18. 18 Volunteer study groups and the Promotion team • Held study sessions for comparative study of multiple frameworks to deepen understanding of scaling. • Structured the FAST adoption project across teams, mainly by engineers and designers. From study of scaling to adoption of FAST April May June July August September • Held study sessions of scaling frameworks (e.g. Less, S@S, FAST) • Discussed pros/cons and fit to our issues • Formed the promotion team for FAST adoption • Tried FAST in the promotion team itself • Experimented FAST within each ex-Scrum team • Decided to adopt FAST officially • Made a guideline for the adoption • Started the adoption from August
19. 19 Launch of Study group Agile coach set up a study group, which later became the basis of the promotion team. From study of scaling to adoption of FAST Sorry to bother you so damn late. I want to start a study group of volunteers to scale our Scrum and make the entire development org. more agile from a mid- to long-term perspective. (I've been prodding Yoshiki to do it, but I'm starting to think it would be better if I took the initiative.) My goal is to make all teams, incl. not only the developers, but also the designers and PdMs, work together organically, as if the entire development org. were one single team, in other words, a “Team of Teams”. We should aim for such an organization in a bottom-up manner. So, I'm planning to hold a kick-off session somewhere in the next week or so, so if you agree with the above and want to join us, please feel free to react to this comment. If you have any other comments, requests, or questions, please send them to the thread. ※. Translated from original Japanese messages. Apr 11. (Thu)
20. 20 Study group to create a bottom-up movement Formerly, some leaders tended to take the initiative and lead the organization strongly. However: • Agile scaling does not succeed with top-down movement alone. • The org. size was no longer such that practically everyone could follow on momentum alone. So I wanted to build grassroots momentum from the bottom up, without direct managerial initiative, and I was the only person who could start such a movement. From study of scaling to adoption of FAST
21. 21 Artifact of the study sessions From study of scaling to adoption of FAST FAST was the most popular of the members.
22. 22 The results of the briefing for the whole organization From study of scaling to adoption of FAST A forum was held to explain how the process would change from the current process, including to those who had not participated in the study group. The main opinion was that there were concerns but a willingness to think positively.
23. 23 Decision for a full-scale trial of FAST • Each of the frameworks seemed to address the challenges, but FAST seemed the most effective. ◦ However, FAST also seemed to have the biggest gap with the current process. • The most common response from the whole product org. was a desire to challenge and to address concerns. (Pure opposition was surprisingly low.) • There was also a genuine curiosity to try something that had no precedent in the country. I thought this initiative would be of great value to us and to our industry. From study of scaling to adoption of FAST From the response of the members, we thought, “Can’t we do it? Let’s give it a go!”
24. 24 Why we could challenge FAST, Supplemental The Loglass product org. had a Tech Value called ‘Update Normal’and was nicknamed “アプノマ” (up-noma) by its members. I observed members mentioned “アプノマ” during adoption of FAST, which had a significant contribution to fostering a mindset of embracing change. From study of scaling to adoption of FAST
25. 25 From study of scaling to adoption of FAST All guys at Loglass are serious about doing up-noma and I think that's why FAST has been able to introduce it so well (much better than expected). But I wonder if some people tell themselves up-noma and feel something hard... BTW the work in Loglass was too hard for me in these half-year or so. Up-noma seemed effective if someone could do what was hard because we must do up-noma. Undoubtedly. It is much more effective than you all think. ※. Translated from original Japanese messages.
26. 26 Actual transition process 1. Implement FAST to the promotion project itself within the promotion team. 2. Understand what happens when each member works autonomously by getting the whol org. used to OST. 3. Adopt the single-team FAST within each ex-Scrum team. 4. Prepare the entire product org. for the FAST transition (i.e., Big Picture, guidelines, etc.). From study of scaling to adoption of FAST ※Big Picture a visualization of the overall product goal and the factors to to achieve it. We created it as a tree in Miro.
27. 27 Big Picture of the promotion team (at the time) From study of scaling to adoption of FAST Each leaf item are refined to “little pictures” by members (or discovery trees)
28. 28 Aside: Loglass' approach to adopting FAST They were (probably) the first to try adopting single-team FAST with existing Scrum teams and then merge them. This approach enabled them to find: - Issues that come up when adopting to the whole org. - Practices that would be good for the whole org. This allowed them to take countermeasures much earlier when major issues were to emerge after merging. From study of scaling to adoption of FAST
29. 29 03 Managers’position
30. 30 Contradiction in my mind Managers’position Is FAST introduced by managers truly “autonomous”???
31. 31 A sense of danger in keeping me leading the org. • I had to take full responsibility for setting up a “Ba” and moving them forward. • However, how should we handle the final organization-wide decision-making process? ◦ Managers can make decisions with strong initiative. ◦ But if you keep doing that, it's not FAST. • There are both feelings that I had to lead them and that I should not stay there as I was. Managers’position
32. 32 Problems arose during our experiments “Who is responsible for advancing this?” vs “It's a problem that if Yoshiki doesn't do something, it won't get any further.” Managers’position
33. 33 My position Promotion Team Whole Product Org. While respecting the bottom-up movement, I must have the accountability to introduce FAST. Various stakeholders Managers’position
34. 34 Delegation in promotion and transition • A stagnation period has occurred, where everyone wanted to do it, but couldn’t make up. • It was a matter of decision making, so I set a policy that we would start transition in August, and left the rest completely up to the promotion team. ◦ I faded out of the team. • Then, within about two weeks, the team made the guideline for the entire transition, and we were able to make the transition. Managers’position
35. 35 What happened there Strong momentum was formed on the ground, and the whole members paved the way with different perspectives. What we have needed must be “a rallying cry”. Managers’position
36. 36 Updating mental models of members including me I had to face with the implicit impact managers have, although I thought I understood it. • “Why don’t we talk to the manager?” • “This should be done by the manager.” Lessons learned: It is easier for the entire organization to move forward if you have a clear distinction between what you want and what you actually do, and if you share the criteria throughout the organization. Managers’position
37. 37 04 What FAST has given us
38. 38 Solving the issues we had • Eliminated the communication costs b/w teams with different cultures. ◦ They can now autonomously and dynamically make their own teams, without coordination by managers • Accelerated cross-functional domain activities and increased knowledge mobility, making it easier for members to gain product understanding. What FAST has given us
39. 39 What was good from a medium/long-term perspective We all can now: • Work together to develop processes and a culture that is globally optimized rather than individually optimized. • Do self-organised collaboration without the boundaries of the team. What FAST has given us As is likely to happen in many organisations, Loglass also saw signs of silos as the organisation grew. So it was extremely valuable to break down the silos and to allow us to find total optimizations.
40. 40 What has improved (from Agile Coach’s perspective) • Barriers between the old teams has disappeared. • Product management is now closer from engineers. ◦ All engineers are now able to think of the whole product and discuss overall policy directly with the product managers. • They now became one big product team. What FAST has given us
41. 41 Remaining issues (from Agile Coach’s perspective) • True product understanding is still a long way off. ◦ The cognitive load naturally increases as the scope is widened. ▪ Product complexity vs. Developer’s cognitive load • The collective’s cohesion is still in place, and there is a wide variation in understanding b/w members. ◦ Toughness through dozens of members and fluid teaming ◦ Some people miss Scrum in this respect What FAST has given us
42. 42 “To tell the truth” Initially, I thought no frameworks were needed. • The study sessions were to introduce frameworks as “Katas” of scaling for members with no knowledge. Then, they chose FAST, which surprised me, actually. In retrospect, however, they made a good choice, I believe. What they are experiencing now will definitely be a great asset in the future. What FAST has given us
43. 43 05 What FAST is interesting
44. 44 Unlearning the common sense of Scrum • In Scrum, teams should be stable. ◦ Replacing members indiscriminately is not recommended. • In FAST, teams are fluid. ◦ We found improvised teaming actually works. ◦ Some sort of sports players seem to familiar with this. ▪ It's similar to playing a game with the people gathered there, divided into teams. What FAST is interesting
45. 45 About fluid teaming • I relied on Amy C. Edmondson’s research about teaming. ◦ “Why do improvised teams sometimes perform better?” ◦ One of the factors found here is “psychological safety.” • Her book “Teaming” was the recommended reading for the promotion team. • This was the basis for advising Yoshiki on introducing a framework that has no precedent. What FAST is interesting Amy C. Edmondson, Teaming: How Organizations Learn, Innovate, And Compete In The Knowledge Economy
46. 46 High standards required to achieve autonomy The basic philosophy of FAST is that each individual must have a deep understanding of their product/business and make optimal solutions. The standards required of each member are honestly considered to be high. What FAST is interesting
47. 47 Autonomy and leadership However, no matter how high an individual's vision may be, someone's initiative is needed to guide the movement throughout the organization. • Information, coordination, will, and courage are needed when making big organizational changes. • Previously, this has often been the responsibility of managers, but in the future it may be possible to do this from within FAST. What FAST is interesting
48. 48 Member autonomy and Manager’s leadership can work together • The initiative to start FAST and other cross-organizational issues have so far been able to take overall leadership from a call to action. • It is good to be able to use different leadership styles for different situations, such as those found in Elastic Leadership. What FAST is interesting Roy Osherove, Elastic Leadership: Growing self-organizing teams • Self-organizing mode • Learning mode • Survival mode
49. 49 How to use Elastic Leadership styles • Self-organizing mode ◦ ex) Follow what is decided within FAST. Contribute by providing information for better decision making. Let them think autonomously about policies. • Learning mode ◦ ex) Have them trial-and-error with the promotion team and update hypotheses. Decide only a policy, and let them move autonomous. • Survival mode ◦ ex) In emergency, prioritize things in an top-down manner and let them follow. Check and monitor if the whole org. is able to focus on what they should now the most. What FAST is interesting I thought once that every time we had to be in self-organizing mode, but it is not. Sometimes it is better for leaders to act in the survival mode. The beauty of FAST is that it is not limited to managers but can be done by any members.
50. 50 Conclusion
51. 51 Our conclusion In summary, what has been most beneficial was that we did bold reframing and unlearning. • The framework does not essentially matter. The story was how we all can escape from silos and think the global optimization holistically. • However, FAST, a minimal and entirely new framework, let us face what we have to think essentially and what managers really should do from the scratch. • We were able to consider what is the autonomy each members should demonstrate.