Blog > DevOps Accelerates Delivery to Market – Why Isn’t My Team Excited?

DevOps Accelerates Delivery to Market – Why Isn’t My Team Excited?

In my career, I’ve been exposed to any number of initiatives in the enterprise intended to effect change and shift paradigm to improve outcomes. The list is long, including things like business-process re-engineering, entity-relationship modeling, mission statement generation, joint application design (JAD), rapid application development (RAD), The 7 Habits of Highly Effective People, quality function deployment and the house of quality, Six Sigma, and more. (Yes, I am glancing across the titles of books and binders on one of the dustier shelves in the bookcase.) All have had their merits, while none has ever been the panacea or endpoint executives might have hoped, and each contributed in its own way to the better day the enterprise now enjoys. Out of all of initiatives I’ve been fortunate enough to receive training on, only one has maintained a perennial spot on my desk – one of the cards from Roger von Oech’s Creative Whack Pack[1] – Expect Resistance:


This is a long way around the mulberry bush and a lot of citations to reach the theme of this piece:  If DevOps is so wonderful, why do some [or all] of my team resist it? I’ve written several blogs in recent weeks on DevOps in the enterprise and the importance of marshalling resources and technology to focus on end-to-end automation of mission essential value streams, and some of the readers have come back with that question.


  • “My engineers tell me they are ‘full stack’ developers and participating in DevOps will only slow things down.” 
  • “DevOps is just a methodology and we already have one.”
  • “DevOps is fine for start-ups that don’t have established processes – our processes work just fine.” 
  • “Our value streams must use the mainframe for some of its needs, and DevOps doesn’t support mainframe.” 

All of these comments both reflect the knee-jerk resistance anyone will have to change they don’t initiate themselves and, to vary degrees depending on context, reasonable objections that don’t in any way detract from the value DevOps can provide to the enterprise.


As with any imposed change, securing support & cooperation requires the application of professional empathy. Frequently, the most valuable and productive technologists in an organization are not necessarily those that work the longest hours, but those that are the most experienced and educated – they are on top of their work and can complete it with relative ease, and maybe have time left over in a day to update Facebook or look at their fantasy league. Requiring them to adopt a new work model disrupts that comfort zone, triggering the resistance reaction before critical thought is engaged. That last part is a critical key to moving past the initial resistance – engaging critical thought so the individual is actively involved with the transition, instead of a passive victim of it.

One of the best ways to achieve this with analytical thinkers, as many in software development and IT operations are, is to ask what is needed to make the new methodology work better or work at all. Very frequently what will be voiced is the need for automating the activity of all the tools in the DevOps toolchain for seamless end-to-end management. This must include not only the traditional DevOps tools for development, test and deploy, like Jenkins, but other critical enterprise infrastructure automation, as well, such as native integration with:

  • ServiceNow for operations needs during development phase and then during deployment phase
  • Enterprise privileged access managers (PAM) for credentials required during develop to grant APF authorization on the mainframe or root access on a UNIX Server and, as above, when needed during the production execution of instances of the automated value stream
  • Enterprise scheduling both for the DevOps value stream itself and, more importantly, the run-time execution of the automated end-to-end value streams, across the many technology silos required including the mainframe

As your team voices critical, creative, constructive thoughts like these, they begin to move from the posture of resistance to the posture of engagement and even excitement. Moreover, you are assured these thoughts can be actioned, directly and easily, by relying on ASG-Enterprise Orchestrator for both the development toolchain orchestration and scheduling, and the run-time production instance workload automation, from a single platform. To learn more about the latest release of ASG-Enterprise Orchestrator and the range of Development, Operations, and QA integrations it offers, please contact your ASG representatives, or tweet me at @jcherrington.


Business process re-engineering (BPR) is a business management strategy, originally pioneered in the early 1990s, focusing on the analysis and design of workflows and business processes within an organization.
An entity–relationship model (or ER model) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between entities (instances of those entity types).
A mission statement is a short statement of why an organization exists, what its overall goal is, identifying the goal of its operations: what kind of product or service it provides, its primary customers or market, and its geographical region of operation.