This article has been updated based on the sharing by CODING Compass Product Director Cheng Shengcong at Tencent Cloud CIF Engineering Effectiveness Summit. At the end of this article, you can visit the official website of the Summit to watch the replay and download the PPT.

DevOps moves from instrumental to procedural

Software engineering has grown from the 1960s to the present, and there is no doubt that it is the age of DevOps, as evidenced by the DevOps transformation that has taken place in the industry over the past few years. By now, companies have been investing in the transformation for so many years that they are eager to see results. A common question is whether DevOps really helps the business and the digital transformation, or whether it’s just the r&d team’s idea.

During the past year of assisting customers with DevOps product launches, we have come to realize that R&D management really can’t just build toolchains, but also apply those tools to the actual business processes of the enterprise. We should actually reduce the burden of development, not add to the burden of business development. Only in this way can research and development efficiency be effectively improved to better meet the needs of business development.

If DevOps used to be instrumentalized, with all kinds of tools emerging, it is now entering a new phase: streamlining in the context of the rapid development of digital business.

There are still challenges for enterprises using DevOps tools

Starting with a typical user feedback, let’s look at the current user dilemma:

The customer above has been using CODING deeply for more than one year, and they have enough say on whether the product is good or not. Through sorting out the feedback results, it can be seen that the products in the instrumental stage still have deficiencies. On the one hand, the client fully affirmed the original decision to choose CODING DevOps. Every role in the team could work on a one-stop platform, which well realized the goal of r&d integration. On the other hand, although our one-stop platform provides the capability modules that the team needs, the collaboration between the different modules is not very good.

  1. For the product, its focus on requirements activities does not relate well to what the development is actually doing, and thus does not have full control over progress and risk.

  2. Updating task status is important for development, but since it doesn’t block you, it’s up to you to do it. So a lot of times, people who are busy with collaborative programming tend to forget to do this.

  3. At the same time, as a relatively post-test, once the test is proposed, a variety of items check is boundless, all kinds of information check and update will take a lot of time, plus the time left for the test is not much, the situation is particularly embarrassed.

  4. And then the operation and maintenance colleagues, not to mention, can only repeatedly told to make full preparations before the release of the version, all kinds of verification checks can not be discounted, and then can only pray not always in the sensitive release window, there are all kinds of puzzling problems.

In general, while the different tools on the same platform worked well, there was always something missing from the overall flow. Switching back and forth between tools still takes a lot of effort, and there is no guarantee that the information is correct. All these are the shortcomings of instrumental products.

Enterprises are increasingly concerned about the overall efficiency of R&D management

This case is not an individual case, but a sign that DevOps has moved to a new process stage: companies are increasingly focused on the overall efficiency of R&D management, from the emphasis on the local optimization of a tool to the emphasis on the global optimization of collaborative processes.

Tools are not equal to overall efficiency. It is pointed out in the PPT of the classical theory of organizational effectiveness management that among the three elements of an organization, People and People are the foundation; Tools and Tools empower People to make work more efficient; Process and flow are carriers to keep People’s behavior consistent with their goals. Doing something perfectly that should never have been done in the first place is pointless and even detrimental to the whole. In the big picture, a good process is essential.

DevOps products should be built into a new type of production relationship that further liberates productivity

In the context of digitalization, the rapid development of business brings high complexity of software system, and individual needs to deal with more things, resulting in the decline of individual efficiency. In order to increase the productivity of each role on the team, organizations pursue DevOps transformation, hoping to leverage emerging technologies and tools to rapidly increase team productivity. But the increased investment in technology and tools, and the growing size of teams, has also brought with it complexity in overall collaboration. These complex dependencies are transmitted to team members like a pyramid, forming a huge impact on the original work habits and even understanding. Even a simple delivery requires a lot of work and collaboration between different actors, making the delivery process fragile and inefficient: there are no contracts and specifications for upstream and downstream work, lack of transparency in the development process, and the need to switch back and forth between different tool platforms.

How can different tools coexist organically in a complete process? How do you create an efficient process for your team to develop high-quality software and release it into production? In this process, team members don’t have to deal with unnecessarily complex issues, get bogged down in details, or wait for long delays. We should free up the productivity of our team members so that development can focus on the work that actually generates business value. This is something worth thinking about right now: just as productivity determines the relationship of production, we need more advanced R&D management products to empower r&d teams to meet the needs of today’s digital business.

CODING Compass: DevOps process management products for DevOps process management

Through sorting out the problems highlighted in the implementation of DevOps practice, we come to the following two understandings:

1. DevOps transformation at the organizational level requires domain experts

According to a report on the Status of DevOps in China (2021) released by The China Information And Communications Institute in July, nearly 30% of enterprises are slow to implement DevOps due to the lack of DevOps experts. And when we serve customers, we often need to provide consultation, through expert diagnosis, develop procedures, and then according to the actual situation, set the goal to improve and specific realization path. What DevOps products do is: extract proven r&d management experience in the industry, embed it into the product, and guide the customer team to solidify good habits and continue to optimize, so as to achieve efficient R&D management.

2. The biggest pain point for team members in collaboration is “trying to understand everything”

With the tools already provided, teams can initially work together with a naive understanding of DevOps. However, the collaboration problems faced by users do exist: for example, the lack of capacity for cross-functional activities, the lack of collaboration specifications between activities, the difficulty of identifying risks in the r&d process, the excessive context that individuals need to understand in their work, and many cross-functional operations can only be handled manually, etc. These may seem trivial, but when these problems add up and go unaddressed, they can cause great “mental drain” on team members and even lead top performers to doubt about creating an effective organization.

The development of DevOps to this stage represents the industry’s new expectation for R&D management products: from Agile to DevOps, coupled with LEAN’s LEAN thinking, towards enhanced visualization and traceability, standardization and efficiency. Based on the perceived pain points, CODING combined with its own practice and industry experience, made efforts to upgrade its products to help customers better improve their R&D management capabilities.

Compass = Workflow + specification + automation

CODING has created a new R&D process management product Compass that includes three main capabilities: workflow (synergy between activities), specifications (standards to improve consistency of R&D activities), and automation (triggering post-activity). It represents that CODING DevOps integrates the know-How part on the basis of the original DevOps tool chain, so that customers can fully learn from the effective practical experience in the industry and achieve efficient R&D management.

How can Compass improve its R&D management capabilities

In short, Compass’s product logic is to define processes, standardize processes, streamline flows, identify bottlenecks, and guide improvements.

1. First of all, there are various activities in the R&D process.

Such as product manager will create demand into the backlog, the team to carry out the program will into the iteration, and claim or assign task decomposition, task, development will create branch, writing code, submit to merge, and so on, while the test is design cases, executing test, measurement, then the team after the quality contral and create release and so on.

As we know, some of the things listed here happen within the same kind of role, while others need the cooperation of different roles. In fact, there is a sequence of their progress.

2. Second, identify key collaborative activities and connect them into a complete workflow.

After classifying these activities according to different roles, it is found that some activities of the same role are objectively preconditions for others. For example, after the requirement is created, it can be included in the iteration, after the branch exists, it can have the corresponding code submission and MR, after the use case design, it can be associated with the corresponding requirements, etc. These internal relations lead to the inevitable spontaneous completion of their activities.

For the remaining key nodes, we artificially defined their dependency order and connected them in series according to the actual work situation from the perspective of overall RESEARCH and development. For example, the corresponding feature branch can be created after the task is disassembled, and the test can be proposed after the MR and requirements are associated with test cases, and then the test is executed, the test report is given, and the release order is submitted. This forms a complete workflow.

3. Thirdly, ensure the robust flow of activities through norms, and drive the efficient flow of activities through automation.

In order to ensure the robustness of activity flow, we can set the admittance and approval criteria for some activities, and give warnings and prevent the flow from continuing if the activities do not meet the criteria. For example, the requirements to be included in the iteration should provide acceptance criteria and serve as the basis for use case design, and the pass rate in the test report should meet a certain value before the release order can be created. In addition, automation rules can be set for certain activities that can be created or triggered in a standardized manner. The flow is automatic when the prerequisites are met, and there is no need for team members to switch to another tool to update status or manually create tasks for the next step. This results in an orderly team collaboration workflow.

4. Finally, map the R&D steps to the business-defined value stream stages to provide insight analysis.

Specifications and automation can produce accurate records of activity to provide real and reliable data for efficiency measures, effective insight diagnostics and guidance for improvement. Such as difference in lead time and processing time, task completion/accuracy rate, etc. This is the foundation of Value Stream Management.

This is Compass’s product design philosophy. We want to drive collaborative development through processes so that everyone in the process can focus on their own value. At the same time, precipitated process data can accurately perspective the research and development process, and based on the insight analysis of data to guide the continuous improvement of the research and development process.

conclusion

CODING Compass is a development process management product based on CODING’s original DevOps tool chain, which includes process choreography, process driving, rule constraints and value flow. It is hoped to help enterprise latong managers’ target expectation and r&d team’s specific execution, and achieve the highest response ability with the minimum collaborative cost, so as to maximize r&d efficiency.

Compass is currently in internal test and is expected to be open for public test at the end of the year. Please look forward to it!

Head over to see a replay of CIF Summit