“Building an Agile Enterprise”: Agile thinking hates things like “work in progress”, which tie up your production capacity, but can’t provide any value

While Agile’s complex genealogy has at times sparked heated debate among agile practitioners, two things are evident from this brief history of agile. The first point is that the origin and application of Agile have gone far beyond the field of information technology, and have been related to many elements of the organization. The second point is that the level of agile application is still expected to continue to spread. Agile development was originally used to help everyone break free from the shackles of the bureaucratic system—and what Irresistible Dim Sum companies most urgently need at present is the ability to re-find the balance between the bureaucratic system and innovation.

How Agile Teams Work

The way an agile team works is not the same as the bureaucratic system where one order follows one order. Agile is most applicable to innovation activities, that is, applying creativity to improve customer solutions, business processes and technologies for profit.

To take advantage of the opportunity, the organization forms a small team of usually three to nine people, mostly full-time, and empowers them to do it. This team usually has a variety of specializations and will include a variety of skills required to complete the task. It is self-governing and takes responsibility for all aspects of the mission solemnly. Senior leaders tell members where to innovate, but not how to do it. Once a big complex problem is encountered, the team will split the problem into modules one by one, and find a solution for each part of the problem through rapid prototyping and rigorous feedback procedures, and finally solve these Program integration into a seamless overall solution.

The members pay more attention to responding to various changes, rather than sticking to the plan and going on. They will be responsible for all the results (such as growth rate, profitability, and customer loyalty, etc.), not just for the output (such as writing a few lines of code, or launching several new products). products, etc.). Agile teams work closely with customers, whether external or internal. This is tantamount to handing over the responsibility for the innovation results to a group of people closest to customers. Doing so reduces layers of control and approval, thereby speeding up work and boosting team motivation.

Agile techniques are a combination of both thinking and methods. Once a religious war breaks out, although believers will argue whose sect is more important, such behavior is absurd. To survive, is your head more important or your heart more important? You must have both, or you die. Agile is a customer-focused philosophy. Agile practitioners believe that every work activity has its customers. When designing its structure, this work should also revolve around meeting customer needs, and it should be as effective and profitable as possible.

For example, the financial department serves the operating units that provide funds for itself, and these units should also report their satisfaction with financial services to the financial department. So agile teams have this thing called a backlog—basically a prioritized and executed list of to-do items—and it’s organized by customer needs, not by tasks.

Agile thinking hates work in process (WIP). Because it binds your production capacity, but it can’t provide any value. The longer it exists, the more it costs. But customers’ needs are always changing, competitors are also constantly innovating, and products in process will gradually become obsolete. Therefore, Agile prefers a small batch of job cycles that need to be completed within a certain period of time (within one month). Each cycle is called a sprint period (sprint).

However, agile practitioners do not intend to force team members to work harder through a short sprint period. This is different from what some Agile skeptics might think. The purpose of arranging a short sprint period is to encourage agile teams to think about how to quickly build something worth testing. The short-day sprint period also makes it easier for team members to simultaneously promote the longer, slower process and the faster process.

The initiative owner of the team, also known as the product owner, must take the ultimate responsibility for providing value to customers (including internal customers and future users) and business departments. People in this role, usually from the business unit, spend their time working with agile teams and coordinating with key stakeholders, including customers, senior executives, and business managers. Campaign leaders can use techniques such as design thinking or crowdsourcing to build a comprehensive portfolio backlog of opportunities with potential to grow.

Then, the campaign leader must relentlessly and continuously adjust the order of the list based on the value expected to be provided to internal and external customers and the company. The activity leader doesn’t tell each member of the agile team what to do, or how much time each task should take. Instead, the team members had to draw up the streamlined roadmap themselves, and only those activities that would not change anything until execution began were detailed in the plan.

They will split the top-ranked tasks into multiple small modules; decide how many tasks they are responsible for and how to complete them; clearly define what is truly “completed”; and finally start to work on the products of each sprint Create different working versions. There will also be a need for someone to act as a “process facilitator” (usually a trained scrum master) to help guide the process. This person must protect the team from distractions and also assist the team in using their collective intelligence to do things.

All processes are completely transparent. Team members hold short daily coordination meetings to review progress and identify obstacles. If there are disagreements between each other, they should be resolved through experiments and feedback instead of resorting to endless debates or going to the top. For a short period of time, they would test a small working prototype with a few customers, even if it was only partly incomplete. As long as a prototype excites customers, it may be released immediately, even if some senior executives don’t appreciate it, or feel that something needs to be added to it before releasing it. Members then brainstorm ways to improve the next cycle and prepare to move on to the next priority.

Agile offers several major benefits over traditional management, each of which has been studied and documented. Agile can improve team productivity and employee satisfaction. Agile can minimize the waste caused by redundant meetings, repeated planning, excessive submissions, quality defects, and useless product features. By increasing visibility and continuously adapting to changing customer priorities, Agile promotes customer engagement and satisfaction, delivering the most valuable products and features to the market, faster and more predictably , the risk is even lower.

By introducing team members from different professional fields and becoming peers who cooperate with each other, the experience of the whole organization is rapidly expanded, and mutual trust and respect are established. Finally, by greatly reducing the number of departmental projects that consume energy and manage everything, agile allows the company’s senior executives to devote more fully to the more valuable work that only they can do: establishing and adjusting the corporate vision; scheduling strategic actions. Prioritization; streamlining and focusing on work; assigning tasks to the right people; fostering cross-departmental collaboration; and removing barriers to progress.

Agile practitioners are skeptical of managers’ ability to predict, direct, and control innovative solutions. Especially when it is still unclear what to provide and how to provide it. Now for a thought experiment, imagine that you are in charge of developing a self-driving car that can drive from Minnesota to Florida, USA. You have two options:

The first way is to develop a definitive version of the car. You could go out and study all the roads between Minnesota and Florida, predicting all possible sharp turns and turns, traffic light changes, pedestrians or deer crossings, traffic accidents, and weather conditions. Once the car crashes on a test run (as it inevitably does), you’re told to work a little harder and improve your predictive skills. But is putting in more effort guaranteed to solve the problem? The chances are slim. If the car is just driving in a tunnel, maybe this prediction and planning model will work, but in the real world, the road conditions may suddenly become extremely complicated.

A different approach is to program the car to respond to changes in road conditions. First, find out why someone would want to travel from Minnesota to Florida. If the occasional tornadoes make Florida too dangerous, consider rerouting to California. Then, predict what might happen, develop ways to measure those conditions, build sensors to track conditions, and then include ways to appropriately respond to those conditions.

Data from weather centers, traffic monitors, and other drivers is collected and fed to the sensors on the car. “The car is approaching the intersection. Please stop the car at the red light.” If the feedback loop is short and sensitive enough, the transition will be smooth and comfortable, without making people feel abrupt and unpleasant. Agile is to do such a thing, and learn as you go.