Five kinds of team organization methods landing in Devops


Original link:
By Matthew Skelton
Coding David Opps

Most organizations set up Devops to improve the delivery value between customers and business, rather than reduce costs, enhance automation, or drive organizational structure; this means that different organizations may need different team structures to carry out effective dev (Development) and OPS (operation and maintenance) cooperation.

So what is the right organizational structure to help Devops develop? “There is no clear answer. Obviously, there is no magic team structure that can be applied to any organization.

However, there are a few team structure models that have certain reference value for some organizations. By exploring the advantages and disadvantages of these team structures and considering Conway’s law, we may be able to determine the team structure that is most suitable for our organization and is conducive to Devops practice.

Many Devops team structures have been introduced before, especially Lawrence Sweeney of CollabNet, in Ben Kepes’ blog comments, detailed the anti type B (independent Devops barn: Devops silo), type 3 (infrastructure services: IAAs) and type 1 (development and operation cooperation: smooth integration) that I will mention in this article.

Devops guys lists 12 Devops anti types, and Jez tumble, gene Kim, Damon Edwards (and many others) have said similar things. Here I add three additional team structures. I have rarely seen or heard of these three types before: full embedded, Devops as a service, and temporary Devops team.

DevOps Anti-Types

First of all, an effective way to look at things is to observe its bad side, which we call “anti type” (after the ubiquitous “anti mode”).

Anti type A: separate barn / dev and Ops

It’s a traditional “throw over the wall” method that splits Dev and OPS. This means that the story point can be estimated in advance (“done” means the function is complete, but it doesn’t mean that it can be used in production). At the same time, the software’s O & M is damaged, because devs (developers) don’t have enough context to understand the function operation, and OPS (operation and maintenance personnel) don’t have time or inclination to participate in devs to solve the software together Problems before parts go online.

We may all know that this type is bad, but I think many team structures are actually worse; at least so far, we have realized the problem of this anti type A.


Anti type B: independent Devops barn

This independent Devops team usually comes from managers or executives who “need a little Devops” and then start a “Devops team” (there may also be a person named “devop”). Members of this Devops will quickly form another group to separate Dev and OPS, because they need to defend their roles, skills and toolsets from “ignorant DeVos” and “dinosaur like OPS”.

The only situation that makes this pattern understandable is when the team is organized temporarily for less than 12 or 18 months. The goal is to bring developers and operators closer together and to explicitly empower the team after that time.

This is what I call type 5 Devops topology (see below).


Anti type C: “we don’t need OPS (operation and maintenance)”

This team structure is a combination of the naive arrogance of developers and development managers, especially when new projects are launched. Let’s say OPS has become a thing of the past (“we have the cloud now, right?) , developers seriously underestimate the complexity and importance of O & M skills and activities, and think they can still do it without these skills and activities, or just spend some spare time.

When their software becomes more complex and more operation and maintenance activities begin to submerge “development” (i.e. programming), this type of anti type C may eventually require type 3 (IAAs) or type 4 Devops topology (Devops as a-service).

As long as such teams recognize the importance of O & M as a rule as important and valuable as software development, they will be able to avoid many painful and unnecessary (and very basic) errors.


Devops team structure

Now that we’ve learned about the anti type crap, let’s look at some of the team structures that Devops works well.

Type I: smooth cooperation in development, operation and maintenance

This is Devops’ Paradise: smooth collaboration between development and operation teams, each working professionally where they need to, but also sharing where they need to.

There may be many independent development teams, but each team will work on a separate or semi independent portfolio. My feeling is that the smooth collaboration model of type I requires considerable organizational change to build it, and a high level of competence in the management team.

Developers and O & M personnel must have a clear and effective common goal (“high quality delivery, fast iteration” or other). The operation and maintenance personnel must cooperate comfortably with the developers, master the test driven coding and git, take the operation and maintenance features seriously, find the operation and maintenance personnel to input the log records, etc., all of which need considerable cultural change compared with the past.

Type I applicability: organizations with strong technical leadership type
Potential effectiveness: high


Type II: full embedded / shared operation and maintenance

When the operation and maintenance personnel are fully integrated into the product development team, we see this type. There is so little separation between Dev and OPS that everyone pays close attention to a goal, which can be said to be a form of type one, but it also has some particularity. Organizations like Netflix and Facebook have effectively implemented a web-based product that already implements this type of structure.

But I think it may not be suitable for narrow product line mode, because there is usually context switching between budget constraints and multiple product lines, which may force Dev and Ops to further separate (for example, back to type one model). This pattern can also be called “noops” because there is no obvious or visible O & M team (although Netflix noops may also be type three).

Type 2 applicability: organization of products or services based on a single Web
Potential effectiveness: high


Type 3: infrastructure as a service

For organizations with quite traditional IT operation and maintenance departments, they can’t or can’t (enough) make changes quickly, and for organizations running all applications in the public cloud (Amazon EC2, Rackspace, azure, etc.), it may be helpful to regard operation and maintenance as an elastic infrastructure team that only needs to provide application deployment and operation functions. In this way, the internal operation and maintenance team is directly equivalent to Amazon EC2 or infrastructure as a service. Then the teams in dev (possibly virtual teams) serve as sources of expertise on operational features, metrics, monitoring, server provisioning, and possibly most of the communication with the IAAs team.

However, the team is still a development team, following standard practices such as TDD, CI, iterative development, guidance, etc. The IAAs team structure has some potential effectiveness (loss of direct collaboration with OPS staff) to make it easier to implement and potentially gain value faster than type I.

Type 3 applicability: organizations with several different products and services, traditional operating departments or their applications running entirely in the public cloud
Potential effectiveness: medium


Type 4: Devops as a service

Some organizations, especially smaller ones, may not have the funds, experience or staff to lead their software operations. Development teams may come into contact with service providers like Rackspace to help them build test environments, automate their infrastructure and monitoring, and advise on the various O & M functions implemented in the software development cycle.

What can be called devops-as-a-service should be an effective and pragmatic way to help small teams understand automation, monitoring, and configuration management. With the development of the business and more employees joining in, it is possible to shift to the third or even the first mode.

Type 4 adaptability: small team or organization with limited operation experience
Effective potential: medium


Type 5: temporary Devops team

This type seems to be very similar to anti type B, but in fact, its essential intention and long-term nature are totally different. The task of this interim team is to bring Dev and OPS closer together. The ideal goal is to completely transform into type one or two. Temporary team members will translate between dev speak and OPS speak and introduce some crazy ideas, such as introducing stand-up meeting and Kanban system to OPS team, and some critical details, such as introducing load balancer to dev team, managing NIC and uninstalling SSL.

If enough people realize the value of the combination of Dev and OPS team, the temporary team will have the opportunity to truly achieve its goals. It is critical that long-term responsibility for deployment and production analysis should not be assigned to ad hoc teams, otherwise it is likely to evolve in a negative direction for anti type B.

Type 5 adaptability: want to achieve the predecessor of type 1, but be aware of the possibility of developing into Anti type B
Effective potential: low to medium



Which Devops team structure is right for an organization depends on the following:

  1. The organization’s product mix: fewer products make it easier for teams to work together because, according to Conway’s law, there are fewer independent silos in this case.
  2. Scope strength and effectiveness of technical leadership; whether Dev and OPS have clear common goals.
  3. Whether the organization has the ability or desire to change its IT operation and maintenance department, and whether it can realize its value flow from “server establishment and configuration”, and whether the software R & D team takes the operation and maintenance team seriously.
  4. Whether the organization has the ability and skills to solve the operation and maintenance problems.

Of course, the topics described here are different. As a reference guide or inspiration, team structure and type may help to evaluate which pattern is suitable. In fact, the combination of multiple models, or the formation of the two models into a transformation and progressive structural model, often can achieve better results.

Activity Notice

July 21 Japan Sunday, CO Ding, Tencent cloud, Tencent TEG technology engineering business group will jointly holdThe first Tencent operation and maintenance technology open dayThe purpose of the activity is to share and exchange Tencent’s internal practical experience in operation and maintenance, and create an operation and maintenance technology ecology of joint communication and progress between Tencent’s internal and external.

Coding is deeply involved in Devops market. In addition to Tencent, it also provides Devops tool services for Foxconn, lakala, Cathay Pacific Fund, Tianjin University and other organizations.Zhang Hailong, founder of coding, was invited to attend the event, will share with youExperience in assisting customers with Devops transformationAnd inNew relationship between development and operation and maintenance under the general trend of Devops

Click here to sign up
We look forward to your coming on July 21!