Media Query Source: Part 15 The Modern S/W Factory Hub (CA Tech blog)Debunking 3 myths of DevOpsDevOps means dev & operations not separateReasons to a
My responses ended up being included in an article at "The Modern Software Factory Hub" by CA Technologies (October 23, 2018). Extent of verbatim quote highlighted in orange, paraphrased quote highlighted in gray. Note that Broadcom completed the acquisition of CA Technologies about 3 weeks after this article was published, on November 5, 2018, and that this article seemingly wasn't archived by The Wayback Machine here.
Media: Myth 1. DevOps Is a Technology.
Gfesser: DevOps is related to the way work is done, not the specific tooling that is used to do the work.
The idea here is that development and operations work is performed by the same individuals.
Working in this way enables efficiency because developers do not need to go to a separate operations group to procure or deploy.
In addition, working in this way enables effectiveness because developers are close to the work being done on a given software product.
Traditionally, operations teams are separated from the actual software development work, so developers often need to walk them through all the steps that need to be done for deployments.
When developers are empowered with the ability to procure what they need, associated turnaround time is typically much shorter because developers can move forward with no procurement related blockers.
In some enterprises, unfortunately, development processes are often seen by management as being equivalent to the tooling being used.
The problem with this outlook, however, is that while tooling can enable development processes, the reality is that this is often not the case.
A DevOps culture typically simply needs to be cultivated as part of adoption in order to fully take advantage of the tooling.
It is a myth to think that adoption of specific tooling is going to automatically result in adoption of appropriate DevOps processes.
In order to be effective, for example, DevOps needs to be embedded within development teams so that they are self-sufficient.
I've seen departments at some firms dedicated to what managers call "DevOps", but the problem with such departments is that these are typically just operations without development.
Media: Myth 2. DevOps Leads to Fast Improvement.
Gfesser: Effective use of DevOps can take some time to implement in firms which make use of separate teams or departments dedicated to development and operations.
The challenge with such traditional shops is similar to changes in other aspects of corporate culture, since over time all work tends to revolve around long-used processes.
It needs to be remembered that all shops have processes regardless of whether they have been explicitly defined, and prior use of agile processes tends to help enable subsequent adoption of DevOps.
While it can be argued that agile processes and DevOps go hand-in-hand, it is typical for traditional shops to first take time to move to agile processes.
As with agile adoption in general, firms interested in DevOps should plan to adopt in a series of steps: start with a limited POC with a small subset of developers, and increase scope over time.
Media: Myth 3. DevOps Must Be Expensive.
Gfesser: In the long run, effective use of DevOps should be expected to save money, but the reason for adoption shouldn't be limited to cost.
The reality is that DevOps should bring about software product improvement over time; if a firm doesn't see this happening it should reevaluate how it is going about use of DevOps.
DevOps should provide returns around how software is iteratively written, tested, and deployed, and as a result typically brings about increased developer satisfaction.
See all of my responses to media queries here.