In a past discussions on DevOps, I’ve said that the Dev doesn’t stand for Developers. That probably seems odd, since in many instances it’s described as Developers + Ops. DevOps is a software development methodology, hence the Dev means development. But, what does that actually mean?
Development is the business side of your product pipeline, as opposed to Ops, which is the customer side. The business side entails not just your software developers, but Product, Sales, and QA (and you could even argue Marketing). These organizations help come up with the product requirements and customers who will use the product. You need a product to develop that your customers want so that the software developers can start developing. This whole side of the business needs to work in synchrony to provide the most value. Development without a product nets you nothing, and product without customers nets you increased inventory costs.
This also affects your feedback loop between Ops and Dev. The operations side of the house needs to provide feedback not just to the software developers, but to let Product and Sales know how the customer’s needs were met and QA needs to know about quality issues that slipped through. If you only talk to the developers, your feedback loop isn’t complete and you’re not implementing DevOps properly.
Celebrating your developers and ignoring the rest of development is like exercising your arms and legs but ignoring your core.
rnelson0 
Interesting post, and I do agree with your core idea that DevOps concepts need to extend beyond dev and ops. However, I do not agree that the Dev in DevOps does not mean Developers. I also think that by focusing only on upstream activities and teams (i.e. pre-development), you have missed half the issue – the need to also accommodate downstream (i.e. post-release) teams and activities.
I certainly do agree that DevOps impacts more than just Dev and Ops. For example, and directly to your point, I have posted before on how to bring the Project Management Office into the DevOps value chain (http://devops.com/blogs/enterprise-devops/enterprise-devops-project-management-office/). But I have also posted on the need to bring both documentation (http://devops.com/blogs/cloud-based-documentation-speed-devops/) and security into DevOps (http://devops.com/blogs/enterprise-devops/ensuring-security-managing-risk-enterprise-devops/).
So while I like the core of your argument – that we need to think beyond just dev and ops to deliver higher quality applications faster – I think it misinterprets DevOps somewhat, and doesn’t really go far enough.
Andi Mann
CA Technologies.
Andi,
I appreciate the comments. I’ve only been writing about DevOps methodology for a short while, this dialog is educational and I hope will lead to me articulating my thoughts as well as you have done in your writing.
I’m trying to tie back to the archetype set up in The Phoenix Project, where it wasn’t just developers and operations. This really includes every part of the company and every part of the software development lifecycle, I was just focusing today on what I see as the mistake many make of only including software developers in the left-hand side of the equation. I’ll see if I can put together a more complete article on overall organizational challenges sometime soon. In the meantime, I think the real important part is getting the whole company involved in a process of continual improvement, regardless of what you call it.
Agree on this, I’ve found a lot of relatively senior people believing that ‘devops’ is some form of product that can applied from a pure technology view, instead of understand that it’s a people/company transformation more than anything else.
I’m still fairly surprised by how much Brook’s “no silver bullet” is misunderstood (or simply ignored/unknown), perhaps this is also symptomatic of execs not knowing the constraints within their own business [is the assumption that it’s always a limit on deployment speed/acceptance by the operations team?].
As certainly within a few companies I have relatively recently worked within that’s *not* the case and the main constraint was around understanding the viable product definition and what was a MVP (reference Theory of Constraints and optimising the wrong thing).
Re: Andi’s point about ignoring the operations side of the value chain, this is called out a few times regarding non-functional requirements in the Phoenix project, and I agree that they are very often missed/unknown even within large projects but surely that comes back to the Second Way [e.g. ensuring that business requirements and metrics are strongly tied together]
Mike Wallis
Thanks for the comments! I must add No Silver Bullet to the suggested reading list. It is amazing how many people, at all levels, misunderstand the phrase. It’s clearly endemic in non-technical (within the subject material, at least) personnel, but that’s not always a negative. CxOs should not really need to know those details; the fault comes when they ignore recommendations from technical people in favor of hearsay from other sources.
Constraints and optimizations are another subject entirely that I hope to delve deeper into soon.
> the real important part is getting the whole company involved in a process of continual improvement
Now this is something I can agree with! š
It is almost a pity we (as an industry) are getting hung up on the term DevOps. I have a real issue with how DevOps exists within a larger enterprise delivery context, we are in many cases merely shifting the bottleneck. Sure, in many cases Dev and Ops are doing great, working faster, shipping more, running better – but what about the rest of the business? Not a bad outcome for IT, but we need to spread the love!
Andi.