Can DevOps Work for Small Organizations?

Can DevOps work for small organizations? Without hesitation: yes.

However, if that were the end of the story, this would be the shortest article you’d read this year. But that wouldn’t be much fun, would it? In general, DevOps is a perfect fit for small organizations. But it might not be right for ALL small organizations.

If you were to ask the real, more tactile question: “Can DevOps work for my small organization?”, we would end up in murky waters where “it depends” is the only honest answer. I would prefer if you asked me, “How can DevOps work for my small organization?” This way, you’ve committed to leading the change. But let’s address the original question first and make a pact to start asking more open-ended questions overall. Pinky swear?

Goldilocks Was Here: Finding the Right Fit

If you know the Goldilocks and the three bears story, you’ll remember there were three bowls of porridge. One was too hot; another was too cold. But baby’s was just right. Since small organizations come in different sizes and DevOps comes in different flavors, we’ve got more of a continuum. Let’s see what DevOps looks like in small organizations of various sizes.

The Smallest Organization

How small is small, you ask? The size that constitutes a small business varies depending on where you are in the world and who you’re asking. I’m thinking of organizations with between one person and two-hundred people.

The very smallest organization, by definition, is probably already practicing DevOps in some way. Only one person is doing all the work. That person is responsible for development and operations. Is that person taking advantage of automating the operations parts of her work? Is she gathering continuous feedback on her application performance and applying it to continuous improvement? I can’t say for sure. If she is doing those things, she’s probably keeping her customers happy and maintaining her sanity at the same time.

Even in an organization of two to ten people, most will be involved in operations to some degree. Practicing DevOps relieves some of the pressure of maintaining custom software. The organization might outsource some or all of its operations. At the same time, that smaller organization can use feedback systems to keep its operations running smoothly. This feedback system could be the catalyst for growth. When you’re running a small organization, you want the kind of natural, stable growth that DevOps enables. Therefore, DevOps is suitable for even the smallest of organizations.

The Organization That’s Starting to Grow

As organizations grow, they tend to specialize further. Let’s say that a tiny organization of ten people becomes successful enough to elicit a round of funding. They grow in size. They advertise. Business picks up rapidly, and so does their product usage.

Let’s imagine you are the head of this organization. What would you want to know about your product usage? I propose you’d want answers to the following questions:

• Which features do you utilize most?
• How is my infrastructure handling the load?
• What are the operational costs of my products?
• How can I reduce my operating costs to increase my margin?

A simple picture shows us how to answer these questions:

Suddenly, that DevOps culture becomes the saving grace of your quickly expanding empire. You measure (perceive) the operation of your software. And because you feed real-world operational metrics back into the system, the system is self-balancing. Furthermore, both the software and the organization scale to the load. Developers are quickly responding to changes. Users are happy. Life is good!

The Big-Small Organization

You’ve done well! Your growth is good, and so is capitalism! Now you’ve got about 100 employees. Consequently, some of those employees have never met and probably never will. What’s more, the organizational structure is deepening, and middle-management is fattening up. Furthermore, departments are specializing. A reorganization is happening whether you like it or not. Herein lies the question of how to structure your teams to handle various responsibilities.

Traditional culture divides the organization along functional lines. And according to Conway’s Law, if you structure an organization along functional lines, the systems will tend to be structured along the same lines. The separation between development and operations depends on the breadth of the seam between the departments. A broad seam will result in poor DevOps, while a narrow one is good for DevOps.

Similarly, if an organization has a separate “DevOps” department, as some do, there’ll still be a divide between the operations and the development of the software. Business as usual with a different label.

First, you need to fully understand the risks of anti-patterns like having a separate DevOps department. Then, you need to be sure the proper patterns work in concert with your organizational structure in order to realize the potential of DevOps culture. DevOps works differently depending on the structure of the organization.

Let’s see how some organizational structures work with DevOps.

DevOps Success Depends on Structure

Which organizational structures best support a healthy DevOps culture? Let’s look at how DevOps fits into each of the five most common types of structures.

A matrix organization has separate departments based on functional areas and project teams that pull resources. So, there may be resource sharing between product teams. People are more likely to specialize than to have T-shaped skills, meaning they are highly skilled in one area but can take on tasks in other areas.

Chance of DevOps Success: Medium.

Major Risks: Resource contention, rebranding, silos.

A functional organization has departments based on functional areas. Therefore, each department has a specific focus. Information is pushed out to other functional areas of focus. Highly specialized resources are the norm, and silos run rampant.

Chance of DevOps Success: Low.

Major Risks: Resource contention, rebranding, deeper silos, change resistance.

Product organizations have separate product departments. Each product has resources dedicated to delivering specific product lines. The product departments may have either specialized or T-shaped developers. However, these organizations need operations specialization. The solution may be a cross-functional virtual team or a platform team.

Chance of DevOps Success: High.

Major Risks: Lack of operations specialization.

A customer-focused organization has separate departments based on types of customers. Therefore, each division has its own resources for delivering customer-type-specific solutions. This type of organization may see a lot of duplicated effort and/or confusion over ownership of shared assets such as data and software. However, these problems can be overcome by introducing a division that has the “internal customer” as its customer type. This division would deliver solutions for cross-cutting concerns.

Chance of DevOps Success: Medium.

Major Risks: Silos, lack of operations specialization.

In an organization designed around geography, divisions in the organization are separated by region. Some functional areas in the organization fall naturally into this structure, others not so much. For example, while it may make sense to create culturally specific client apps, it probably doesn’t make much sense to have regionally separate applications that are cross-functional. Again, a separate division would be needed to deliver cross-cutting concerns to avoid chaos and inefficient duplication of efforts.

Chance of DevOps Success: Medium.

Major Risks: Silos, lack of operations specialization.

Real Organizations Don’t Fit Molds; They Break ‘Em

I’ve also rated the division along product lines as the organizational option with the highest chance of success and the division along functional lines with the lowest. DevOps succeeds when communication flows freely. Teams structured along the same lines will have lower barriers to communication; thus, their processes will be designed with fewer gaps between development and operations. The products will follow suit.

A matrix is a close approximation to forming teams along product lines. However, the first chain of command in this structure is in the functional area; project teams are more of a temporary arrangement. Therefore, communication, process, and product will flow up the functional chain, across that departmental divide, then down into the other functional areas. Competition over resources will thwart efforts to create a true DevOps culture. A matrix structure is more likely to form a separate DevOps department or rebrand the operations department. And DevOps is neither of those things.

Of course, most businesses aren’t going to organize exactly along these lines. Most business models will naturally fall into some hybrid of these five basic models. However, some may not fit into any of these boxes. Valve Corporation is a perfect example. They use a flat model and organize strictly around projects.

Fortunately, some excellent people have been working on composing anti-patterns and patterns for DevOps topologies (please read the comments too; Matthew Skelton provides much more context in his responses). No matter the size or structure of your organization, this compendium shows you how to achieve a successful DevOps implementation.

DevOps Can Still Succeed, Despite My Pessimistic View

Regardless of the organizational structure, DevOps can still succeed in a small organization. A slight (or even significant) reorganization might be necessary to realize maximum benefit. Fortunately, this should be easier to pull off in a smaller organization. After all, if “embrace change” can’t be achieved by an organization, it has no business doing DevOps (and arguably business at all).

Originally published at https://aspetraining.com/resources/blog/devops-small-organizations.