End-to-end DevOps: Lessons learned and why it's essential

Culture is sometimes seen as the domain of the HR professional and leadership boardrooms—a soft value that gets applicants through the doors and gives management something nice to talk about at stakeholder meetings. But really, it's the actual everyday actions reflecting people's values and beliefs in the organization even—especially—when nobody's watching.

Enter remote working, physical distance amplified everything that was good—and bad—about the culture of a business, a unit, a team. It turned out culture was something that needed attention.

The multidisciplinary, eclectic individuals that form DevOps organizations also cooperate through their own cultural language. There are good DevOps environments, and there are challenging ones too. In our experience, the root cause of both cultures can be summed up in one simple question: Are you end-to-end?

The end-to-end approach to DevOps

End-to-end DevOps culture means, ideally, totally connected teams. Every decision is made with maximum visibility of all moving parts that connect to the project. Future plans and current activities, both business and technical, can be planned, executed, and dissected with the knowledge that no important nuggets of information are being held back.

Transparent communication between people representing all competencies, sitting together in the same room (digitally or physically) is the simple, effective way to paint a complete picture. There will be challenges, as does any project that has complexity, but the ability to solve those issues together and take all aspects into account is what smooths the ride. In theory, this kind of synergy is simple when it works, but sometimes not so easy to establish.

The exact demarcation of teams and their autonomous decisions is something to be considered as one designs the end-to-end system. The goal remains one of complete visibility, supported both by the tools and the process of decision-making.

Why DevOps culture is needed

If you aim for end-to-end responsibility, you'll have to take on challenges that can't be solved by siloing them into well-specified and defined tasks. Instead, you'll need to focus on reaching the right kind of outcomes and embracing the problem instead of the solution.

If you're building large solutions/services, break that big problem down into smaller pieces. Organize around smaller DevOps based on customer journey areas—not functionalities or technologies. Each team will clearly own their area and therefore can solve their problem in a holistic way.

Multidisciplinary teams should have end-to-end ownership of their project and a comprehensive mandate to fulfill their responsibility. It follows that each team should contain all necessary competencies and full access to relevant systems used by other parts of the organization.

Each of these multidisciplinary teams also needs trust, psychological safety, and to feel empowered—both inside their team and across the organization—to function well. When these pieces are in place, complex individual challenges can be solved while building synergies with the larger picture.

When working on large solutions, the teams also need to be connected to each other to enable joint problem solving when problems on common topics arise. Structures and culture that encourage inter-team communication and co-creation in a fast and efficient manner need to be in place. People must understand the big picture and how things are connected to each other to be aware of the other parts in the picture.

How to leverage automation to enable a positive culture

According to Brian Burke, Research Vice President at Gartner, "Everything that can and should be automated—will be automated." Hyperautomation is pretty much essential for large-scale continuous growth. The high-frequency cycle of delivery in DevOps has long been powered by automation.

None of this is possible if the whole service doesn't work together. If people are still digging up needed information from different locations or doing partly optimized sub-tasks, it's not possible to automate the process. Building features that provide value for customers is important, but there are other critical prioritization factors, too. Sometimes it makes sense to prioritize building needed automation instead of building features that bring direct value to customers. It often means that you need first to eliminate the sub-optimizations and ad-hoc parts that are often revealed by the difficulties in building the automation capabilities. Prioritize what the whole project needs before execution.

A culture of co-creation

To work on real issues, teams need access to the right systems. The easiest path is to build (and own) your own, but the acid test of a working DevOps setup is when the team needs to access shared resources. If things are sub-optimal, DevOps teams often find themselves sectioned off on their own little island while the rest of the organization works as it always has.

This is when ticketing system access requests begin, but with no visibility, the DevOps team is basically trying to understand what system to access, why they need it, how they should work with it, and where the info they actually need resides. A lack of common proactiveness on shared resources leads to silos.

People get frustrated and do the work they can so something gets done. You end up with a box full of jigsaw pieces that need a lot of extra work to shape them into something that fits together. Yes, it's tough, but kicking off projects by explaining the need for a co-creation culture will remove many stumbling blocks further down the road.

A healthy DevOps culture is powered by psychological safety. Therefore, it enables the team members to improve things they see blocking the work, raise the issues they can't solve by themselves to a wider audience, and bring their early ideas forward for everyone for a holistic discussion and develop further into action.

Also, it enables people to find ways to solve unforeseen problems that are cutting across different teams and organizational structures. A healthy DevOps culture has enough structures that support the work and reduce the burden of figuring out recurring topics again and again, such as agile practices that the team can tailor to their needs. End-to-end transparency is an essential feature of that culture. Many concrete practices, such as fact-based decision-making and the holistic utilization of user insights, rely on it. A growth mindset and continuous improvement are driving the team forward as they solve problems no one has ever solved in that exact same environment (otherwise, those things would have been automated already).

What all this means in practical terms

There is a great opportunity to shape your organization with end-to-end DevOps culture in mind. The roadmap to getting there includes these key practices:

• Understand your customer journey and shape your organization towards its phases. If you can't change the official organization, create transparency and start communicating openly.
• Look at things from an end-to-end perspective, focus on what you want as an outcome, and identify the chain of actions to make it happen efficiently.
• Build a working environment that supports the whole multidisciplinary team's needs, and automate everything you can.
• Team culture building is an everyday process. Take care of psychological safety; focus on transparency and good visibility as your drivers for decision making, information, and communication. Hold regular retrospectives with the whole team.

Outcomes are sure to follow when we invest in culture. Good luck on your DevOps journey.