Amoeba, TPS, Scrum and XP

Original

Recently, I've joined the Amoeba Study and Tour to Japan and learned about the Amoeba of Kyocera and the TPS of Toyota. Back when I start to learn agile development, I've heard that that agile development learned a lot from Toyota management. Taking this study tour has provided me with a more direct and intuitive experience of Amoeba management and I made a comparison of Amoeba management, TPS, Scrum, Extreme Programming.

Let's look at some background information first.

Since the invention of computers, computer software has been developed. With software development, there is software project management. The popular project management method earlier was Waterfall. Waterfall has four stages: requirement analysis, framework design, coding, and testing. It is assumed that every stage in a project should be done correctly, so that the work in the next stage can be guaranteed.

The disadvantages of Waterfall is becoming more and more obvious with the ever-changing market. Its cycle is long, and it is difficult to respond to market changes in time, and there is a long wait in the middle of it. For example, a complete waterfall development may take six months or even a few years. During that time, there will be no product to deliver, so other departments, such as the marketing and sales, have to wait, and they will have no feedback from the market. It is likely that the product fails in the market when it is finally launched.

Under such circumstances, many of the predecessors in the software industry have studied and put forward their solutions. In 2001, some of them held a meeting together to present the famous Agile manifesto and the concept of Agile. In Agile, a working software is more important than documentation, and it emphasizes the communication with customers, teamwork, and real-time adaptive planning, instead of following the plan strictly. Among the many schools of Agile, the most famous ones are extreme programming (XP) and Scrum.

Extreme Programming emphasizes the software engineering, which guarantees the quality and the velocity of software development through user stories, pair programming, collective ownership of code, continuous integration, and automated testing. Scrum is more focused on management in a micro way. It specifies what roles in a software development team should do at different stages. Both Extreme Programming and Scrum emphasize delivering runnable software as quickly as possible by Sprints, gathering the feedback from the market and its customers, and then adjusting the in your next step. This approach, which we call iteration, usually takes no more than four weeks, and may be delivered in a week or even a day.

In an iteration, Scrum includes requirements analysis, task breakdown, daily standup meetings, review meetings after the iteration is done, and retrospective meetings. A scrum team, led by a Scrum Master, completes all sessions, and eventually completes all the necessary work of software development and testing, and eventually delivers runnable software.

Most of development teams adopt Scrum and Extreme Programming at the same time. Scrum works as a framework at a macro level, while Extreme Programming guides users how to do coding. At this point, I personally think that there is a similarity between Amoeba management and TPS. Amoeba is about how to manage your business, but it doesn't tell you how to minimize costs and maximize profits which can be done in TPS through a series of tools such as Kanban.

Next, Let's see the similarities of Amoeba, TPS, and Scrum, Extreme Programming.

Amoeba management emphasizes that everyone is a manager and everyone has to bear a sense of management. In Scrum, a self-managed team is of great importance and emphasized. A Scrum team must make decisions for itself, adjust its plans, and deal with problems. In this respect, Amoeba and Scrum are similar in some aspects. They both emphasize the initiatives of team members and improve business operations by mobilizing everyone's enthusiasm.

In terms of organization structure, Amoeba management and Scrum are similar too. The organization structure of Amoeba tends to be flat, and the number of members in each Amoeba is not big. The ideal team size for a Scrum team is no more than ten. Small teams are more flexible, and the communication is more efficient, so it is more likely for team members to improve a sense of achievement.

In terms of operations, Amoeba management request an Amoeba statement from each Amoeba. By calculating the direct expenditure, shared expenditure, external income and internal income, the profit of an Amoeba is worked out, and then the unit time added value of the Amoeba is worked out. Scrum requests the Product Backlog of each iteration (the goal of this iteration), the Burnout Chart (a chart to show the progress of the project), and the velocity (at what speed a Scrum team completes a story point. Meanwhile, a variety of estimates are required, with the estimating props (Scrum Poker).

While studying amoeba in Kyocera, I found that the daily morning meetings and business analysis meetings are similar to daily standup meetings and retrospective meetings in Scrum respectively. Moreover, the regular meeting with openness and cordiality is consistent with the team building in many IT companies.

Amoeba also emphasizes the visual management of a team. A Scrum team use a variety of tools to visualize the progress of the entire team and present it to everyone.

Through the implementation of Amoeba, team members are trained to have a sense of doing business. Scrum also emphasizes the self-management and growth within the team, and many managerial talents will emerge in the doing Scrum.

Toyota TPS reduces waste and delivers quickly through post-process claiming, leveling production, and self-work guarantee. Because I have only a preliminary understanding to Toyota TPS, I can only talk about its similarities to Extreme Programming briefly.

A very important practice in extreme programming is Unit Testing. The smallest units in software are Function. Each function has its own input. It completes certain functions and eventually has its own output. Unit Testing guarantees that the function works properly by writing test cases in various scenarios. For example, a Sum (A, B) function. Parameter A can be positive, negative, decimal, zero, string and so on. Coupled with the Parameter B, there will be a dozen or even dozens of typical scenarios. When we complete this function or make subsequent changes to it, we need to execute all the test cases to make sure that the function will be correct. Even if in abnormal situations, we can still deal with it. This is similar to the self-work guarantee in TPS. In production workshops of Toyota, a variety of detection tools and prompting tools are provided. For example, if the screw is not tightened, the corresponding indicator light will appear. This is a unit test case in programming.

After unit testing, integration testing, system testing, and so on will be performed, which is very similar to a variety of checkups and tests after the assembly of the car is done in Toyota. After the assembly of the car is done, the appearance test, steering wheel test, starting test, and braking test will be done by a particular tester, as well as the test on the various dashboards and so on in high-speed driving state. There are more than 1,500 or more tests for a car in Toyota.

Extreme Programming emphasizes automation. For example, there are various automation testing frameworks to help programmers, when performing unit tests. There are also a variety of tools to help QA, when they do system testing. Automation is also the core of the TPS. In the factory of Toyota, all kinds of automation tools are everywhere. They even created a word in Japanese for it: a character meaning human beings is added to the verb to emphasize the initiatives under the premise of mechanical automation.

In order to reduce the waste, Toyota implemented the post-process claiming. I think that it is similar to test-driven development. Test-driven development is to write codes for a unit test first, and then write a program that can pass the unit test code.

Leveling production and Agile development are similar too. Leveling production is characterized by avoiding mass production and saving mold changing time to achieve overall efficiency. For example, if we do a mass production of Procedure A, staff work in Procedure B will be on hold. The way of mixing AABBCC can guarantee the efficiency of everyone. In Agile development, the design, development, and testing are carried out simultaneously, and it is to provide everyone with concurrency and avoid too much waiting time and waste.

There are four principles of quality assurance in TPS workstations: follow the standard operation, corresponding to code specification in Extreme Programming; Self-inspection, corresponding to self-testing in development; mutual recognition of quality, corresponding to pair programming and mutual measurement in development; and improve to easy-to-operate operations, corresponding to continuous optimization in development.

The all-round worker in TPS and the full stack engineer in software development are completely the same concepts.

TOYOTA Kanban management has been completely adopted in software development.

Whether Amoeba, TPS, Scrum, or Extreme Programming, it is a process of continuous and endless improvement, and endless learning. Written on August 24, 2018 on a tour bus in a hurry, just for your reference.

See also

• Beginners' Guide to Scrum Project Management
• Collective code ownership is an important factor of XP
• Extreme Programming: Planning Game