Continuous delivery and deployment are key tenets of a DevOps approach, but there's another critical component not to be overlooked – the Continuous People Pipeline. Jayne Groll, co-founder and board member of the DevOps Institute, will discuss why it's so important for teams to recognize their contribution to the value stream at the upcoming DevOps Enterprise Summit, Nov. 7-9, in San Francisco.
We spoke with Groll to find out more about the role of culture in DevOps, and what IT leaders can do to set their teams up for success.
The Enterprisers Project (TEP): Why do you think culture is such a critical aspect of adopting a DevOps approach?
Groll: People are the most important ingredient in the recipe for DevOps success, and people shape culture. The Business Dictionary defines culture as “the values and behaviors that contribute to the unique social and psychological environment of an organization.” So essentially, it is how people think, feel and interact within their organization that will profoundly affect how that organization performs.
TEP: What are some of the most common cultural barriers to adopting DevOps?
Groll: IT has historically been organized internally by silos of staff with the same expertise. Each silo has its own vocabulary, practices, tool and even culture. Many of the silos are geographically dispersed, even within the same silo. IT silos were created primarily for HR, management and organizational chart purposes but have often become major obstacles to a faster flow of work within IT to the business.
TEP: What can IT leaders do to change the culture in their organizations?
Groll: While reorganizing IT from an HR perspective may not be possible or reasonable, leaders can certainly create an internal culture that reflects more of a flat organization where navigating silos is easier and less bureaucratic. Similarly, the definition and membership of a “team” could shift from like-skilled members to cross-functional members from different areas of expertise. For example, members of traditional Scrum teams are mostly developers. Why not put Ops or QA staff on Scrum teams so that they can shift some of their responsibilities and readiness to the left? Similarly, creating custom vocabularies, shared accountabilities and leveraging common tools reduces costs and increases collaboration.
TEP: Are there other "people" considerations for IT leaders as they begin their DevOps journeys?
Groll: It is important to recognize and respect that people will absorb and accept change at their own pace. Some will buy-in on faith and others will buy-in on proof. Too much change too quickly will create change fatigue. Poor communication will create change resistance. Training, messaging, feedback loops, ChatOps, change agents and other opportunities for people engagement will help move people towards acceptance and organizational agility.
