Coaching for Better (Software) Buying Power in an Agile World

To print a PDF copy of this article, click here.

Author: Martin Brown

On Nov. 13, 2012, Under Secretary of Defense for Acquisition, Technology and Logistics Frank Kendall unveiled his guidance for improving efficiency and productivity under the Better Buying Power initiative. Better Buying Power 2.0 (BBP 2.0) identifies 36 initiatives under seven focus areas with all being applicable to the acquisition of software and systems.

The extension of Better Buying Power, coupled with ongoing initiatives to improve the acquisition of information technology (for example, Defense Science Board 2009, Section 804 of the 2010 Defense Authorization Act), should lead acquisition professionals carefully to consider incorporation of agile methodologies into the set of acquisition tools at their disposal. This transformation is not easy. It requires a change in how we look at programs. Therefore, DoD should consider the use of “Agile Coaches” to assist in this shift. Ideally, the agile coaching corps should be internally grown and assigned to acquisition organizations with a cadre centrally located as DAU consultants available to support any and all acquisition programs.
The 12 agile principles supporting the “Agile Manifesto” are closely aligned to six of the seven focus areas of BBP 2.0 as shown in the following paragraphs.

This transformation is not easy. It requires a change in how we look at programs. Therefore, DoD should consider the use of “Agile Coaches” to assist in this shift.

Achieve Affordable Programs

Agile places the highest priority on satisfying the customer through early and continuous delivery of valuable software. Unlike the traditional waterfall method that delivers at the end of a long process subject to schedule delays and cost overruns, the agile process focuses on delivering the customer’s top priority functionality first and continuing to update development plans so that the customer continuously gets what he or she wants the most. From an affordability perspective, the agile process stays within cost and schedule constraints but varies the features delivered within those constraints. An agile program can be stopped as the planned funding limits or timeframes are reached, and the customer will have already received the most valuable set of capabilities.

Cost Controls Throughout the Product Life Cycle

In addition to the focus on satisfying the customer described above, three additional agile principles support this focus area. Agile methodologies call for continuous attention to technical excellence and good design to enhance agility. Agile understands that these factors cannot be completely designed up front. Instead, agile processes address technical excellence and good design throughout the design, development, test, and support phases of the product life cycle.

050613-article-9-secondary-1Agile methods include the concept of technical debt, which, simply stated, is the increased cost of change due to poor, inefficient code or due to the backlog of unresolved defects allowed in the system. A good agile team will plan on regular refactoring efforts to ensure that the software conforms to high standards. Agile also focuses on frequent and regular delivery of functioning software reflecting top user priorities. Therefore, it is easy to equate costs to functionality and user value throughout the development process. A key principle of agile is simplicity, defined as the value of the work not done. The concept of time-boxing when coupled with the principle of simplicity focuses agile development on delivering functionality the user asks for—no more, no less.

Incentivize Productivity and Innovation in Industry and Government

Agile methodologies support the close alignment between profitability and DoD goals through the frequent delivery of working software that address top warfighter priorities. In an agile environment, incentives can be directly tied to the early and regular delivery of working software. Agile also focuses on harnessing change for the customer’s advantage. This means that, as acquisition professionals, we need to assess how and when requirements are set in concrete. This also means we need to think about how we contract for capabilities. In an agile world, we can think in terms of fixed-price or fixed-price incentive contracts if we fix the price of a sprint (using an agile term for a short duration iteration) then buy a number of sprints as an option if the contractor meets promised velocity. This strategy allows both the government and the contractor to be responsive to changes in requirements or user priorities.

In an agile world, we can think in terms of fixed-price or fixed-price incentive contracts if we fix the price of a sprint (using an agile term for a short duration iteration) then buy a number of prints as an option if the contractor meets promised velocity.

Eliminate Unproductive Processes and Bureaucracy

Agile has a principle called simplicity that is the art of maximizing the amount of work not done, that captures the essence of this focus area. Traditional information technology acquisition follows a sequential, stovepiped waterfall process that results in a large amount of “work in progress” throughout the development effort and delays delivery of functionality to the end user until the end of the effort. Agile believes that DevOps, the process of warfighters and developers working together throughout the project, is superior to volumes of detailed documentation subject to misinterpretation—or worse, nonuse—and results in early and frequent delivery of the capabilities the user needs. Simplicity also comes into play here in that developers, working closely with warfighters, can accurately identify when a capability is good enough. If 20 percent of the effort can deliver 80 percent of the functionality and the warfighter is happy, the Department is better served if the remaining funds are allocated where they can address the most pressing needs.

Promote Effective Competition

This starts with establishing the government as the product owner and ensuring that the government owns the functional and technical vision. For afloat forces in the Navy, we expect software capabilities to ride on the Consolidated Afloat Networks and Enterprise Services (CANES) infrastructure. ­Contractors follow well-defined software development standards designed to promote interoperability and avoid proprietary code from creeping into deployed systems. It also means the government program offices need to clearly define the desired government technical data rights.

Improve the Professionalism of the Total Acquisition Workforce

The DoD needs to invest in training the acquisition workforce in agile methodologies to add tools that can be used effectively when appropriate. The Department also needs to look at organizational structures and relationships that promote the values identified in BBP 2.0. Operational commands need to understand their role in defining priorities and working with the acquisition agencies to ensure their voice is heard throughout the development process.

One of the most fundamental changes is in how the Department manages requirements—or, as they are referred to in an agile environment, features. The incremental, iterative evolution of requirements throughout the life of a project calls for active participation instead of the frequent practice of throwing the requirements over the fence and waiting years for results. Acquisition professionals need to learn how to manage features (large blocks of functionality) and user stories (detailed requirements) instead of tasks. At senior levels, we need to think about how we manage and assess the effectiveness of investment strategies.
In the preceding paragraphs I discussed how agile principles support the BBP 2.0 focus areas.

Now I want to focus on the transformation to agile.

The first question always is, “Why?” Version One, a leading provider of tools supporting agile development, conducts an annual State of Agile Survey. The results for 2011, based on more than 6,000 responses, indicated that the ability to manage changing customer priorities (cited on 84 percent of respondents) replaced improved productivity (75 percent) as the leading reason to be agile. Equally surprising was the fact that project visibility (77 percent) moved into the second position, indicating that senior decision makers are getting the information they need from agile projects.

050613-article-9-secondary-2A number of agile programs currently are being executed within the DoD environment. The DoD even has a draft Agile Handbook (Mitre Technical Report 100489) that identifies both the advantages and barriers a program faces as it tries to adopt agile methodologies. The Government Accountability Office (see GAO Report 12-681) was asked to “identify (1) effective practices in applying agile for software development solutions and, (2) federal challenges in implementing Agile development techniques.” Both documents contain specific recommendations that address key reasons agile projects fail if the Department considers moving toward increased use of agile software development methodology. The 2011 State of Agile Survey reported that the leading causes of failure for agile projects were lack of experience in agile methodologies and failure to understand/address the broader organizational issues involved. These top two were followed closely by corporate culture issues and pressures for traditional waterfall methods.

Agile reflects a way of thinking about executing projects that cannot be learned in one or two classes. The Defense Acquisition University (DAU) is continuously improving the information technology curriculum. The challenge will be to continually raise the bar as agile approaches reach deeper and broader into the national defense system. DAU also offers coaching services but the number of agile certified coaches is currently limited. These are valuable resources.

However, software development organizations should consider establishing an internal Agile Coach position within the acquisition and/or program management competency to provide the ongoing mentoring and advice to individual programs considering adopting agile. Both of the previously referenced documents recommend training and the involvement of an Agile Coach to help projects and organizations align processes and organizational structures to support agile methods. The Agile Coach also should help the organization address the transition from traditional waterfall processes toward increased agility. In BBP 2.0, Mr. Kendall challenged every acquisition professional to do “more with less.” Agile methodologies may provide the means for us to meet that challenge.

To print a PDF copy of this article, click here.

Brown has more than 20 years of defense acquisition experience and brings both the contractor and government perspective to his current role. He holds both Program Management Professional (PMP) and Agile Certified Practitioner (ACP) certifications from the Program Management Institute.

The author can be contacted at



Leave a Reply

Your email address will not be published. Required fields are marked *