It's DevOps, not Dev[space]Ops

I don't want to spend time and effort creating yet another rehashing of all of the goodliness of the DevOps approach to software development and operations, but I would like to clarify my feelings on what a valuable DevOps environment should look like.

Many practitioners of DevOps make it look more like "Dev [space] Ops" where I am a strong proponent of "DevOps" (no space!) model. The [space] model promotes two organizations (Dev and Ops) working more closely together (a good thing, no doubt), while the no-space model does not identify two organizations - but a singular organization performing tasks from both of those roles.

Just move a few people around - no biggie

This may seem like a subtle change which can be achieved by simply assigning operations team members into the development organization - just move a few people around, no biggie. This often leads to the situation where Ops people only take on Ops tasks, and the Dev people only take on Dev tasks. That situation is still a "Dev [space] Ops" model in that there is little to no cross-training or cross understanding of the needs and processes of each role. People like to feel that they are contributing and the best way to get that feeling is to contribute in areas where you are already knowledgeable and comfortable.

That is not what DevOps means to me.

What DevOps means to me

DevOps to me is a single team that takes on the entire set of tasks surrounding both development and operations - shared among the team members without regard to their past experience. This ends up looking very much like the idealized Agile development model, but with operations thrown the mix as well. Expanded experience, learning, and progress get spurred on when things get a bit uncomfortable, forcing team members to learn new skills. This is where the real value of DevOps comes into play. Developers, if left to their own devices, will tend to create products that are focused on customer needs and expectations but will often fail to take into account that operations of the product are also a customer of sorts. Moving the operational aspects of a product into the development team lays bare the "ops pain" that developers can inadvertently create. In the situation I discussed earlier ("just move a few people around - no biggie") DevOps can be achieved via that process, but it takes a consistent and focused mindset to avoid the situation where the Ops people only take on Ops tasks, and the Dev people only take on Dev tasks.

What does it take to get there? A lot of work. A lot of fearless taking on of unfamiliar tasks. A lot of closer collaboration between ex-Ops and ex-Dev when they become DevOps.