software development. It reduces documentation burdens, encourages modern engineering practices, and promotes cross-functional collabora- tion. However, implementation chal- lenges remain. SWP programs may be procedurally agile, but they often operate in ecosystems constrained by legacy contracting, cybersecurity, testing, and oversight models. Pro- gram offices enjoy flexibility, while enabling functions continue applying traditional, compliance-first models. The DoW began incorporating agile practices more than a decade ago. Programs like the Air Force’s Kessel Run demonstrated that embedded development teams, con- tinuous integration pipelines, and close user collaboration could dra- matically improve delivery tempo and user relevance. The Army Software Factory and the Navy’s Black Pearl initiatives followed similar models, embedding development within op- erational contexts. Yet, while these programs have shown promise, many agile efforts across DoW still face headwinds. For instance, in a midtier Navy system modernization program, develop- ers successfully adopted two-week sprints, but release timelines were repeatedly delayed due to end-of- phase cybersecurity reviews. Despite using modern DevSecOps tooling, the program could not receive authority to operate until multiple stakehold- ers—who were not embedded with the team—reviewed static documents offline. This disconnect neutralized the speed agile could offer. Leadership in an agile context must shift from passive oversight to active enablement. Army Gen. Norman Schwartzkopf once said: “Leaders do not deal with how to get the job done; they surround themselves with talent and then allocate resources and re- move roadblocks to enable the talent to excel.” His approach applies equally in industry and government. From Oversight to Enablement
Yet, many government leaders have internalized a model of leader- ship based on oversight and risk aver- sion. General officers, SES executives, and senior acquisition professionals often see themselves as approvers of outcomes rather than co-owners of delivery. This mentality, while suited to hardware programs built around milestone reviews, is incompatible with agile software development. In Scrum, leadership must be present, available, and engaged within the sprint cycle. The longer decisions are delayed by hierarchy or distance, the more velocity and morale suffer. In practical terms, this means that functional leaders must adapt their posture. Cybersecurity professionals must move from checklist-driven in- spections to continuous collaboration with development teams. Test and evaluation experts must align their work with iterative delivery cadences rather than rely solely on milestone- based assessments. Contracting of- ficers must structure agreements to support modular delivery and evolv- ing requirements. Effective agile leadership does not equate to reduced accountability; rather, it represents a distinct ap- proach to engagement. For example, a flight engineer continuously monitors
and adjusts performance in real time, in contrast to an airport inspector who evaluates only after the journey is complete. Similarly, program lead- ers are akin to stage crews and focus on ensuring smooth execution rather than post-event outcomes critiques. Agile leaders serve as coaches instead of referees, emphasize the teaching of core principles, provide ongoing guid- ance, and respond promptly to devel- opments as they arise. What Happens Without Enabling Leadership In contrast to high-performing agile programs, many DoW software efforts still resemble their hardware- centric predecessors. In one such ef- fort, leadership insisted on quarterly milestone reviews before authorizing code deployment. The result was a sluggish release pace that frustrated users and demoralized developers. Features that could have been tested within days by real users sat idle for weeks awaiting approval. The failure was not in the agile tools; it was in the lack of empowered leadership. This failure often stems from a deeply rooted belief among senior leaders that their role is to evalu- ate outcomes from a distance. In a hardware-centric world, that mindset
30 | DEFENSE ACQUISITION | November-December 2025
Made with FlippingBook - Online Brochure Maker