Can DevOps Apply to Everyone? – InApps 2022

DevOps Power Panel: Can DevOps Apply to Everyone?

Also available on Apple Podcasts, Google Podcasts, Overcast, PlayerFM, Pocket Casts, Spotify, Stitcher, TuneIn

It remains a fact that most enterprises do not retain their own software developers. Indeed, there are major institutions today whose IT operations leaders have never actually met the people who wrote their software, or know whether they’re still alive. And throughout the Southeast Asian region, software developers are often hired on contract, produce their work in one lump sum, and wait to get paid once it’s installed, tested, and approved. There, the benefactors don’t expect to need that software to be replaced for at least another five years, in some cases as high as 15 years.

Some IT ops professionals perceive the idea of software development automation with daily release cycles as foreign a concept to their own way of work as, say, replacing their manufacturing lines with molecular manipulators that could produce fully functional bulldozers out of compressed peat moss. DevOps may be an indicator of the directions that institutions and enterprises must evolve to stay relevant in the long term, but how many iterations of change will they require before they can declare themselves, technically speaking, “there?”

“At Capital One, we have a very clear vision on where we’re going in the industry,” said Chafin Bryant, the financial services provider’s senior software engineer, in a panel discussion for InApps Makers podcast. “Within my team, on a more detailed level, we are working in concert with some of our peers in the organization to develop some kinds of earmarks, or maturity tenets, as we’re calling them. I think the synchrony there comes down to not saying we all have to be consistent, but it’s saying, we all want to be on the same page, and let’s try to identify those things we want to do well? … We’re separate teams, we’re going to work in different ways, but we’ve tried to say at least for our group, what are those things that, for our group, we can look objectively, for the most part, and say, ‘This is the best way to do this?’ Because once you solve that approach one time, you can scale that.”

Bryant’s approach seems workable for a large organization where there may be a multitude of possibilities for finding alignment. How about for a small one?

“I think [having] a smaller number of teams, and a smaller number of people per team, has its advantages and disadvantages,” explained Richard Knechtel, a team technical lead with Wisconsin-based Church Mutual Insurance — which, like its name says, is an insurer of churches.

“The advantage is, you’ve got less people who are vying for resources,” Knechtel continued.  “At the same time, you also have a smaller number of resources that are available. So we have multiple teams that are all working on their own release cycles and release cadences… Many times, there are certain things like in our Shared Services area where different teams have to make changes to the same shared services. So there gets to be times when teams start stepping on each other. That gets to be a challenge sometimes for us. But as we’re growing as an organization, it’s becoming more clear that we need to get a lot more coordination, and more things synced up, and more standardization.”

For example, Knechtel’s organization has begun a Java community of practice (COP), where developers may submit ideas that become evaluated by the community as a whole. There, initiatives have already begun for standardizing processes among the various development teams.

Knechtel and Bryant are joined by JFrog Developer Advocate Baruch Sadogursky and SignalFX Executive Vice President Leonid Igolnik, for a wide-ranging discussion about applying automation to organizations in stages. Listen now to this special edition of InApps Makers, inspired by a session Sadogursky led during CloudBees’ recent DevOps World 2018 conference in San Francisco.

In This Edition

9:59: An example of QA in the DevOps transformation.
15:55: Why people are afraid of the journey to DevOps culture.
26:38: Does ownership present an obstacle to you being able to automate processes or eliminate them?
30:32: Exploring the “water-scrum-fall” of the development cycle.
34:09: The importance of self-assessment in the development process.
47:11: Is there any kind of communication that can help that process?

CloudBees is a sponsor of InApps.

Pictured counting clockwise from upper left: Baruch Sadogursky, JFrog; Scott M. Fulton, III, moderator; Richard Knechtel, Church Mutual Insurance; Leonid Igolnik, SignalFX; Chafin Bryant, Capital One.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: JFrog.