In the last two episodes of the ContinuousX Podcast, hosts Rick Stewart and Mike Fitzurka spoke with James Edmonds, the Project Manager for Kessel Run’s Dagr application, about how DevSecOps has impacted the organization’s culture, and how the organization, as a whole, is “winning at software.“
In their third and final episode with James, the ContinuousX crew asked about the challenges that Kessel Run faces, and some of the ways that a DevSecOps approach creates challenges for the organization. They also asked James about the importance of teamwork and collaboration within and across teams and organizations, and how that impacts Kessel Run’s ability to deliver applications for the Air Force.
Transcript: ContinuousX Podcast (Season 2, Episode 7) with Kessel Run’s James Edmonds
Rick Stewart: Hello and welcome to another ContinuousX episode, where we “Search for X in the SDLC equation.” We’re back with Jim Edmonds. Jim is the product manager for Kessel Run’s Dagr application. It’s an operational unit-level intelligence application. So, Jim, many public sector agencies are attempting to move towards DevSecOps for software development and delivery but have yet to have any operational success. Kessel Run has operational services up and running. Can you help provide any insights to our audience through your services and challenges and overcoming them with DevSecOps principles?
James Edmonds: I think in my time working with Kessel Run as the Dagr product manager, one thing that I’ve seen is that they have been successful in getting capabilities out because from the very beginning they understand the importance of the different teams working with one another. Very much.
They’re providing a facility. They’re providing the tools. They’re providing the environment for security checks. And they’re allowing teams to do their design, their development, and deployment in a nice seamless approach. But more than that, they recognize, again because they’re a unit focused on the mission, their overall mission is airpower. Planning, conducting, and assessing how airpower is done. Everyone within that umbrella recognizes to be successful individually, we have to work with one another.
I mentioned in a previous segment, that I think one of the concerns or challenges I’ve seen happen with other teams and other DevSecOps environments is sometimes not an appreciation of the larger ecosystem. In an old waterfall approach, you might be thinking of information exchange requirements, JCIDS documents, those were all documented in requirements documents.
Those kinds of artifacts don’t always accompany a DevSecOps environment. You don’t always recognize until it’s maybe too late, that there are inputs and outputs from other customers, other applications, other systems. And if you don’t do that more strategic view at the product level, portfolio level, and product-line level, you might fail to meet that mission. So, you could still have the tools, you could still have the overall skilled designers and developers, that are following all their practices that you would expect an Agile/Lean activity to do. But operationally, you still have to understand the overall big picture. And it’s one of the things to see.
I’m a huge advocate of user-centered design. I believe that you ought to be talking to the users every day. But I think it’s equally important to make sure you understand and talk to the stakeholders, the people at the higher headquarters. Our military services are assigned to organize, train, and equip forces, not just provide an application but to provide general capability of airpower.
The United States Air Force, the Chief of Staff of the Air Force, expects to dominate in the air power. So, what you’re selling to them has to meet a larger capability requirement. I think when you’re doing DevSecOps, you operate at a small level. You do design and you build features with the user in mind. But it’s important, never to lose sight of that 70,000 foot level view of the target you’re trying to accomplish, by seeing the more holistic capability you’re supporting, or you’re having some kind of interface with.
As an intelligence application, we obviously are affected by what happens at the combat support agencies within the intelligence community. We’re obviously affected by what happens at the command-and-control level that Kessel Run has more say on. We’re affected by other agencies, like mapping agencies and things like that. Dagr has to be mindful of all those.
So, when we’re working with a specific thing that a user told us to work on, I’m trying, and my team is trying to factor in how we’re going to provide all those services. How’s the intelligence data going to feed? How’s the operational and meteorological data going to feed into this whole capacity? I think with DevSecOps, there’s nothing wrong with that process. I think everyone can be successful on it, as long as you keep your mind on the big picture as well.
Michael Fitzurka: I think you touched on that, again in the last episode, that you also have the teams working together and you may solve a problem that helps another agency. And you don’t get that if you’re working in silos. You get that when you’re working and thinking at a higher level in a more strategic way across the board.
James Edmonds: Right. It’s hard to look at the overall big picture. You don’t always know what the puzzle box top cover’s going to look like, but you need to be mindful. You’re a part of puzzle of that 10,000-piece puzzle, you’re a piece, your application is. I think within my portfolio, my product line, they’re really good about teaching everyone on the team about the operational environment.
We read professional journals, not only on how to do software development, and better understanding the operational imperatives, we make people read doctrine. We make people read tactics, techniques, and procedures. See videos and how the military’s doing it. Because the interviews you have with the users, especially when it’s at their locations, can give you a feel for that. But even sometimes the young airman, the young officer on their first assignment, they may not have the experience of knowing all the things that are happening around their base or where they’re deployed. They don’t maybe understand how joint warfighting is actually conducted. So, they depend on you to do that kind of thinking for them and knowing that the app is doing things they never even asked it to do. They didn’t even know to ask them.
Rick Stewart: I think what makes Kessel Run, and your program Dagr, unique across the public sector is the cultural organization and hierarchy has bought into that culture where there’s no hierarchy per se, that the lowest common denominator, the resource working on that, has as much say as maybe your commanding officer, within reason. And that open dialogue, that open culture of communication, really provides a better product or service, because it’s not dictatorial, and you’re listening to people actually in the field, getting real time data, in order to re-evaluate your features and what you’re working on.
James Edmonds: Right, absolutely. Our commander and the organization, as a whole, believe that it’s not the rank on the shoulder of the airmen or the arm of the airmen that matters, it’s the content of their ideas, and what they bring to the table. And everyone in the organization from the top on down adheres to those principles and that culture. What you bring to the table is what’s most important, and it’s one of the things that working at Kessel Run is so rewarding.
Rick Stewart: Terrific. Well, thank you very much, Jim again for your time and your efforts. And thank you for your service on behalf of the taxpayer, and the US citizens. We really appreciate all the work you’re doing with Kessel Run. From an IT perspective, it is really great to see momentum and adoption of DevSecOps in the public sector. And thanks to your listeners for listening to our multiple episodes with Jim, feel free to go back if you haven’t listened to a previous topic with Jim, feel free to do so, as we “Search for X in the SDLC equation.”
