Source:-enterprisersproject.com
In a strong DevOps culture, teams feel supported, collaboration is rewarded, and emotional intelligence runs high. Ask these questions to rate your culture – and keep improving

People like to explain DevOps by first saying what it is not. DevOps isn’t a tool. It’s not something you can buy. It isn’t a team or an individual. Rather, experts and leaders agree: DevOps is a culture; a way of working. The strength of that culture will determine whether DevOps succeeds or struggles in your organization.

Building a great DevOps culture is easier said than done, of course. It starts by knowing what you are aiming for and then ensuring your entire team is working toward culture-specific goals and metrics.As DevOps takes hold, what metrics and trends are expected to improve?

“Culture can be an amorphous and ambiguous thing,” says Matt Poepsel, senior vice president at The Predictive Index. “Leaders can provide tangible support for DevOps initiatives by identifying specific metrics and trends that are expected to improve as a result of introducing new DevOps capabilities.”

To consistently improve your DevOps culture, assess where your culture is at now – and at regular intervals along your journey. Consider these questions you should ask yourself and your team often:

[ Some common DevOps wisdom falls flat. Read 7 pieces of contrarian DevOps advice. ]

1. Are people frequently trying new things?

When DevOps is working well, teams have everything they need to be more innovative, says Daniel Viveiros, CTO at CI&T. They are comfortable with experimenting often.

“In our experience,” Viveiros says, “we found that the new culture helps to foster an experimentation mindset. Moving things to production more often allows your company to test new ideas faster and more effectively.” 

This is one of the positive side-effects companies experience when they take the time to invest in their DevOps culture, says Viveiros.

“Any company that deploys code several times a day understands the importance of breaking down big user stories into small, manageable pieces,” he explains. “This process is very similar to the one used to transform bold ideas in a set of hypotheses that should be quickly validated. Each hypothesis can be developed and deployed for a subset of your customer base. The collected metrics will help define the best next step.”If experimentation is scarce, your team might have an emotional intelligence issue.

If experimentation is not happening at the level you’d expect, you might have an emotional intelligence issue on the team, says Steve Burton, CI/CD and DevOps evangelist at Harness.

“Focus as much on EQ as IQ,” he suggests. “Make sure engineers and operators can give and receive feedback while building a DevOps culture from the ground up. The notion of ‘fail fast and learn fast’ can only evolve if feedback is received regularly and activated by teams. Blame-game cultures are toxic and will divide teams instead of uniting them.”

2. How does the rest of the business perceive DevOps?

How does the work DevOps teams do benefit the business? If your team can’t readily answer this question, you may be creating a culture of “us-versus-them,” says Ben Grinnell, managing director and global head of technology and digital for North Highland.A culture of “us-versus-them” inhibits knowledge transfer.

“So often, companies run these ‘trailblazer’ projects without thinking about the fact that if you want to scale, these projects must leave a trail that others can and want to follow,” says Grinnell. “Trailblazing teams are usually staffed by confident people new to the organization who have done it before elsewhere. They are encouraged to disrupt and break the rules that others are supposed to follow. It’s easy to see how you end up with an ‘us-and-them’ culture, which inhibits the transfer of skills and knowledge.”

Fix this by focusing DevOps teams on business impact, suggests Burton. “Your company hired engineers to build cool things. Make sure those cool things translate to measurable business outcomes,” he says. “For example, do you want your DevOps engineers to be in the business of building tools and automation, or building innovation that your customers can experience?”

“DevOps is not just about releasing software fast. It’s about releasing the right software and value to the clients fast,” adds Eran Kinsbruner, lead technical evangelist at Perfecto. “In order to achieve this goal continuously, DevOps leaders need to ask the following questions:

• Are we focusing on the most important projects to the business?
• Are we using the right technologies to deliver software that works and matches the latest technology advancements?
• Do we have the right visibility into everything that we develop within the DevOps pipeline?
• How can we optimize the entire process, remove waste, save costs, and deliver more flawlessly?
• How can we automate more of the manual processes towards a full continuous deployment process?”

Aligning DevOps teams with business goals comes with other key benefits: autonomy and accountability.

“You can’t expect a DevOps team to have the right culture if they are boxed in with constraints and red tape from surrounding teams,” says Burton. “Autonomy with accountability means engineers are trusted to make decisions fast and understand the impact of their actions.”

3. Who is blocking DevOps?

If you want to build a strong DevOps culture, you must vigilantly look for two types of people: the critics and the champions. Both can make a difference in how quickly DevOps culture scales (or stalls).

[ Are you fighting skeptics? Read also: DevOps for doubters: How to deal with 9 kinds of people who push back. ]

IT leaders have told us that resistance and pushback can come from a number of sources, from engineers who have been burned in the past, to the CIO, to middle managers. 

Mike Bursell, chief security architect for Red Hat, explains one common example of DevOps blocking: “If your organization works on a model where managers are incentivized to build large teams, set specific short-term targets, micro-manage their resources, and just keep accruing larger and larger budgets, then the adoption of DevOps will be an overwhelmingly negative experience for them.”

“They will fight against it, refuse to assign their team members to DevOps projects, and, when pushed into doing so, will attempt to stop them from participating fully in the DevOps process and generally find ways to be obstructive.”