“Today, there is a disconnect between startups and older companies when it comes to software engineering,” he said. “A lot of companies are still doing engineering delivery like 1800s manufacturing was done. It’s a croft-based system, parsing work out to different teams. We want to help non-tech companies think about the cultural transformation. It’s not just about moving to the cloud and installing Docker.” To come up with a solid and repeatable plan for how to start with DevOps, Duffy and Schoonover met with 150 “high-performing” software development teams and wrote down their observations on sticky notes. They winnowed their notes down to 15 capabilities, each with four stages, Duffy said. The idea is not to overwhelm an organization, but to get clarity on what matters most and then move forward.
“We try to get to a small set of very actionable items that we helped select that justify the ROI calculations and case studies,” Duffy said. “We help companies recognize the size of the problem and attack it in small identified chunks to gain credibility with the business.”
DevOps as a continuum
Speaking to a senior engineering manager at a defense contractor who asked not to be named, the large number of legacy and custom hardware in software installations complicates the idea of how to start with DevOps.
“We want to look at software development as a continuum. But at one spectrum, we have the low-hanging fruit that it’s easy to see how to make changes to, and on the other spectrum we have custom hardware and software that is not low-hanging fruit,” the manager explained. “We want to have the same kind of systems in place for both so that we can have CI and CD running. That’s the area we’re a little concerned about.”
But so far, that “how to start with DevOps” process has worked, the senior engineering manager said, because the Sodo team doesn’t just point out the issues, but works alongside the team to solve them.
“Our CTO has realized he can really get some quick wins — with management — using the terminology Sodo uses,” he said. “Our developers can be finicky and judgmental, but they took to the Sodo team right away. They don’t come in with the idea of knowing everything.”
The Sodo team has already been asked several times, “Can you just deliver this project?” but Duffy stressed he and his partner are more interested in teaching companies how to start with DevOps. “Patience is important, but so is momentum,” he explained. “Something shipped out the door is really what we preach.”