Product-Oriented Delivery - Alibaba DevOps Practice Guide Part 6

This article is from Alibaba DevOps Practice Guide written by Alibaba Cloud Yunxiao Team

The development of IT is the approaching and integrating process of technologies and business. The delivery modes of IT need to be evolved accordingly.

At first, IT was the work of professional companies and professionals. IT developed what the business used. Later, IT companies moved closer to the business, generating more interaction and co-creation with customers, and many business companies also had their own IT development departments. However, even within the organization, IT was also the cost center, playing the role of Party B. At this time, IT was separated from the business, and most IT delivery is in the form of projects.

The core of the project is to deliver the pre-specified content within a specific time using a relatively certain budget and workforce. The project pursues certainty and focuses on planning and plan execution. In an era when IT was separated from business, both sides were benefited by drawing a clear boundary. Correspondingly, the organization can also plan, allocate, and execute IT budgets in advance by projects, which were usually in annual or at least quarterly units.

In the digital age, IT has become a part of business. Planning and delivery through projects are increasingly inadequate to meet the need for a timely response to daily business. One-time project delivery is not conducive to the long-term accumulation and optimization of assets, especially software assets, and the continuous optimization of engineering capabilities and infrastructure.

The preceding figure shows the differences between project-oriented delivery mode and product-oriented delivery mode. During the implementation of DevOps, we advocate adopting the product-oriented delivery mode as much as possible.

In the product-oriented delivery mode, organizations should regard the Technical Delivery Team as a profit center rather than a cost center. Organizations build cross-functional and relatively stable product delivery teams for products and services, measuring and motivating product delivery teams by business value and business response. Based on business value, product delivery teams continuously upgrade, learn, and accumulate software assets, engineering assets, and technical assets to improve response and delivery capabilities.

Focus on Long-Term Efficiency and Business Value

In the product-oriented delivery mode, products are responsible for long-term business results. Accordingly, the standards that measure the product delivery teams should support the effectiveness and efficiency of the business. We divide the goal of product development into three categories:

1. Businesses that serve the current situation directly: This type of goal is easy to understand, and the technology value is reflected as direct business results. Product requirements usually come from specific customer demands or business plans. Here are some typical examples:

Build a new customer service delivery process to improve the efficiency of user delivery
Support content-sensitive caching and routing modes to improve the video viewing experience and reduce bandwidth consumption

2. Product layout for future situations: This type of goal does not serve the current business directly. It is based on the judgment of the future business and technical direction to make layouts in advance. For example:

Based on the prediction of future business growth, upgrade the distributed architecture in advance
Make pre-research and technical preparations for the IoT strategy. This type of goal is business-driven, but the business is a future business.

3. Improvement of the delivery efficiency and effectiveness: In addition to the product delivery itself, the team is also responsible for delivery effectiveness, including the response speed of business requirements, delivery quality, and innovation effectiveness. For example:

Deliver business requirements in a shorter time and with a smaller workload through platform-based capabilities or the construction of business middle platforms
Establish system integration and quality assurance systems through the construction of engineering capabilities

Unlike the project-oriented delivery mode, a Product Delivery Team is not measured by a one-time delivery but long-term business value and efficiency. It is the synthesis of the three goals above. When setting the goals of the Product Delivery Team, we also need to follow these three categories. For example, the team's objective key results (OKR), a method of goal setting and management, should be expanded and set from these three aspects.

Distribute the Work to a Relatively Stable and Multi-Functional Team

In terms of personnel management, the project manager makes the plan based on budget and scope and then assigns personnel to the project. At the end of the project, personnel are released and ready to move on to the next project. In this mode, people are regarded as alternative resources. The workforce allocation for projects has its advantages for businesses that require high certainty and low response speed, especially in increasing the use efficiency of personnel.

In the digital age, the business uncertainty is increasing, while the requirements for IT response speed and continuous healthy evolution of products are getting higher. The team formation mode in project management causes the following problems:

Each time, a project should determine content first and then go through the process of planning making and team formation. Therefore, the response to the demand and the delivery time is prolonged, which cannot meet the needs of immediate response to the business.
The Project Team is temporarily built and is only responsible for short-term delivery. Therefore, it is difficult to ensure long-term business results, and it is the business party responsible for the long-term product evolution and continuous delivery efficiency.

From Assigning People to Things to Giving Things to the Team

In DevOps implementation, we advocate product-oriented delivery. In terms of the team organization, its core change is from assigning people to things to giving things to the team. A more detailed description says the project-oriented delivery mode takes people as alternative resources and allocates them to things in a predetermined scope. For product-oriented delivery mode, it assigns things (dynamically generated product requirements) to cross-functional delivery teams. There are the two core changes:

How requirements are handled: In the project-oriented delivery mode, the scope of a project is determined in advance and in batches. Business changes cannot be responded to immediately or flexibly. In the product-oriented delivery mode, it should respond to business inputs, conduct iterative business planning, and deliver value streams through the needs of different optimization teams to achieve continuous and rapid demand delivery.
How teams are organized: The product delivery team is relatively stable and responsible for long-term product evolution, delivery efficiency, and business contribution. To this end, the team should be:
- Cross-functional, including product, development, testing, and other functions: This is the only way we can directly face the business, complete the delivery of product requirements, and collectively improve the delivery efficiency.
- Fully Authorized: For example, they are authorized to evolve their collaboration approaches, technologies, and engineering practices when meeting the needs of external businesses.
- Relatively stable for a long time: Only long-term teams can be responsible for long-term results.

In the product-oriented delivery mode, the Product Delivery Team is the core of the organization. It is cross-functional, fully authorized, and relatively stable. Long-term effectiveness is the core concern of the Product Delivery Team. It relies heavily on the evolution of the product and the construction of engineering capabilities.

Accumulate High-Quality Software Assets and Team Engineering Technique Capabilities Continuously

Ideally, the basic functions provided by the product will become more complete as product development evolves. More atomic functions are encapsulated as software interfaces and services, becoming reusable components. In this condition, the cost of meeting new business requirements should be lower. However, in many cases, the situation is the opposite. With the evolution of technology development, the complexity of the software is getting higher, the scalability and maintainability are getting worse, and the team's response to the business is getting slower.

Reduce Debts and Accumulate High-Quality Assets

The figure above reflects two trends of efficiency over time. Whether efficiency will continue to increase or decrease depends on whether we are accumulating assets or debts in the development process.

Assets refer to things accumulated today that will benefit the future. In the IT product delivery, good assets mainly include software assets, engineering assets, and organization assets. The following are common examples:

Rich and well-designed atomic services
Domain models that continue to approach the business essence and provide continuous evolution capabilities
Well-maintained and test-guarded design and coding consistent with the models in a conceptual domain
Good engineering practices and quality assurance systems, such as continuous delivery pipeline and quality assurance body based on continuous delivery pipeline
Good team organizing methods, cooperation mechanisms, and practices

Debts refer to things caused today that will be paid in the future. In the IT product delivery, the following are common debts:

The poor interface and service design lead to trouble in the reuse process.
The increasing software complexity and poor design make it difficult to scale out and maintain.
The lack of effective test-guarded code leads to increasing the workload of regression testing and software quality degradation.
The expansion of organization size and the increase of coordination complexity
The lack of an effective engineering practice leads to the increase of system integration and verification costs with unguaranteed quality.

The attitude towards assets and debts is an important factor in distinguishing between excellent and bad teams. An excellent product delivery team should continuously accumulate assets and eliminate accumulated debts. However, what we are talking about here is not 100% debt avoidance. In special circumstances, such as responding to urgent business demands, it is inevitable to introduce debts. However, it must be a conscious trade-off, and the debts introduced should be eliminated in the future.

Only by accumulating assets continuously and avoiding and eliminating debts can the delivery efficiency be continuously improved, the response capability of products to businesses be improved, and the business value of products be enhanced.

The Fit between Business-Driven Collaboration and Product-Oriented Delivery

IT collaboration modes and delivery modes need to evolve to adapt to the requirements of embracing uncertainty and continuous innovation in digitalization. We advocate and practice the business-driven collaboration mode and the product-oriented delivery mode. The two fit naturally and can be connected seamlessly.

The collaboration mode should be business-driven:

IT work originates from the business, and the business drives the collaboration and rapid delivery of various positions and functions
IT work must return to the business to form an effective closed loop of learning and support business innovation.

The delivery mode should be product-oriented:

From regarding IT as the cost center and centering on the use efficiency of resources to regarding IT as the profit center and centering on the long-term and overall benefits
From a short-term batch delivery to long-term continuous delivery and continuous product evolution
From regarding people as replaceable resources and establishing temporary teams for projects to a relatively stable multi-functional team for continuous improvement
From focusing on process assets of project management to focusing on all-around software, engineering, and organizational assets, including architecture design, software code, engineering capabilities, and team efficiency

When introducing the collaboration mode in the previous article, the product requirements decomposed from the business layer are directly handed over to the Product Delivery Team. The team quickly completes the product requirements and delivers them continuously. The two layers are connected to complete the quick response, delivery, and feedback closed loop of business, enabling efficient innovation in the digital age.

Summary

Business-driven collaboration and product-oriented delivery can adapt to the demands of the digital age and are our core value proposition for DevOps implementation. Moreover, their effective implementation cannot be separated from the support of engineering practices and capabilities. Part 7 of this 27-part series will discuss another core element of DevOps - the engineering capability of continuous delivery.

Community

Product-Oriented Delivery - Alibaba DevOps Practice Guide Part 6

Focus on Long-Term Efficiency and Business Value

Distribute the Work to a Relatively Stable and Multi-Functional Team

Accumulate High-Quality Software Assets and Team Engineering Technique Capabilities Continuously

The Fit between Business-Driven Collaboration and Product-Oriented Delivery

Summary

Read previous post:

Read next post:

Alibaba Cloud Community

You may also like

Comments

Alibaba Cloud Community

Related Products

Alibaba Cloud Flow

DevOps Solution

E-Commerce Solution

Livestreaming for E-Commerce Solution