There's More Than One Way To Do It

Scrum may not be inherently necessary for Web development in Japan

Is a full-time Scrum Master needed?


I recently read the paper "The New New Product Development Game," which is the source of Scrum. It is generally a discussion of how US companies can become as good as Japanese companies by adopting good development practices. The Scrum Guide's Scrum also seems to have been influenced by it.

Scrum is a method that is widely adopted in agile development, but there are still companies that do not have a full-time Scrum Master. Let me try to summarize at what point Scrum Guide Scrum is useful and the rationale for having a dedicated Scrum Master.

The New New Product Development Game Overview

Now this paper compares the products of several companies as examples. The products are below.

  • Fuji Xerox mid-size copy machines
  • Canon home copiers
  • Honda passenger cars
  • NEC personal computers
  • Canon SLR cameras
  • Canon's lens shutter camera

The author analyzes their development methods. The classification seems to be waterfall type A where each process is independent, type B where adjacent processes overlap, and agile type C where all processes influence each other.

Leading firms are said to have the following characteristics

  • Inherent instability
  • Self-organizing teams
  • Overlapping development phases
  • Multi-learning
  • Little control
  • Transmission of organizational learning

Generally speaking, it seems that the strength of bottom-up and the ability to turn the cycle of improvement without a strong top-down approach is a good thing about Japanese companies.

Japanese companies have been able to do what Scrum wanted to do from the beginning

In this way, it can be said that at least in the top Japanese companies, the elements of Scrum were already conducted.

The Scrum Guide can be seen as a manual for U.S. companies to adopt Japanese corporate development methods. Japanese companies may not have to do anything.

In Silicon Valley, I hear that engineers change jobs after one or two years. The U.S. is very active in immigration and has a diverse population. It is difficult to share cultural context, so there is a rationale for having a full-time coordinator.

On the other hand, traditional Japanese companies are almost all Japanese and employ people for life. More likely, it was almost exclusively male. Colleagues are familiar faces who have worked together for years. They will often do well without a full-time coordinator. The less diverse the team, the less need for a full-time Scrum Master.

Japanese Companies Need to Raise the Bar at the Manager Level

On the other hand, it is questionable whether Japan can use the same approach in the future. According to OpenWork statistics, overtime hours have decreased from 46 to 24 hours per month in the last 10 years. That's the impact of reforms in the way people work.

It can be said that Japanese companies managers were free-riding on the abilities of players, because even if the managers made a slight mistake in direction, the players covered for them on their own with overtime. As the manpower shortage progresses further in the future, such managers' lack of ability will become more and more visible.

Of course it is good to make what is strong now stronger, but Scrum is a framework for players to work harder, and it is possible that it has already been done in Japan. Instead, it may be more important to consider the opposite framework, such as training for managers, how to bring salaryman presidents closer to founding presidents, and how to incorporate the best aspects of the U.S. into Japanese companies.

There are companies that use employee engagement of members as an indicator for manager evaluation.

No need for a scrum master unless there are many positions within the development team

There are other perspectives on whether a dedicated Scrum Master is needed, for example, one indicator is whether there are many communication paths within the development team.

I think people were talking more about scrum, scrum in the heyday of social games. It is sort of a given, and essentially game development is asset heavy compared to web service development. Programming is not necessarily the high weight of the game. Graphics and voice are also necessary, and naturally there are more communication paths within development. So there is a necessity of having a full-time coordinator.

On the other hand, in the case of toB SaaS, it is said that customer success is necessary due to the business structure. The communication path has shifted from inside development to outside compared to social game development team. The demand for coordination within development is relatively low. On the other hand, PMs in between tend to be busy, and there are companies with multiple PMs here and there.

It is difficult to capture the business structure of not only Scrum, but also other IT companies in general, and since the elements required for web service development, game development, and system integration are different. The team topology of different business types is often not very helpful.

The easier the area is to modularize, the less need for a Scrum Master

There is another factor that makes IT companies less likely to need a full-time Scrum Master. That is because programming is a relatively individual sport among team sports.

The companies in The New New Product Development Game are manufacturers. There are so many parts in an automobile, and they often interact with each other. Mechanical design is hard to be loosely coupled due to its existence in physical space. When you improve the module to improve the sound quality of wireless earphones, it is easy to exceed the weight target, or something like that.

This is not to say that collaboration is unnecessary in IT companies, but what is at the root of the story that the productivity of programmers differs many times from person to person is a baseball pitcher's characteristics, or a highly individualistic part.

I have written before about the difference between capital-intensive and labor-intensive businesses, and there are two types of labor-intensive businesses: those that are team-oriented and those that are highly individualistic. Compared with manufacturer making a camera, if designed properly, we can avoid the tight coupling between modules in programming.

DX consulting jobs will eventually disappear. No need for scrum masters

Finally, I will also write about Scrum Master as a DX consultant. Some people say if Scrum Masters are the teachers of the DX method of Scrum, they are no longer needed once they have finished teaching the method. I think that is true.

I think if a full-time Scrum Master is the actual role name of a startup, it's the COO, because he's not a PM or a tech lead. From an investor's point of view, a company with a strong board of directors is a company you want to invest in. So it's not as if you don't need a COO. However, when you look at stock option grant rates, COOs are often not paid as much as CFOs or CTOs.

Is it helpful to have someone who doesn't know the technology and can't give direction to the product? I think there are some cases where it is necessary. But not all.

I think engineers can be roughly divided into those who like technology and those who like product development. It is more often the case that the first person who can develop it for any given area A is someone who likes technology. There was a moment during the machine learning boom when student Kagglers were stronger than experienced engineer. There are stories that blockchain entrepreneurs are young.

Google, for example, is an example of a company formed by geeky young engineers + adults, and it is possible that the Scrum Master is a sort of expedient for the formation of these adults. However, as time goes by and geeky young engineers gain experience in their careers. There will be engineers who can be managers. So over time, the COO and Scrum Master necessity declines.

A COO who can fill in for the CEO is welcome, but there's possibility a COO-like career can be a risk if you don't behave well. He or She may become someone who is not quite sure what he or she can do.


In Japanese companies where diversity is low, and programming itself is a relatively flourishing business category, web development companies where the main focus is not on out-of-the-box technology may not need Scrum, especially a full-time Scrum Master.

The Scrum Guide also mentions that ScrumMaster is a concept, but seeing that so many companies have a ScrumMaster who also works as a different role. It would be nice to invent a model that better describes the necessary team topology.