How to Keep DevSecOps Teams Motivated

Agile and DevSecOps leaders in the federal government prioritize cultural overhaul and data-driven decision-making to succeed.

Mandy Moore, deputy director for the Office of Application Engineering and Development at the U.S. Patent and Trademark Office (USPTO), said federal agencies shouldn’t be worried about implementing “the next big thing in IT.”

“The main goal here is to form that strong business and product team bond, and that team is responsible for the full backlog of work relating to these projects,” she said during GovernmentCIO Media & Research’s Disruptive DevSecOps event this week.

Moore said focusing on cultural transformation at USPTO helped break down silos of communication and data between the development, operations and security teams.

“I think it’s really about focusing on culture change and instilling that belief that it can be done,” she said. “Making an effort and commitment to showing incremental improvements and taking small steps and smaller teams and showing that even without impressive automation, you can achieve autonomous teams doing DevSecOps. Sometimes it’s about getting the collective to believe the change can happen.”

Florence Kasule, director of procurement at the U.S. Digital Service (USDS), suggested federal agencies use the acronym CALMS to guide the shift to Agile and DevSecOps.

“CALMS stands for culture, automation, lean, measure and share,” Kasule said during the event. “Making sure your teams are as collaborative as possible and user-centered … trying to get as scrappy as you can and making sure your teams are working closely together, figuring out the problems on both sides. Measure being making data-driven decisions, so there aren’t assumptions about why the development or security or operations teams are doing something. What is the data, what is it showing you? And then sharing information as much as possible in order to meet shared goals.”

Kasule also recommended constant communication and open feedback loops to ensure problems get addressed quickly. Like Moore, she stressed breaking down silos between teams in order for a DevSecOps strategy to succeed.

“Blended teams are critical to making this work,” Kasule said. “You can’t work separately during a vacuum in this kind of model.”

Defense Information Systems Agency’s Services Development Director Brian Hermann and Lindsay Young, an 18F team member for Digital Service Delivery at the GSA, said federal agencies should keep the end goal of their production processes top of mind in order to create a successful Agile culture.

“As far as implementation, I think it’s really important to keep your focus on those big goals,” Young said. “Sometimes you can add some Agile-sounding meetings to your waterfall scheduling, and that doesn’t give you any benefit. It will give you more meetings. When you’re thinking about Agile, ask yourself, what have we learned from building and testing so far? You should be learning all of the time.”

Helping teams connect the dots between their work and the value they provide can help with this.

“When our teams are disengaged and not feeling that sense of mission and accomplishment — we can’t do Agile for Agile’s sake,” Hermann said.

Besides accelerating software production cycles and helping make them more secure, Hermann is optimistic about the ways DevSecOps can fortify IT security at the Defense Department.

“I’m especially excited about the synergy between DevSecOps and cloud hosting,” Hermann said. “It enables us to instantly deliver that capability. Figure out if something’s wrong, roll back if necessary, but keep moving forward. If we host things at the enterprise using cloud, we have a known capability, a known constantly updated cybersecurity status. That value alone provides some interest for the rest of the leadership in DOD because security is a huge issue for us.”

Understanding what the value is in your DevSecOps approach and encouraging information-sharing so as to make better data-driven decisions are overall keys to successful implementation.

“The No. 1 thing is value,” Young said. “You want your technical decisions to be driven by the value seen by the people using the products. It also might mean you want to try something that isn’t as shiny.”