Almost everyone I have ever met is terrible at defining devops, because I believe it is more about the process than the tools — essentially, we want to do everything right, verify that everything is actually right, and make everything visible.
There’s no part of the entire software enterprise that isn’t within the problem domain of a true cross-functional and effective devops team, so trying to bound it in functional or technical terms always comes up short.
A lot of people will say it’s about automation, or full stack development, or CI/CD and faster releases, but those are all visible outputs of an overall well-functioning software delivery organization.
I think devops is a philosophy and practice of taking hard things and making them manageable enough for people to accomplish reliably in human time scales, so that they can focus on work which provides value.
I don’t like the idea of DevOps Engineers as a functional role or team, because it’s like saying Agile Engineers or Git Engineers — devops is too big for any single team or role, devops is only effective when everyone in the organization has ownership and contributes to the whole system.
Team Structures Matter
To do good software delivery, teams need to be large enough to perform meaningful work, and small enough to be managed effectively from within — with a goal to normalize work among the different groups and keep communication flowing.
A lot of this is going to be changing behaviors and expectations — devops is only about the tools as much as they are valuable to their users. The primary place that DevOps/Agile transformation fails is that people expect to shift an entire culture in one project or by using a new platform, but it’s extremely ambitious try to pivot from a waterfall legacy Java shop to a microservice Kubernetes one as a single initiative.
Process Is a Means, Not an End
Just because developers are doing Agile, and running sprints, doesn’t mean much if the release cadence isn’t in sync and directly driven by the product teams. If we don’t map out and improve the release process, to the point where developers can be doing prod deploys independently, then every other tech we layer on top will be a band aid at best.
This generally happens because people see new technology that, when fully deployed and mature, fosters a much more sustainable workflow than what we have now — but we need to account for making those shifts while maintaining legacy service sufficient to our existing agreements.
Big Picture Strategy Drives Everything
Systems thinking, understanding how each decision impacts not only the final product, and how other teams and stakeholders engage in the process, is essential if momentum gained is to be maintained. Making an improvement in one area that streamlines a part of the process which wasn’t causing much pain may seem like a wise investment, but that time and energy will generally be better spent addressing a constraint which is causing the organization pain.
Focus on Demonstrable Value Above All Else
We need to prioritize on things that can help the business do business better — and, more to the point, we need to be able to show our customers and prospective customers how we deliver value, and to do so at or above expectations every time.
The entire software delivery lifecycle, and indeed the entirety of the company, is a tightly coupled unit — any deficiency in any area can be compounded to be detrimental far beyond its immediate effects. Slowdowns and missed communication between groups compounds and error probabilities raise significantly as the sizes of changes grows and the release cadence is further attenuated.
Agency and Autonomy are Paramount
Only by making everyone in the organization empowered and responsible for applying DevOps practices can this concept be successful. The general thrust should be to allow one person to do everything they need to create, deploy, and maintain software with minimal fuss and maximum simplicity.
To do this, there are two critical areas, and unhappy organizations tend to focus on one to the detriment of the other. First, the tools and services must be usable and useful to the teams we serve, and secondly, communication and normalization of decisions across the organization must be fostered.
Decentralizing decision making to allow more agency and autonomy can lead to dramatic increases in productivity and quality, but only if it’s done in a way that decentralizes the power of legacy processes to the teams. Too many organizations will declare “full stack” teams without giving the teams the trust and support needed for them to move at the pace they want, which leads to confusion and regression to the mean.
Set Reasonable Goals to Get Sustainable Wins
Be cautious of the psychological scope creep of shifting to a model agile organization in one jump, setting small milestones and building confidence across the organization to try new things, and keep or throw them out based on results and data, doesn’t need to have everything fixed in one big project.
Many times, some change instituted may be better, but is dragged back to the old ways by pressures elsewhere in the organization. This isn’t great, but sometimes putting that part of the puzzle down, and focusing on areas tangential to that piece, can help build the feedback loops that will move that needle incrementally.
People Aren’t Machines
In a lot of cases, the early stages of a digital transformation should be focused on improving existing process and tackling burnout. Addressing the immediate pain points for developers might mean spending a lot of time in the legacy Jenkins server fixing and instrumenting the status quo, but these backwards-looking work streams are necessary to buy the time and focus teams need to make meaningful improvements.
In my experience, issues with scaling are rarely about technology — consultants, vendors, and new tools can be brought onboard in a truly agile organization without a lot of fuss — the issues generally relate to the scaling of the humans and processes that underpin the product.
Making burnout a top tier priority will demonstrate that our process is aimed squarely at real needs and can demonstrate real value, and create opportunities for people across the organization to take a more hands on role in the process.
Maintaining and Scaling Wins
The regression to the mean is a real problem in our field, as the natural tendency of a group is to do what they’ve always done. Introducing new processes, tools, and ideas means that the way things have always been done might not be the best way to get to the strategic goal.
By focusing on actual needs and making sure that we understand the ask and the expected result, we spend less time doing things that look useful but don’t make a meaningful contribution to the process. Making sure that communication with stakeholders is consistent, and a required part of the work flow, can give us the temperature of the teams and see how people are receiving our work.
It’s a Journey, Not a Destination
DevOps is, if anything, a metaphysical thing — we can’t ever really say “we are done and are fully DevOps capable now”, because it’s more about how we look at our internal processes and structure to continually maintain and improve the things we create.
Because it’s not something we can put in Artifactory and version, it can be hard to quantify the benefits of this process in the earliest stages. Many times this will lead to resistance, as teams who are overwhelmed by the legacy process have no bandwidth to take on more work.
Focusing on meeting these teams’ needs in the short term builds the reputation and trust in DevOps practices which will be critical in making the larger and more disruptive changes that will come in time.