Organize Software Delivery activities around final deliverables rather than roles: continuous delivery and cross-functional teams

In implementing continuous delivery, we can easily focus on automation and tools, because they are usually the easiest to do as a starting point. However, the successful implementation of continuous delivery also relies on the optimization of the organizational structure based on the final deliverables. For continuous delivery, the biggest obstacle is the organization of teams based on roles and hierarchies, rather than the final deliverables (products or services) in the business ).

To solve the "silos" between the development team, test team, and O & M team, the devops movement should be developed. So why do these "silos exist? Gartner's Coleen
Young said the following paragraph to directly address the core of this issue:

In fact, each IT organization will face a process transformation that will inevitably lead to a radical change in its organizational structure. The delivery and organization modes of traditional IT services are effective at the cost. In the past, computing power was very expensive. when resources were scarce, it was reasonable to maximize the utilization rate of personnel and the life cycle cost of assets. This resource-oriented business process will eventually lead to functional barriers. The optimized process-based organizations focus on the output of their respective links, rather than the global final deliverables.

The root cause of "Silo" is the historical cost of computing resources and the high cost of the release process. The size of the batch unit is directly related to the handover cost. This has already been reflected in the economic mic Lot Size equation, which is used to process the transaction cost (transaction cost) and deliver a work block to the next stage (such as from development to testing) the balance between the holding cost (not to the downstream cost. This is discussed in Donald reinertsen's "Principles of product development processes", as shown in:

Continuous delivery: reduces transaction costs

In the mainframe era, the transaction cost of releasing a version is small. Later, when we entered the Client/Server Architecture era, and later the web-based software system, the transaction cost of each release became higher and higher, and even ranked first in the total cost. This drives us to carry out batch development, which leads to the "Silo" we see today ".

However, continuous delivery delivers a piece of information, that is, there are many tools, models, and practices that can greatly reduce the transaction cost of publishing, so that the holding cost accounts for the majority of the total cost of delivery.

In this way, the root cause of the formation of organizational barriers will no longer exist. In addition, barriers may cause low-quality software, poor production environment stability, and fewer releases. Therefore, it is more necessary for project teams with critical businesses to eliminate these problems.

Cross-Function Team: optimization for final deliverables

A substitute for silo is a cross-functional team. As young suggests, in cross-functional teams, we optimize final deliverables or delivery times. The practice of continuous delivery can reduce the transaction cost to a negligible level. Then, we can implement small batch production by limiting the number of products in process and try to publish these small batch functions to users in the shortest time, or at least "can be published to users.

Cross-functional teams are not a new concept, but people often underestimate their importance. For lead-time reduction, cross-functional teams are a crucial factor. Because the delay in function delivery is often caused by communication overhead. If everyone involved in a product (or service) can work together, before writing code, the developer can directly call the tester to show him the functions that have been completed, to get quick feedback. Testers and developers can work together to create a function acceptance test. developers can also discuss database structure changes with DBAs, we can also discuss with infrastructure experts the balance points in the infrastructure.

This not only makes software delivery faster, but also has more fun. Of course, we will eventually get high-quality software, low-risk releases, and faster responses from customers. When Amazon makes the decision to "form a cross-functional team for service-oriented architecture", these factors are the key benefits it deems.

For "cross-functional teams", we often hear such objections. First, when the Organization is in compliance with certain laws, such as the Sarbanes-Oxley Act, or the Payment Card Industry Data Security Standard (PCI-DSS, all called the Payment Card Industry Data Security Standard, responsibility isolation is required. In fact, cross-functional teams can achieve separation of responsibilities more efficiently, just as I recently
Mentioned in an article about Cutter it journal.

Another objection is that there will be additional costs when creating a cross-functional team and implementing continuous delivery. Indeed, this means that you will only invest this additional cost in those strategic core service portfolios. In this case, products can be quickly listed, learned from users, and iterated quickly to avoid useless features in Development (this is the biggest source of waste in software development) returns several times the additional cost. -- Of course, some of the problems caused by "Silo" can be solved through better management means. For example, ensure that the Resource load in these "silos is not heavy, and personnel rotate across silos to encourage collaboration and understanding.

How can we move to a cross-functional organization?

If your IT organization is not large, for example, less than 30 people, you can change to a cross-function mode. However, in large organizations, like everything in CD, this should be an iterative and incremental process.

Start with a pilot project. First, make sure that you can collect the total cost and total income throughout the project cycle, as well as other related metrics, such as cycle time and the incremental value delivered by each release. The entire team is responsible for the SLA (Service Level Agreement, service-level agreement) of the service. Moreover, more importantly, the infrastructure on which you depend can achieve self-service, including the test environment and production environment, therefore, you do not have to wait for days or weeks for the hardware to prepare such work. The team should be given some time to achieve continuous delivery and focus on delivering a minimum viable product (minimum
Viable product), and then quickly iterate based on the real data feedback from the user.

Large organizations with distributed teams should turn to the "cross-Function Team" goal. The key is to ensure that teams are not organized based on different roles. For continuous delivery of high-quality software, nothing can hurt the development team in one country, the testing team in another country, and the O & M team in other countries.

Finally, the team should first focus on verifying the business assumptions made by breaking them into the least viable product set and testing. Once a failure occurs, it is easy to make adjustments.

The original Article is from CD. For more information about CD, visit
Http://www.continuousdelivery.info.