ASWF

One of the reasons I started this blog was to share lessons learned while moving from quarterly to daily production delivery and helping other teams in other contexts learn the same. Not every team got there, but every team that tried had less pain and higher morale with improved outcomes for the business. The improvement in delivered outcomes and quality of life is why I am so vocal about these topics.

Over the years, I’ve seen many people claim they were “doing CD” while ignoring the core practices that bring the benefits of CD.

Build/deploy automation with GitFlow, some unit tests, and manual acceptance testing isn’t CD.
Bypassing the pipeline for a hotfix isn’t CD.
Delivering once a month “because that’s as often as the customers want it” is not CD.

Because I’ve seen far more fake CD than real, my default is skepticism when someone claims to do it. I expect there will be significant gaps or even build automation, and I’m rarely surprised.

The US Army surprised me.

I had the opportunity to visit the US Army Software Factory in Austin, Texas, part of Army Futures Command. I was invited to see what they were doing, compare notes with the teams, and see what we could learn from each other. Army Software Factory has a boot camp program to teach soldiers how to develop software professionally so that they can return to their units and deliver capabilities sustainably in the field.

The Problem to Solve

For decades, the Department of Defense has depended on contractors to deliver approved software. This usually follows the classical waterfall development process followed by obtaining an Authority to Operate. The entire process can take months or years to get capabilities into the hands of the people who need them. The results are often software less than “fit for purpose,” with high costs for upgrades or fixes. This leads to soldiers in the field with self-taught development knowledge writing software that meets the immediate tactical needs of their units. This happens for the same reason that shadow IT exists in many large enterprises: “We need solutions now, and we can’t wait on IT to deliver them!”

Soldiers delivering software for fellow soldiers can result in faster delivery of solutions better tailored to their needs. The people best able to deliver the right solutions are the people closest to the problems. Still, it comes at a cost: developers without the proper training lack the experience to build sustainable solutions. This can lead to mission-critical capabilities being deployed that are brittle and difficult to maintain, improve, and secure.

Transforming Warfighters to Warcoders

To address these problems, The Army Software Factory has developed a dedicated training program to teach soldiers the skills of Extreme Programming, continuous integration, and continuous delivery in a team environment. Their mission is to prototype the future force design. They want to inform the Army how to use developers as a strategic asset through Doctrine. The soldiers in training are meant to support that effort and help spread the knowledge of modern software development to their future assignments. To qualify for the program, they must rank between E-5 (Sergeant) and O-3 (Captain). When accepted into one of the program openings, they spend several months learning basic development skills before joining a platform or product team. The soldiers come in with little or no development experience. They are taught basic language skills and how to work on a modern development team using techniques such as TDD, trunk-based development, continuous integration, and continuous delivery.

From there, they spend the remainder of their two-year training cycle delivering real software while honing their skills. Each team owns a specific product domain and owns their outcomes. Because this is the DoD, security and compliance are also critical. To that end, security and compliance teams work with the development teams to help them achieve those quality goals too. They enable security and compliance rather than policing for them.

After the first year, the soldiers are given a technical assessment with two opportunities to pass. If they fail to pass twice, they are removed from the program. At the end of the program, successful graduates move on to their next assignment. Some will join development efforts in their next unit. Some of the officers will go on to lead existing or new development teams, and some will return to their previous units. The latter may not be developing, but they will be better-informed consumers of the systems they use and be able to provide better feedback to the people creating them.

Marketing or Reality?

I visited for two days and interviewed several of the soldiers from product and platform teams, plus the leads for security and compliance. I dove into the details to probe for gaps in their processes. With most teams I’ve talked to in the past, it’s not difficult to find common problems. No slight to those other teams, but it’s hard to be “good” if you’ve never seen “good.” In this case, I struggled to find low-hanging fruit that could be fixed. I had some suggestions for improving the workflow around code review and work refinement, but these were more optimization than critical changes to make.

Developers reported integrating code into the trunk several times per day. Most teams received frequent and rapid feedback from the field. Some teams were working on solutions that required app store-type distributions and had slower feedback, but they did work to get people with domain expertise involved with using it in staging to get the best feedback possible. It was impressive, and I’d happily join any of their teams to maintain the low-drama delivery environment I prefer.

Challenges

Nothing is perfect, and since the Army Software Factory is part of the US Army, utopia was never an option.

In 2024, Army Futures Command made the decision to reduce the program timeline from three to two years due to the intense demand from across the Army for the capability they are delivering. This means a soldier will spend 18 months on a team after their coding boot camp instead of 30 months. That loss of a year of hands-on experience is significant, but hopefully, the disciplined training process they use will still provide them with the experience they need to help drive change.
They are teaching new developers how to do this correctly. The challenge is that most other organizations don’t know how to do it correctly, much less incentivize teams to work that way. The hope is that the graduates can influence change. To do that, they’ll need some exposure to how bad things can be elsewhere and how to communicate “this way works better.” I worry that some may become disheartened if forced to work the way many teams (even in the private sector) work.
The officers graduating from the course must understand how to communicate this way of working to their superiors to influence change.

I spoke to a Captain whose next posting was leading a software modernization effort. He asked if he should discuss “agile” or the “Pivotal model” with his new leadership. I told him that under no circumstances should he discuss those. Leadership won’t care and may even be hostile to buzzwords. Understand the problems your leadership is trying to solve and be able to explain how improving the logistics of software development can help solve those problems.

Building the Future of Army Software

The program the Army has built is truly impressive. It has been operating as an experiment for several years, but the value has been recognized. As of January 2025, the Secretary of the Army has directed the formation of a new career field for “Software Operations” based on the ASWF model. This is a hard-won win and speaks to the value the Army sees in owning the outcomes of their software and using modern software engineering methods to deliver it. I hope the rest of the DoD recognizes the value and follows the Army’s lead.

The US Army is Beating You

Your organization probably has less bureaucracy and inertia than the US Army. What’s stopping you from modernizing your software engineering? All it takes is finding good information, a willingness to change, and replacing fear and stagnation with curiosity.

Resources:

The ASWF isn’t using a framework because frameworks solve someone else’s problem. They are using the same methods you can find in these books.

Blog Home

How The US Army Modernizes Software Engineering

Related Articles