Organizing for success: New DevOps findings to improve speed and agility
For the last eight years, the annual DevOps Enterprise Forum has brought some of the most brilliant thinkers together to help solve the challenges of the ever-changing tech landscape. This year’s forum was a bit different—it included the US Department of Defense (DoD) to discuss the pressures they face in winning the battle of tomorrow. Together they and the enterprise technology experts quickly found the important leverage point: A need for greater speed and agility, not in the technological capabilities themselves, but in the organization of the DoD’s software efforts.
Trent Hone, vice president of solutions architecture at ICF and author of “Learning War” and “Mastering the Art of Command,” was part of the Forum’s research team and co-authored the resulting paper publishing DoD’s software structural issues and the team’s recommendations. We sat down with him to talk about his key findings:
ICF: This paper is a deep dive into DoD—are your findings applicable to a broader federal agency audience too?
Trent Hone: Yes, I think they are. The broader theme was being more effective with your software development in a large organization or government agency. There are certain pressures the DoD faces that other agencies won't, but in terms of conceptualizing a mission, making sure the software team understands the needs of its users, and using economic and time resources efficiently, it’s very similar across agencies.
ICF: What's something you learned during your research?
Trent Hone: One thing that really jumped out was how enthusiastic the participants were about improving things, becoming better stewards of the nation's investments, and catching up to what private enterprises are doing so well. The other thing was a lack of familiarity with how software development can be made most effective. It's typical in a government environment to have a lot of control points: There’s a software engineering team, an operations team, a security team, an external testing or verification team, etc. As you pass through all these checkpoints and handoffs, there are delays and losses of knowledge. There are logical reasons to have all those groups involved, making sure constraints and policies are met, but if it’s not organized right, you can lose a lot of value.
We looked primarily to federal agency CIOs or CTOs or their chief subordinates—the people who establish the policies and organizational constraints that inform how software teams go about their work—and focused on the work environment: How do we create space for these talented software teams to be effective?
ICF: It's clear that operating at greater speed and agility is essential to winning the future fight, as you've raised in the paper. Tell us about the government software “factory.”
Trent Hone: I don't know when or where the term originated, but it's a group of teams that produce and build software to modernize solutions So it's a digital modernization approach. One of the things I find useful about the factory framing is that, when the government is thinking about it, they're not just thinking about bringing some teams together. They're thinking about the broad infrastructure the teams are using, the tools they're developing, where they're working, and how the developer experience can be more effective, as well as that of the end-user—everything that encompasses the environment teams are working in. On the other hand, I think it's an unfortunate description because it brings an industrial concept to mind, and one of the things we draw out in the paper is how they’re different.
ICF: In the paper you talk about how we can help through Outside-In and Center-Out processes. Tell us more about that.
Trent Hone: That integrates users into the process so we can gain the tacit knowledge you only get from being embedded at each step. If you put things in a requirements document, or if it's communicated verbally, there are a lot of pieces that get lost. These are concepts that have been part of the agile process and effective software development for a long time, but we found a way to relate them directly to DoD.
ICF: This notion of thinking about the end result from the start and staying customer-focused was one of the things that really stands out in the paper. Say we’re developing a piece of software that does X, with Y mission objective tied to it—who might the end user be and how might they be folded in?
Trent Hone: Say the Air Force needs a piece of software to find the right plane for a mission. You need to factor in the right amount of fuel, the correct sensors, internal room for people and supplies, etc., and maybe there’s a new kind of plane, or the mission parameters change. In researching the paper, I was impressed with the Air Force’s willingness to take members of the software team to the base so they can sit with the operators and learn directly about the desired outcomes, the environment it’ll be used in, who will be using it and how, and the challenges they’re facing. Those members of the software team can make the changes there and then because of the effective infrastructure in the DevOps pipeline, the Air Force can have the new software in a matter of hours or days rather than weeks or months, and the software team can receive immediate feedback.
One of the things I've enjoyed about working at ICF is that we're already cognizant of all this in the software work that we do. Not only are we making sure the feedback loop is rapid so we have an effective pipeline and new code can be created quickly, but we're also bringing in the user perspective through human-centered design. It’s not that we're at the limits of potential success, of course, but we are in the right regions for this kind of work. It’s not just different for difference’s sake, or just strictly more effective, it’s a much smarter use of time, talent, and computing resources.
Read the full paper here .
