"DevOps Practice Guide" - Reading Notes (1)

Part 1 Introduction to DevOps

The three-step approach to DevOps: flow, feedback, and continuous learning and experimentation.

• Flow Principle: It accelerates the process from development, operation and maintenance to delivery to customers.
• Feedback principle: It enables us to build a safer and more reliable work system.
• Principles of continuous learning and experimentation: It creates a culture of high trust and a scientific way of working, and makes organizational improvement and innovation a part of daily work.

Lean movement

The practices of value stream mapping, Kanban, and total production maintenance originated from the Toyota Production System in the 1980s. In 1997, the Lean Enterprise Institute began studying how Lean concepts could be applied to other value streams, such as the service industry and the healthcare industry.

Two main principles of Lean include: the belief that lead time (the time it takes to convert raw materials into finished goods) is one of the best measures of improving quality, customer satisfaction, and employee happiness; and that the delivery of small-batch tasks is the key to shortening the lead time. Setup time is a key factor.

Lean principles focus on how to create value for customers through systemic thinking. The scope of systemic thinking involves establishing lasting goals, embracing scientific thinking, creating flow and pull (rather than push) collaboration models, advocating ensuring quality from the source, and using humility as the basis. Orientation and respect for all individuals in the process.

Agile Manifesto

The Agile Manifesto was jointly proposed by 17 top masters in the software field in 2001. They hope to use a lightweight system of values ​​and principles to optimize those heavy software development processes (such as the traditional waterfall development model) and methodologies (such as the unified software development process).

In the Agile Manifesto, an important principle is " 频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期" and emphasizes the use of small batches of tasks for incremental releases, rather than large-scale jobs and waterfall process releases. At the same time, we emphasize the establishment of self-organized small teams so that members can work happily in an environment of high trust.

In many companies that have implemented agile, productivity has been significantly improved, and agile has gained more and more widespread support and recognition. Interestingly, in the development process of DevOps, several key activities described below all originated from the agile community or agile conferences

1. Agile, continuous delivery and the three-step approach

1.1 Manufacturing value stream

A basic concept in Lean is called value stream . "A series of orderly delivery activities performed by an organization based on customer needs", or "a series of activities required to design, produce and provide products or services to customers. It includes the flow of information and materials Double value”.

The value stream can be seen everywhere in the manufacturing process and it starts with receiving a customer order and sending raw materials to the factory. In order to shorten and predict the lead time in the value stream , it is usually necessary to continuously focus on how to establish a smooth workflow, including reducing batch size, reducing the number of work in process (WIP), avoiding rework, etc., while also It is necessary to ensure that defective products are not passed to downstream work centers and to continuously optimize the entire system based on global goals.

1.2 Technology value stream

“Translate business ideas into the processes required to deliver valuable, technology-driven services to customers”

The inputs to the process are given 业务目标, 概念, 创意and 假设, starting with the R&D department accepting work and adding it to the work-to-be-done list.

All work only generates value if the application or service runs as expected in a production environment and provides services to customers.

1.2.1 Focus on deployment lead time

Deployment lead time is a subset of the value stream.

The value stream begins when engineers (including development, QA, IT operations, and information security personnel) commit a change to the version control system and ends when the change successfully runs in the production environment , provides value to customers, and generates effective feedback and monitoring information.

• In the first stage, the work mainly includes design and development, which has many similarities with lean product development: both have a high degree of variability and uncertainty, not only require creativity, but some work may not be repeated. This makes it impossible to determine the overall processing time.
• In the second phase, the work mainly consists of testing and operations, which is similar to lean manufacturing. Compared with the previous stage, it requires creativity and professional skills, strives for predictability and automation, minimizes variability (such as short and predictable lead times, close to zero defects), and meets business goals.

We do not advocate completing large batches of work serially in design and development, and then moving to the testing and operation and maintenance stages (such as using large batches, a development process based on the waterfall model, and working on feature branches with long life cycles). ). Quite the contrary, the goal is to adopt a model where test and operations are synchronized with design and development, resulting in faster value flow and higher quality. This synchronized model can only be achieved when work is done in small batches and quality is built into every part of the value stream.

1. Defining lead time and processing time
   In the Lean community, 前置时间lead time and processing 处理时间time (sometimes called contact time or task time) are two common metrics for measuring value stream performance.

   • The lead time starts after the work order is created and ends when the work is completed;
   • The processing time starts when the job is actually processed. It does not include the time the job is waiting in the queue.

   

2. Common Scenario: Deployment Lead Time of Months
   Typically, deployment lead time can take several months. Once the deployment lead time becomes long, almost every stage of the value stream will require “hole filling” experts to remedy the situation. Often,
   it is likely that it is only after the development team's changes have been merged before the end of the project that it is discovered that the entire system does not work properly at all, and sometimes the code even fails to compile and test. Each issue can take days or even weeks to locate and fix, resulting in an extremely poor customer experience.

3. Our goal: a deployment lead time of minutes.
   We can achieve this goal by continuously submitting small batches of code changes to the version control system , doing automated testing and exploratory testing of the code, and then deploying it. to the production environment. This way, we can maintain a high degree of confidence that code changes will run successfully in production, while also quickly identifying and fixing problems that may arise.

   In order to more easily achieve the above goals, it is also necessary to optimize the architectural design through modularity, high cohesion, and low coupling to help small teams work autonomously. In this way, even if it fails, it will be within control and will not have an impact on the overall situation.
   

1.2.2 Pay attention to the rework indicator - %C/A

In addition to lead time and processing time, the third key metric in the technology value stream is time to completion and precise percentage of total time spent ( %C/A). This metric reflects the quality of output at each step in the value stream

"To capture this %C/A, ask your downstream customers what percentage of the time they receive ' truly useful work ', i.e. they can focus on doing useful work rather than having to fix error messages, supplement information, or clarify what should be information."

1.3 Three-step working method: basic principles of DevOps

three step method

• The first step is to realize the rapid flow of work from development to operation and maintenance from left to right.
  To maximize workflow optimization, you need to visualize work, reduce batch sizes and wait intervals, eliminate defects from being passed downstream through built-in quality, and continuously optimize global goals.

  Relevant practices include continuous build, integration, testing and deployment, setting up environments on demand, limiting the number of WIPs, and building systems and organizations that can safely implement changes.

• The second step is to apply a continuous and rapid work feedback mechanism in each stage from right to left.
  This method prevents the recurrence of problems by amplifying the feedback loop, shortens the problem detection cycle, and enables rapid repair.

  This way we control quality from the source and embed relevant knowledge into the process. Not only does this create a safer working system, it also allows catastrophic incidents to be detected and resolved before they occur.

• The third step is to establish a creative and high-credibility corporate culture that supports dynamic, rigorous, and scientific experiments.
  By proactively taking risks, you can learn not only from success but also from failure.

  By continuously shortening and amplifying feedback loops, you not only create safer work systems, but you also take more risks and conduct experiments to help you improve faster than your competitors and beat them in the marketplace.

As part of the third step, we are able to make the working system do more with less, turning local optimization into global optimization. In addition, no matter who is involved in the work, all experience can be continuously accumulated, and people in the organization can learn from each other's experience and wisdom.

2. Step One: Flow Principle

In the technology value stream, work typically flows from developers to operations, that is, all functions between the business and customers.

The first step of the work method to be described in this chapter is to establish a fast and smooth workflow from development to operation and maintenance that can deliver value to customers. It is necessary to optimize for this global goal, rather than focusing on a series of local goals, such as the completion of functional development, the discovery and correction rate of problems in testing, the availability of operation and maintenance, etc.

Enhanced flow through continuous increased visibility into work content, reduced batch sizes and wait intervals, and built-in quality to prevent defects from being passed downstream. By accelerating the flow of technology value streams, we can shorten the lead time to meet the needs of internal and external customers, further improve the quality of our work, and make us more agile and better than our competitors.

Our goal is to improve the quality and reliability of our services while shortening the time it takes for code to go live in production. In fact, we can find clues about value stream applications in the manufacturing industry that help us apply lean principles to technology value streams.

2.1 Make work visible

• The work content in the technology industry is invisible, which is a significant difference compared to the manufacturing value stream.
• The flow of technical work can be accomplished with a single mouse click, such as reassigning a work order to another team. Because the click operation is too easy, different teams may "kick work" around due to incomplete information, and existing problems will also be passed to downstream processes, and these problems are completely undetectable until they cannot meet the deadline. Product is delivered to customers, or the application breaks down in production.

In order to be able to identify where work is flowing, queued or stalled, work needs to be visualized as much as possible . 可视化工作板It is a better way of working, such as using paper or electronic cards to display various tasks on a Kanban board or Sprint planning board.

Ideally, a Kanban board should cover the entire value stream; work is only completed when it reaches the far right side of the Kanban board. Completing the development of a certain function cannot be considered "completed". It can only be considered "completed" when the application successfully runs in the production environment and begins to provide value to customers.

By putting all the work in each work center into a queue and displaying it visually, it is easier for stakeholders to prioritize each work based on the overall goal. In this way, each work center can adopt a single-task processing method, starting with the highest priority task and completing all the work in order to increase the throughput of the work center.

2.2 Limit the number of products

Technical work is often dynamic—especially where shared services exist, and teams must meet the needs of many stakeholders simultaneously, leading to ad hoc arrangements that control day-to-day work .

Tech workers are easily interrupted because the consequences of this disruption appear invisible to everyone, even if it impacts productivity more than in manufacturing. For example, if an engineer is assigned to multiple projects at the same time, he will have to switch back and forth between multiple tasks, cognitive rules, and goals, paying the cost of re-entering the role.

When using Kanban boards to manage work, you can limit the occurrence of multitasking. By limiting the number of artifacts, you can also more easily identify obstacles in your work.

2.3 Reduce batch size

In Lean, an important lesson is that in order to reduce lead times and improve deliverable quality, small batches should be continuously pursued . Theoretically, the minimum batch size is 单件流that in which only one unit of product is processed per operation.

"Classic case of simulated mailing of brochures"
This example assumes that 10 brochures are to be mailed. Before mailing, each brochure must go through 4 steps: folding, inserting envelopes, sealing envelopes, and stamping.

If using a high-volume strategy (i.e. "mass production"), we will perform the above 4 steps in sequence for each brochure. In other words, first fold all 10 pieces of paper, then insert each piece of paper into an envelope, then seal all the envelopes, and finally stamp them all.

A low-batch strategy (i.e., "single-piece flow") in which all required steps are performed sequentially for each brochure before starting on the next brochure. In other words, you fold a piece of paper, insert it into an envelope, seal the envelope, and stamp it; then, remove a piece of paper and repeat the process.

The difference between adopting a high-volume and low-volume strategy is huge. Suppose that the above 4 steps must be taken for all 10 envelopes, and each step takes 10 seconds. If you use a large batch policy of 5, it takes 310 seconds to complete the first stamped envelope.

To make matters worse, suppose we find that the first step of folding is wrong during the envelope sealing operation (assuming that it can only be discovered when sealing), in this case, the earliest time we can find the error is after 200 seconds , then we would have to refold and put the 10 booklets in this batch back into the envelopes.
In contrast, when using the small batch strategy, it only takes 40 seconds to complete the production of the first stamped letter, which is 8 times faster than the large batch strategy. If you get the first step wrong, just rework a brochure. Smaller batches produce less work-in-progress, lead times are shorter, errors are detected faster, and rework is reduced.

2.4 Reduce the number of handovers

In the technology value stream, if deployment lead times are measured in months, it is often because deploying code from a version control system to production requires hundreds or even thousands of operations. In fact, in the process of code value flow, it requires the collaboration of various departments to complete related tasks, including functional testing, integration testing, environment setup, server configuration, storage management, network, load balancing equipment, information security reinforcement, etc.

When a piece of work is handed off between teams, it requires a lot of communication—requesting, delegating, notifying, coordinating, and often prioritizing, scheduling, deconflicting, testing, and validating.

To reduce these problems, either work to reduce the number of handoffs, automate most operations, or restructure the organization so that teams can independently deliver value to customers without relying on others. Therefore, increase liquidity by reducing waiting time in queues and time spent on non-value-added work

2.5 Continuously identify and improve constraint points

In order to shorten lead time and improve throughput, we need to continuously identify constraint points in the system and improve work productivity.

"In any value stream, there is always a flow direction and a constraint point. Any optimization that is not aimed at this constraint point is an illusion."

• If we optimize the work center before the constraint point, then work will be backlogged faster at this constraint point.
• On the contrary, if the work center after the constraint point is optimized, it will also be in a hungry state, waiting for the end of the work at the constraint point.

solution:

• Identify system constraint points;
• Decide how to exploit this system constraint point;
• Based on the above decisions, consider the overall situation;
• Improve system constraints;
• If the constraint point has been exceeded, go back to the first step, but avoid system constraints caused by inertia.

During the DevOps transformation process, if you want to shorten the lead time from months or quarters to minutes, you generally need to optimize the following constraint points in sequence.

• Environment Setup
  If setting up a production or test environment always takes weeks or months, on-demand deployment is not possible. The solution is to establish a fully self-service environment on demand to ensure that the team can automatically create the environment when it needs it.
• Code Deployment
  If code takes weeks or longer to deploy (for example, each deployment requires 1,300 manual, error-prone operations and involves up to 300 engineers), then it cannot be deployed on demand. The solution is to automate the deployment process as much as possible so that any developer can automate deployment on demand .
• Test Preparation and Execution
  If each code deployment takes two weeks to prepare the test environment and configure the data set, and it takes another four weeks to manually perform all regression tests, then on-demand deployment is not possible. The solution is to automate testing so that the speed of testing can keep up with the speed of code development while deploying safely and in parallel.
• Tightly coupled architecture
  If the architecture is tightly coupled, on-demand deployment is not possible because every time a code change is made, the engineer has to obtain permission from the change review board to implement the change. The solution is to create loosely coupled architectures so developers can make changes safely and autonomously, increasing productivity

2.6 Eliminate dilemmas and waste in the value stream

A common definition of waste in Lean is “ the act of using any materials or resources that exceed what the customer needs and what they are willing to pay for .”

Waste and distress are the main factors causing delivery delays in the software development process. Some types:

• Work-in-progress: It refers to any work in the value stream that has not yet been completely completed (for example, requirements documents or change orders that have not yet been reviewed) or work in the queue (such as work orders waiting for QA review or server administrator review). Partially completed work gradually expires and eventually loses value over time.
• Extra work: Extra work performed during the delivery process that does not add value to the customer. This may include documents that are never used in downstream work centers, or reviews or approvals of output results that do not add value. Additional processes not only increase the workload of processing, but also increase lead time
• Extras: Those features built into the delivery process that are simply not required by the organization or the customer (e.g., “gold-plated”). Additional functionality increases the complexity and effort of functional testing and management.
• Task switching: When people are assigned to multiple projects and value streams, they need to context switch and manage dependencies between work, which consumes additional work and time in the value stream.
• Waiting: Waiting between jobs due to competition for resources increases cycle time and delays the delivery of value to customers.
• Movement: The amount of work that moves information or data between work centers. For example, in a project that requires frequent communication, team members do not actually work together and cannot sit together to collaborate closely. At this time, the waste of personnel movement occurs. In addition, work handovers can also create a waste of movement, requiring additional communication to clarify any ambiguous parts.
• Defect: An error, incompleteness, or ambiguity in information, materials, or products that requires a certain amount of effort to confirm. The longer the time between the occurrence of a defect and its detection, the more difficult it is to resolve the problem.
• Non-standard or manual work: Non-standard or manual work that requires reliance on others, such as using servers, test environments and configurations that cannot be automated and rebuilt repeatedly. Ideally, anything that relies on operations teams to do it manually should be configured to be automated, on-demand, or self-service.
• Pit-filler: In order to achieve the goals of the organization, some people and teams have to be put into unreasonable situations. This may even become their daily routine (for example, an accident occurs in the production environment at two o'clock in the middle of the night, and hundreds of software versions are submitted overnight. work order)

Our goal is to visualize these wastes and dilemmas (anywhere a gap filler is needed) and systematically make improvements to reduce or eliminate these burdens to achieve the goal of rapid flow.

2.7 Summary

Improving the fluidity of technology value streams is critical to implementing DevOps. To do this, we need to visualize work, limit work-in-progress, reduce batch sizes, reduce the number of handovers, continuously identify and improve constraint points, and eliminate daily work dilemmas.

3. Step Two: Feedback Principle

The first step method of work describes the principle (the flow principle) that enables work to flow quickly from left to right in the value stream.
The principles described in the second step work method (feedback principle) enable rapid and continuous work feedback to be obtained at each stage from right to left.
Our aim is to create safe and reliable working systems

3.1 Work safely in complex systems

An important characteristic of complex systems is the inability to view the system as a whole and understand how the various parts fit together. The components of complex systems are usually tightly coupled and closely related. The behavior of the system cannot be explained solely based on the behavior of the components.

Failures in complex systems exist and are inevitable. Therefore, whether in manufacturing or information technology, we must design a safe work system that allows employees to perform their work without fear and ensures that catastrophic consequences such as personal injury, product defects or negative customer impact are avoided as early as possible. ), errors can be quickly detected before they occur

We may not be able to design an absolutely secure system, but we can make complex systems work more securely by taking the following four measures:

• Manage complex work to identify design and operational problems;
• Work together to solve problems and quickly build new knowledge;
• Apply new regional knowledge to the global context across the organization;
• Leaders must continue to cultivate people with the above talents.

3.2 Find problems in time

In a safe work system, we continually validate designs and assumptions . The goal is to increase the information flow of the system earlier, faster, at the lowest possible cost, from as many dimensions as possible, and to determine the causes and consequences of the problem as clearly as possible. The more assumptions we can rule out, the faster we can identify and solve problems, increasing our resilience, agility, and ability to learn and innovate.

We do this by building in the working system 反馈and前馈回路

In high-performance manufacturing operations, there is fast, frequent, and high-quality information flow throughout the value stream—each process operation is measured and monitored, and any defects or serious deviations can be quickly discovered and dealt with. These are the basis for ensuring quality, safety and continuous learning and improvement.

Our goal should be to establish rapid feedback and feedforward loops as all work is performed at every stage of the technology value stream, including product management, development, QA, information security, and operations. This includes creating automated build, integration, and testing processes to detect code changes as early as possible that may lead to defects.

We also need to establish a comprehensive monitoring system to monitor the running status of service components in the production environment to quickly detect unexpected service situations. The monitoring system can also help us measure whether we deviate from expected goals and radiate the monitoring results to the entire value stream, so that we can see how our actions affect other parts of the system.

3.3 Work together to overcome problems and gain new knowledge

Clearly, simply detecting the occurrence of an accident is not enough. Once a problem occurs, we must work together and mobilize all relevant personnel to solve the problem.

Doing so gives everyone involved a deeper understanding of how to manage the system, turning the inevitable early stages of ignorance into a learning process.

The reasons for teamwork are as follows:

• Prevent problems from being brought into downstream processing links, otherwise not only will the cost and workload of repairs increase exponentially, but you will also incur technical debt;
• Prevent work centers from starting new jobs, which could introduce new errors into the system;
• If the problem is not resolved, the work center may encounter the same problem during the next operation, requiring higher repair costs.

3.4 Ensure quality at the source

Examples of ineffective quality control include:

• Other teams are required to help complete a series of tedious, error-prone, and manual tasks that should be automated by the requester themselves.
• Requiring approval from people who are far away from the actual workplace and busy with official duties, forcing them to make decisions without understanding the work situation and potential impact, or with just a routine stamp of approval.
• Writing large amounts of documentation that contains questionable details and becomes out of date shortly after being written.
• Push a large amount of work to the operation and maintenance team and expert committee members for approval and processing, and then wait for a reply.

In daily work, we need everyone in the value stream to identify and solve problems in their areas of control. In this way, quality control, safety responsibility and decision-making can be placed in the context of the work being done, rather than relying on peripheral approval from senior managers.

3.5 Optimized for downstream work centers

Lean defines that we must design for two types of customers: external customers (those most likely to pay for the services we provide) and internal customers (those immediately following us to receive and process work). According to Lean principles, our most important customers are our downstream customers. Optimizing our work for them requires us to empathize with their problems to better identify design issues that hinder fast and smooth flow.

In the technology value stream, we optimize downstream work centers by designing for operations, including non-functional requirements for operations (such as architecture, performance, stability, testability, configurability, and security) and User functionality is equally important.

3.6 Summary

Establishing a rapid feedback mechanism is crucial to achieving high quality, reliability and security in the technology value stream. To do this, we need to identify problems when they occur, work together to solve problems and build new knowledge, control quality at the source, and continuously optimize for downstream work centers.

4. Step Three: Continuous Learning and Experimentation Principles

The first step is to establish a workflow from left to right (flow principle).
The second step is to establish fast and continuous feedback from right to left (feedback principle).
The third step is to establish a culture of continuous learning and experimentation (continuous learning and Experimental principles)

By applying the three-step work method, personal skills can be continuously improved, which can then be transformed into an asset for the team and the organization.

At the core of the technology value stream is building a culture of high trust. It emphasizes that everyone is a continuous learner and must take risks in daily work; improve processes and develop products through scientific methods, and accumulate lessons from successes and failures to identify valuable ideas and abandon useless ideas. In addition, all local experiences will be quickly transformed into global improvements, thereby helping the entire organization try and practice new technologies.

Further promote and safeguard learning by setting aside time for daily improvements. Continuous improvement is reinforced by continually putting pressure on the system. Under controllable circumstances, we even enhance resilience by simulating or injecting faults in the production environment.

4.1 Establish a learning organization and safety culture

In the technology value stream, by striving to create safe work systems, we can build the foundation of a vibrant culture. When accidents and failures occur, focus on how to redesign the system to prevent recurrence, rather than pursuing human problems.

4.2 Institutionalize improvements in daily work

In the technology value stream, in order to prevent catastrophic accidents, teams are stuck in implementing various temporary solutions, but there is no time to complete those valuable tasks. Therefore, ad hoc solutions to problems often lead to the accumulation of problems and technical debt.

Improve your daily work by explicitly setting aside time to pay down technical debt, fix bugs, refactor, and optimize your code and environment. You can set aside a period of time during each development cycle, or schedule a kaizen blitze period, where engineers can form their own teams to solve problems that interest them.

For the technology value stream, making working systems more secure can also help identify and address potential risks. For example, we might start with a non-blame post-mortem investigation of an incident that impacted customer service, and over time we will gradually identify other potential risks.

4.3 Transform local findings into global optimization

NR is world-famous for its adherence to standardized processes, and any process or operational deviations require a fault report to be written in order to accumulate experience. Regardless of the strength of the failure signal or the level of risk, process and system designs are continually updated based on these experiences.

In the technical value stream, we should also establish a global knowledge base through a similar mechanism. For example, convert all incident reports into a searchable knowledge base so that teams in need can more easily use it to solve similar problems, while establishing an organizational-level shared source code base so that everyone can easily use it across the entire organization. code, libraries and configuration. These mechanisms help transform individual expertise into collective wisdom that serves more members.

4.4 Inject flexibility into daily work

High-performing organizations achieve or achieve better results by improving daily operations, continuously introducing tension to improve productivity, and injecting greater flexibility into the system.

Through continuous experimentation in their daily work, they are able to continuously increase production capacity without adding any new equipment or personnel. Introducing this type of improvement not only increases productivity but also increases resilience, as organizations are always in a state of tension and change.

In the technical value stream, shortening the lead time of deployment, improving test coverage, shortening test execution time, and even decoupling the architecture when necessary are all practices that introduce similar tensions in the system and can also improve developers' productivity. Production efficiency and reliability

4.5 Leadership strengthens learning culture

Leaders and frontline workers have a complementary working relationship and must respect each other. This relationship is necessary because no one can solve the problem alone—the leader will not
personally do the front-line work required to solve the problem, and the front-line workers will not understand the larger organizational environment or have the skills to do it outside their work area. the power to change.

Guided by these strategic goals, we establish short-term goals for nested iterations, and then set goal conditions at the value stream or work center level (such as reducing lead time by 10% in the next two weeks) to achieve these goals. These goal conditions form the framework of a scientific experiment: a clear description of the problem to be solved, the assumptions made about the solution, the methods to test the assumptions, the interpretation of the results, and how to use the experience to proceed to the next iteration.

Leaders can use the following questions to help and coach experimenters:

• What did you do in the previous step? what happened?
• What did you learn from this?
• What is the current situation?
• What is the next target condition?
• What are the obstacles to your current job?
• What’s next?
• What is the desired outcome?
• When can a review be conducted?

The way leaders help frontline workers identify and solve problems in their daily work is actually the core of the Toyota Production System, as well as the core of learning organizations, improvement routines, and high-reliability organizations.

In the technology value stream, this method of experimentation and iterative improvement not only guides us to improve internal processes, but also guides us to continuously conduct experiments to ensure that the products we build can bring value to internal and external customers.

4.6 Summary

The third step principle of the three-step working method achieves a learning organization, achieves a high level of trust and cross-departmental cooperation between functional departments, accepts the fact that "failures will always occur in complex systems", and encourages talking about any problems to establish A safe system of work. It also requires institutionalizing improvements in daily work, transforming local results into knowledge that can be used and learned by the entire organization as a whole, and constantly injecting tension into daily work.

While cultivating a culture of continuous learning and experimentation is a third-step principle, it is inseparable from the working methods of steps one and two. In other words, achieving a rapid flow of work and rapid and continuous feedback requires the use of iterative and experimental methods, including establishing target conditions, describing the envisioned solution, designing and conducting experiments, and evaluating the results.

The result of this third step is not only high performance, but also increased resilience, employee job satisfaction, and organizational adaptability.