I have been practising and advising on DevOps as a consultant with different clients for almost five years now, before my current position, I held roles in software development, web operations and systems administration. In my personal experience DevOps comes in many flavours.
Organization Patterns
DevOps Antipatterns:
NoOps and NoDevs - not strictly DevOps in the most strict sense, however, these teams both build and operate software without a dividing line between Development and Operations. The challenges with these teams come down to maturity, Development teams may be expert Software Developers but novice Operators and visa versa.
The DevOps Bridge - this is where one or more teams are given responsibility for taking work from the development teams and "Productionizing" it to make it operable. The challenge comes down to now there are two hand-offs, i.e. Development → DevOps and DevOps → Operations.
The DevOps Team - this can, arguably, work if the team has responsibility for building tools that support the DevOps enabled Operating Model, however, it should probably be called a "Tools Team" or "Platform Team".
DevOps Patterns:
Embedded DevOps - more commonly referred to as Platform Engineering, whereby there is someone within the team who is accountable but not responsible for delivering automation, tools and infrastructure for the provisioning and deployment of the solution, sometimes also including operating the software - in my mind, it's the latter that is actually representative of DevOps.
Institutionalized DevOps - where a project team jointly is responsible for both development and operation of a software package building shared ownership and positive feedback loops.
Practices
The actual practice of DevOps builds on top of several other practices, namely:
Each of the above practices builds upon the other, it's possible to not follow a practice, however, it means an important feedback cycle is missing which may be indicative of a "missed opportunity". The key differentiator between following any of the other practices and DevOps is the operation of software in production.
The Three Ways
In The Phoenix Project Gene Kim and his co-authors describes the three ways of DevOps:
Systems Thinking
The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).
In my experience starting to get Developers to consider Operational Concerns and Non-functional requirements achieves this goal. This is very much part of the culture aspects of DevOps.
Amplification of Feedback Loops
The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.
I generally achieve this through Continuous Integration/Delivery/Deployment and shared monitoring and alerting, thus it very much fits in with the tools component of DevOps.
Culture of Continuous Experimentation and Learning
The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.
This fits very much in the culture space, although it depends heavily on tools and process to enable the culture to grow.
