Companies that think that DevOps is a technology-only endeavour are set up for failure. At best, they will create some short-lived automation, and will not support a delivery chain of an ever-changing application—which is just Waterfall 2.0.
DevOps has as much to do with the organizational structure as the technology used to deploy applications.
Do you like pizza?
In the most successful DevOps organizations, the first radical change comes from finding a way to improve conversation, and decrease unneeded variables. The first and easiest way to accomplish this is by creating two-pizza teams, where each development team and DevOps group is limited to around seven people. The smaller teams are able to focus on results of discrete units of the application or delivery chain without muddying the waters with the broader team.
This, however, is also an application architecture consideration. If the application is a Waterfall- developed monolith, it is not easy to identify the discrete units that would constitute individual teams.
Communication and stewardship
Small two-pizza teams do not mean fiefdoms. If it did, then we are only further compartmentalizing what’s been done before, and creating a huge problem. Barriers have prevented communication and sharing. It is not easy to balance results focus with open communication, but many organizations are tremendously successful doing so. The way they do this is by making communication a priority, and focusing the DevOps function on stewardship.
The DevOps Engineer, IT Ops Manager, Site Reliability Engineer, and Quality Engineer, etc. are all joining together not to dictate how developers work, but to be stewards of efficient and high- quality development practices. Their job is to make sure that everything is automated, developers are focused on coding, and that the application maintains quality.
This “DevOps+QA” unit builds the delivery chain and offers it to everyone else as if it were an application of its own. They also provide the systems for monitoring and communicating, which are the key aspects to transparency. By reforming these functions as facilitators, there is an opportunity for everyone to give input on how the delivery chain works, but one group is focused on its execution and always improving it.
Give developers more work with less effort
By building a system of stewardship, the concept of “shift left” is more than just a novel idea. Most people's reaction to giving developers more work is giving them the responsibility of testing, even in some cases supporting production deployments of their application—and this seems insane. How can you expect developers to build more features, but at the same time give them more work to do that has nothing to do with coding? You can, and it’s surprisingly effective. DevOps+QA gives developers a toolkit of test suites and automation that makes it easy for the developer to commit, test, and review without any additional effort on their part.
You might say reviewing the test results is an additional step, but not only is it not more work, it’s less work. Either you review the test results continuously upon every commit, or you review them when the customer complains and it’s 10x (or more) difficult to correct. So by finding issues on their own, developers are saving a ton of time. If a test run delivers a failed test result, the impact of that failure will hit them in the face no matter what. They could address it before it’s even exposed, or when they are in the hot seat and everyone knows about it.
It’s still top-down
Organizational changes are still top-down. And very often the executors have little influence over that. But lets assume you are working for an organization that supports modern development practices and the pieces will all fall into place.
One major change that organizations can make without deliberately defining the structures discussed above, and with no technology at all, is aligning objectives. Most organizations have incentive programs, but often the incentives across the team compete. For example production teams might be measured on how few outages occur, which motivates them to change nothing. And developers are measured by how many features they get out the door, or tickets they close. There is no way this conflict won't cause animosity and guarded information and tools. Rather, the entire team should be focused on objective results. Results are providing the functionality that users want at the highest quality.
Approaching DevOps tool-first and tool-only is a fun way for techies to tinker with a lot of new and cool technology. But it’s only that—a sandbox. The DevOps methodology was not constructed to build short-lived automation and delivery chains. It is also meant to support future adaptations in the environment and application. Because of that, tools are the second part of the equation. And all organizations need to get their structures and motives aligned so that the amazing environments they build can sustain, and churn out far greater functionality.
About the Author
Chris Riley (@HoardingInfo) is a technologist who has spent 12 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling. In addition to being a research analyst, he is an O’Reilly author, regular speaker, and subject matter expert in the areas of DevOps strategy and culture. Chris believes the biggest challenges faced in the tech market are not tools, but rather people and planning.
We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.
As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag!