Abstract: In the Internet era, business and collaboration complexity is increasing day by day, and competition is becoming increasingly fierce. Improving research and development efficiency has become a common challenge for the software industry. “36 Strategies for R&D Efficiency Improvement and Agile Implementation” is a series of courses carefully designed by Aliyun and Teambition. The courses are lectured by He Mian, Zhang Gang, Zhang Liaoyuan and other domestic lean and Agile senior experts with decades of experience in R&D efficiency. Will work from agile projects, agile requirements management, continuous delivery and engineering practice, design and code of practice, five aspects of the business innovation, system for the first time sharing method, analytic alibaba alibaba r&d performance and industry best practice case, and through the tool of visual presentation, help enterprise managers breakthroughs r&d efficiency bottleneck, the road to business success.

“Improving r&d efficiency” is the common goal of product r&d. But where to start? In this course, the second in a series of 36 courses on R&D performance improvement, the two lecturers will share alibaba’s experience — starting from visualizing the end-to-end delivery process and exposing problems to start the road to r&d performance improvement. You will learn:

Visualizations What are the four steps to effective visualization Three criteria for testing visual effects

Note: The following content is the summary of the lecture video. Click the link at the end of the article to go to the course information collection page to view the previous video, PPT and the latest live preview.
I’m sure you’re familiar with visualization. Many Agile teams use physical or electronic kanban for transparency and visualization. As for the effect, there are mixed reviews. Think useful and adhere to many, think is formalism also a lot of people in.

Whether visualization is useful, we think, depends first on: “Visualize what?” .

One. Visualize what? Visualization shines a light on the problem

The story happened in front of a bar, a drunk is looking for something under the street lamp. The policeman watched him silently… Ten minutes passed and the policeman couldn’t resist stepping forward. “What are you looking for? “Asked the policeman; “My keys,” replied the drunk. “Did you leave it here? “Asked the policeman, who took a look but could not find the key. “No,” replied the drunk. “Then why are you looking here?” “Asked the policeman, puzzled. “Only from here,” the drunk replied impatiently.



The key is not where the light shines. In English, “Key” means “Key” or “answer”. Can see the place, but not the “key”, of course, can not find the answer to the need.

Will we make the same mistakes during development? Unfortunately, it’s not only true, it’s very common.



For the development process, it is easy to see whether people are busy or not. We tend to look at the output of each function from a reporting line perspective, such as the efficiency of development, testing, product, etc.

However, problems that lead to the development process, such as integration, quality, schedule alignment, requirements communication, environmental maintenance, and delivery models. The roots of these problems tend to be systemic rather than local. They are not places of light and are therefore easily overlooked.



Problems in product delivery can lead to stagnant demand, which impedes the smooth flow of value and fundamentally undermines r&d effectiveness.

In software product development, the fundamental problem is never stagnant resources (engineers), but stagnant product demand (user value).

This also provides direction for visualization of the r&d process. Visualization of the R&D process is to visualize the end-to-end delivery process of value, allowing us to see the process of value flow, as well as the obstacles, stagnation and problems in the flow process.

The core of visualization is: “Shine a light on the problem.”

Let’s look at an example. Below is a billboard of Alibaba’s new tmall retail team two years ago. The kanban is divided into columns from left to right, each representing a stage. The blue cards on the kanban board are requirements, and they go from left to right through the columns: Select, Design, To Review, to develop, Development design, Development, testing, all the way to release.





As you can see, the “in development” column is wide and divided into several subcolumns, the first of which is called “Requirements” and is used to store requirement cards. The other subcolumns are “front end, Back end, Test, and Dependency,” and the yellow cards in these subcolumns are the subtasks that the requirements are split out from. Once the task is complete, it moves to the last subcolumn, the “Done” column.

Requirements that are “under development” are in line with their subordinate tasks, which we call the “requirements swimlane.” Once all the tasks under a requirement are “complete,” the requirement development is complete and can continue to flow forward to “to be tested,” where tasks can be cleaned or collapsed. Lanes are cleared and ready for the next need to enter.

Through this kanban we can see the flow of requirements, the breaking down of requirements into multiple tasks, and the team working together to complete the task. It helps the team expose and discover problems, facilitating better teamwork to deliver requirements. It lays a foundation for efficient collaboration and smooth flow of value.

The above is a specific example, and the visualizations are certainly different for different teams. How can teams design their own visualizations within their own context? That’s what we’re going to talk about.

How to Visualize — Four steps to achieve effective visualization

To achieve effective visualization in the context of the team. In practice, we summarized four steps.

Step 1: User value driven, identify effective flow units

The first thing we need to do is analyze what the team or organization is delivering to the outside world to identify effective flow units and clarify the subject of the visualization.

The example below is from a real team. They divided the flow units into four types.

  1. Product planning requirements: derived from product design and planning to serve long-term business goals;
  2. Daily needs of users: during the use of the product, the development team should timely respond to daily feedbacks and requirements from users or business parties and schedule development according to the priority;
  3. Technology improvement requirements: requirements for sustainable delivery or technology leadership, such as technology reengineering, development test environment improvement and introduction of key technologies, etc.
  4. Problems and defects: The team must respond to and resolve in real time.




These four types of requirements are the bulk of what the team needs to deliver and are the flow units on the kanban board.

You can analyze and categorize requirements and identify flow units on the kanban board based on your team’s characteristics. On this basis, we can analyze and model the value flow process, which is the second step introduced next.

Step 2: Define the end-to-end value stream





Different colored cards represent different types of requirements. For example, green cards represent user needs and blue cards represent technical improvement needs.

Teams need to analyze and model the process by which requirements flow. Here is an example of a requirement that starts with (being) “selected” and then goes through “analysis”, “review” and “ready” phases. It goes through the “Implemented”, “to test”, “to test to release”, and finally to the “released” phase. This end-to-end process is the value stream of requirements delivery.

The end-to-end value flow process involves different functions such as product design, interactive vision, development, and testing. In order to improve flow efficiency, it is necessary to pull through various functions in the organization and realize the visualization of the whole process.

Some teams are not able to do a full end-to-end pull through immediately due to constraints. Conditions allow, or as far as possible to both ends of the expansion, to achieve true end-to-end agile and lean. This also provides direction for the evolution of the team.

Function before and after the pass is the basis of the fast delivery, in addition, the collaboration within the team also need to pay attention to link, especially the coordination of different roles, such as: before and after the end of the development team’s cooperation, collaboration with external dependencies, etc., it is also promoting one of the most important aspects of the value of rapid flow, this is what we need to discuss about “module alignment”.

Step 3: Align the left and right modules to reflect the task collaboration of the link

The collaboration of tasks within a link, from the point of view of requirements, reflects the decomposition and merger of requirements. A typical example is when requirements are broken up into different tasks during implementation, which are performed by different functions (front-end, back-end, iOS, Android, external dependencies, etc.).





In the “Implementation” phase in the middle of the figure, the requirements represented by the green card are broken down into multiple tasks (the yellow card). These tasks are back-end, iOS development, Android development, and external dependencies. The team’s goal is not to complete more tasks, but to deliver requirements as quickly as possible.

That’s what we’re talking about: left-right module alignment, task alignment to requirements, early delivery of requirements. It encourages teams to collaborate more effectively with requirements delivery as the lead, and helps teams identify bottlenecks that affect requirements delivery.

Identify effective flow units, front and rear functional pull through and left and right module alignment. These three steps make the requirements delivery process visible and instantly expose problems and bottlenecks in the flow.

However, in order for the team to collaborate effectively, we must also build on this and define clear requirements flow rules. This is the fourth step that we are going to introduce.

Step 4: Clear flow rules, enable the team to make local decisions and build in quality

Defining the rules of the flow defines the conditions that must be met for the next phase of the flow of requirements. For example, what criteria are met to move from “ready for review” to “ready”. The team should define clear requirements flow rules and have an agreed understanding.

Clear flow rules help the team achieve built-in quality. The so-called built in quality is to ensure the quality of requirements at each stage effectively, avoid problems in the final stage of the outbreak, and avoid unnecessary rework, which is also the basis of continuous smooth value flow.





How do you define rules? Let’s take the entry rules for the “ready” phase.

For a development team, readiness is their input, and the quality of the input largely determines the quality of the output. There is a saying in the IT industry: “Garbage in,Garbage out” — Garbage goes in,Garbage goes out.

In general, we expect requirements to flow smoothly backward when they are in place, not in stop-and-go mode. The problem has not yet occurred when the requirement enters the ready queue. In project management terms, problems that have not yet occurred should be called risks. Typical examples are: business risk – whether requirements are clear and understood; Associated risk – identifying external dependencies and commitments; Technical risk – The scheme is basically feasible.

The above risks should be considered when defining the entry rules for the ready queue. Hence, the following example. Ready queue access rules:

  1. Development, test, and business work together to clarify requirements and define clear interaction processes and acceptance criteria
  2. The big requirements have been broken down into requirements where the work can be completed and delivered in less than two weeks
  3. Confirmed plans with business affiliates (if any)
  4. Identify major technical risks and define countermeasures
  5. For requirements involving three or more developers, assign coordinators to coordinate schedules
The flow rules are defined above using the “ready” column as an example. Based on similar principles, teams can define flow rules for other segments.

Clearly defined rules should be defined and shared by the team, with an agreed understanding and commitment to them, and based on which the team collaborates and makes decisions. It empowers the team to make better decisions. Equally important, rules are not set in stone; they are an important tool for quality assurance and a baseline for team improvement.

Summary – Basic steps for visualizing value streams





Briefly review the four basic steps for visualizing a value stream. Step 1: Driven by user value, identify effective flow units; Step 2: Before and after the function pull through, define the whole end-to-end value stream; Step 3: Align left and right modules to reflect task collaboration within the link; Step 4: Clearly define flow rules to enable the team to make local quick decisions and ensure built-in quality.





How to ensure visual effect? Three tests for effective visualization





How to design your own visualizations within the team’s own context. Every team can practice, and we believe that many distinctive schemes will be produced.

So how do you determine if the program that you’re producing is effective? Based on my experience in practical implementation, I will present three principles that correspond to three questions.

Question 1: Does it reflect the end-to-end delivery process?

Question 2: Can the bottlenecks and problems affecting the flow of value be reflected in time?

Can teams collaborate and make decisions based on visual information?

Affirmative answers to these three questions have always been my bottom line in designing kanban systems. Facts have also proved that the above three points can lay a very solid foundation for the smooth flow of value. How to make value flow faster is a natural matter, and we’ll talk about that later in the course.

Four,

Don’t be a “drunk under a street lamp” and “shine a light on the problem.” This is the shift in thinking that is necessary in order to visualize effectively. To shine a light on the problem, the subject of the visualization must be the requirements, the flow of requirements, and the problems and bottlenecks in the flow. Based on this appeal, we share four steps and three test criteria for visualization. Hopefully they will help you and your team shine a light on how to improve r&d performance.

This article is by Teambition Developer

The original link

This article is the original content of the cloud habitat community, shall not be reproduced without permission.