DevOps culture is about dissolving the boundaries between IT operations and development. Its essence is in the Development Operations, in the ownership of the product and continuous improvement of the processes, tooling and teamwork.
The benefits of DevOps culture reflect directly to the ways of working, how your team is functioning, how the product is being developed and with which tools.
A DevOps team is one vertically integrated team building and maintaining a product or service. There are no separate teams or divisions doing development and IT ops.
A DevOps team aims to automate their workflows as much as possible, ranging from maintenance to testing to deployment. People and their roles within this kind of team can vary: a functioning team fostering DevOps culture has its specific DevOps, development, and facilitative roles and responsibilities. People share their tasks. One team takes total ownership of the service they are building and hosting, with roles and titles being secondary to the goal. Ideally, the tasks are usually performed by the developers so there is no need for a separate DevOps role.
A unified DevOps team can build more efficient systems and services without organisation-enforced abstraction. There are no silos or bickering between development and ops teams. Per Conway's Law, a system’s design mirrors the organisational communication structure. This does not mean everything becomes a monolith; building microservices is still possible, but they're built on the product's terms instead of the teams'.
Don’t forget the tech
Modern (IaaS) Infrastructure as a Service tooling (such as Terraform, AWS CloudFormation, Pulumi) allows DevOps teams to manage their infrastructure environments like one would manage software development ones. Peer reviews become easier, changes faster, and maintainability more transparent. These tools narrow the gap between dev and ops methodologies. No more cowboy coding, no more cowboy ops.
Cooperation supplemented with modern tooling enables faster feedback and improvement cycles. As the team gets more stuff done faster, its members' self-confidence increases, reducing time spent hesitating and leading to a self-reinforcing loop of improvement.
The essence is shared ownership
Making a working DevOps team (or any team) comes down to ownership of the results. With no possibility of assigning blame to some other entity, a team must take ownership - and move on with solutions.
The scope of things to learn and pay attention to widens for one team. A vast technological stack can be overwhelming, especially for newer team members looking to be productive. In the end, no one person should do everything, but having avenues for learning and options for manoeuvring within a team is an often overlooked perk.
With total shared ownership and possibly fluid roles, these teams require self-management skills. Team members need to assign themselves responsibilities and figure out cross-disciplinary processes. They must handle some of the communication traditionally conducted by middle management. Add these requirements to the widening tech stack, and the difficulty level rises again.
Achieving a working DevOps culture removes much of the IT management nonsense. It's only possible via shared ownership that promotes learning, continuous improvement, and collaboration.