The development structure here refers to the roles of the members that make up the development team and the development process.
First, why is it necessary to change the development structure in order to increase software development productivity? As of 2012, there were more than 70,000 SCRUM MASTERs in the U.S., compared to less than 4,000 in China and a little more than 100 in Japan. See: [https://www.ipa.go.jp/files/000004634.pdf]. It is becoming more difficult for historical Japanese firms to implement SCRUM. At the time of this writing, the number of Japanese acquisitions is likely to remain low, although the number of Japanese acquisitions is likely to be growing rapidly.
(Supplement) Agile development is common in software development for start-ups and growing companies in Japan, and many companies have adopted SCRUM. The problem is that its adoption has been slow in historical manufacturing companies with high market capitalization in Japan.
The problem is not that Japanese engineers are not aware of Agile and DevOps, but rather that they are unable to change their development systems and thus cannot implement Agile within their organizations.
Then, as to why the development system has not changed, the author believes it is because many engineers have given up or become frustrated because of the time and effort required to explain the change within the company. It is difficult to explain the change in the development system. It may seem strange for non-Japanese companies, but I think that managers in Japanese companies go through the following mindset.
- Subordinates or individual managers feel the need to introduce SCRUM.
- Summarize the differences from the current development process and explain them to stakeholders. At this time, if you are a department that develops cloud-based BtoC tools, it is somewhat easier because you only need to explain to internal stakeholders. In this case, the items that need to be explained are as follows.
- Quality
- Cost
- Delivery date
- Explanation of quality: At the beginning of the project, it may be possible to explain that the quality is the same. Agile can be explained as higher quality because it can receive feedback from the customer more quickly. However, at this time, there is a sense of resistance within the company to releasing an incomplete product, whereas in the past, a fully working product was released.
- Explanation of costs: It is difficult to estimate costs at the same level for sequential and agile projects because the cost estimation methods are different. In addition, it is difficult to explain the increase in initial investment costs when a new PJ method is used for development.
- Explanation of delivery time: As with costs, it is difficult to explain the difference in goal setting between sequential and agile projects.
- As a result, the company gives up implementing SCRUM because it is unable to explain the cost effectiveness and the delivery time.
- (Hypothetically) Although SCRUM is introduced, there is an increase in defects or miscommunication in the early stages of the PJ, and the old PJ process is reverted to.
It is similar to the so-called “big company disease” of not being able to change the prescribed rules. Unfortunately, the only way to introduce Agile is either to implement it top-down with some cost increase, or to introduce it in a new PJ that requires no explanation.
Many historical Japanese companies often continue development by changing the predecessor PJ, etc., making it difficult to change from a sequential project to an agile project.
(So what to do?)
However, if there are engineers who are worried about the cost and are unable to implement the system, I would like to give them two pieces of advice.
- Introduce test automation from the early stage of PJ and set up HIL (hardware in the loop) at the same time as hardware specifications are finalized. In my experience, it always pays off. One of the stumbling blocks of SCRUM is the implementation of tests within a sprint, and automated tests are indispensable to achieve this. I have never seen a PJ with zero defects. The same is true for waterfall projects, where testing and defect correction are repeated at the end of the PJ, but because it is at the end of the PJ, there is often not enough time for automated testing in waterfall projects. The cost of repeating manual testing at the end of a waterfall project is similar to the cost of setting up automated testing from the beginning of a PJ in a SCRUM project.
- Software projects tend to grow to their budget limits as long as the budget is available. If both projects grow to their budget limits, the development cost will be the same regardless of the development method used, and if SCRUM can always achieve the goal of releasing working software, then SCRUM will be more cost effective in that it is easier to cut the PJs. If a user who has never implemented SCRUM in the past is asked by your supervisor for the PJ cost under SCRUM, you should indicate the same amount as for a waterfall project and try to implement SCRUM.
If there are Japanese engineers who want to try Agile but cannot start, please try to persuade them again. I hope to share some strategies for persuasion on this page.
In the next post, I would like to describe automated testing in embedded systems.
