Agile Methods: Tools, Techniques, and Practices for the DoD Community

Agile Add comments

By Douglas C. Schmidt,
Principal Researcher

Douglas C. SchmidtWhile agile methods have become popular in commercial software development organizations, the engineering disciplines needed to apply agility to mission-critical, software-reliant systems are not as well defined or practiced. To help bridge this gap, the SEI recently hosted the Agile Research Forum, which brought together researchers and practitioners from around the world to discuss when and how to best apply agile methods in mission-critical environments found in government and many industries. This blog posting, the second installment in a multi-part series, summarizes a presentation made during the forum by Mary Ann Lapham, a senior researcher in the SEI’s Acquisition Support Program, who highlighted the importance of collaboration with end users, as well as among cross-functional teams, to facilitate the adoption of agile approaches into DoD acquisition programs.

Lapham’s Talk on Agile Methods: Tools, Techniques, and Practices for the DoD Community

The broad—and rapidly expanding—threats the DoD must address necessitates an ability to develop software faster, Lapham told the audience. “In today’s environment people want results faster. They want to use information technology (IT) applications and infrastructure sooner; there is a real need,” Lapham said. In the commercial and DoD domains, the prevailing question is, “How can IT be delivered faster?” The answer, Lapham told the audience, is an iterative approach that lends itself to agile methods.

Lapham noted that the SEI is focused on reducing the DoD information technology development cycle—which can currently take as long as 81 months—to short, increemental approaches that yield results more quickly. One complicating factor is that DoD acquisition programs (like other highly-regulated commercial environments) have a prescribed vision of how IT systems are developed, Lapham explained. She referenced the DoD 5000 Series Acquisition Lifecycle, which has traditionally employed a waterfall approach that focuses largely a sequential process of requirement analysis followed by design, implementation, and testing.

Lapham said that she and other SEI researchers are working on developing an approach that will allow the DoD to develop applications in a shorter period, ideally 18 to 24 months. One aspect of Lapham’s research focuses on helping the DoD transition from a traditional method to more iterative and incremental development methods, while still operating within the regulatory boundaries of the overarching DoD 5000 Series Acquisition Lifecycle model.

Implementing Agile Effectively for in DoD Environments

Lapham said the SEI’s research in this field began in 2009 when a DoD client asked about using agile methods.  “We reviewed the 5000 series to see if something in it would preclude us from using agile, and there wasn’t. From there, we’ve gone on to investigate different parts of the acquisition process so we can help program offices and contractors understand how to implement agile effectively in DoD environments.”

Lapham said her team applied agile methods to study agile methods. Researchers started by interviewing practitioners who were experts with traditional waterfall methods about how those methods fit into the DoD acquisition lifecycle. Next, Lapham and her team identified the gaps that would occur if agile principles were applied by the DoD in the traditional acquisition lifecycle. After identifying the gaps, Lapham’s team consulted with DoD stakeholders to ensure they had identified the appropriate gaps. The researchers then characterized those gaps and built a model to form a complete overview of the lifecycle with agile principles.

The research conducted by Lapham’s team yielded a compendium of topics that addressed the barriers of adopting agile methods in the DoD. “We have a list of 30 topics, including such questions as: How do I do agile contracting? How do I do agile requirements management? How do I do agile cost estimation, testing, and system engineering?” Lapham explained. Next, the researchers consulted with DoD acquisition stakeholders to ensure that the topics they are addressing are relevant. The team is in the midst of piloting their agile approach with practitioners. “We’re applying a lot of the agile methods that have been used successfully in the commercial arena,” Lapham said, adding that their research accounted for the fact that certain agile terms in the commercial world differ from those in a DoD environment. The published results—which will be released starting later this year—will be a set of validated tools, techniques, and practices.

Comparing and contrasting traditional and agile approaches to software development

Lapham noted the research results thus far have yielded the following findings about traditional versus agile development:    

Characteristics of traditional approaches

  • an arms-length relationship between developers and acquirers
  • hierarchical, command-and-control-based teams
  • leader as keeper of the vision and primary source of authority to act
  • conventional, representational documents used by the program management office to oversee the progress of developers in a software development lifecycle model with separate teams, particularly for development and  testing; some independent program teams involve multiple functions

Characteristics of agile approaches

  • collaborative relationships between developers, acquirers, and end users
  • strong team relationships, with collocated teams, or effective communication mechanisms with distributed teams
  • facilitated leadership, with the leader as champion and team advocate
  • “just enough” documentation to maintain a product and continue to use it and evolve it (documentation is highly dependent on product context)
  • cross-functional team relationships that includes all roles throughout the lifecycle where every member of the team performs their function, but they perform it together and reinforce it

Lapham also described how SEI researchers are compiling a compendium of cultural issues that organizations need to consider when implementing agile, as described below

Organizational Structure. Many DoD practitioners are content with traditional hierarchical structures where one person is in charge. Traditional DoD organizational structures are hard to change due to their command-and-control-based integrated-product teams that have formal responsibilities and roles.  They meet on a prescribed schedule, usually once a month. Often, those teams work through certain issues as part of their charter.

Agile organizations, in contrast, are characterized by flexible and adaptive structures. Teams are cross-functional and small. An agile organization might have multiple teams working together in different locations, but still maintain constant communication. Teams will be self-organized, but that doesn’t mean they lack discipline, Lapham said. Instead, agile projects require developers with rigor across a core set of processes.

Leadership. In traditional DoD software development approaches, the leader is the keeper of the vision and the primary source of authority to act. In an agile DoD organization, in contrast, the goal is facilitative leadership, the leader is an advocate and champion for the team. This approach is a different style of leadership that requires a paradigm shift in management styles in DoD organizations.

Reward systems. A traditional DoD organization focuses on the individual and rewarding individuals for high performance. In an agile DoD environment, the team is the focus of the rewards system. Lapham commented that team members typically behave based on the activities for which they are incentivized. If developers are rewarded for being the hero, therefore, that may not create an environment conducive to team building.

Staffing model. A traditional DoD organization uses a lifecycle model with separate teams, particularly for development and testing. Different roles are active at defined points in the lifecycle and are not substantively involved, except at those defined times. An agile DoD environment, in contrast, employs cross-functional teams, including all roles across the lifecycle of the project. The teams contain an agile mentor or coach who explicitly attends to the team’s process and ensures that they work together cooperatively.

Communication and decision making. In organizations that employ a traditional approach to software development, top-down communication structures dominate. Likewise, external regulations drive the focus of the work while indirect communications, such as documented activities and processes, dominate over face-to-face dialogue. Program management office oversight tools focus on demonstrating compliance.  In an Agile DoD environment, in contrast, teams usually hold 15-minute daily standup meetings in which three main topics are discussed:

  1. What am I going to do today?
  2. What did I do yesterday?
  3. What problems did I have? (the goal is not to solve problems in this short meeting, but the agile coach determines whose responsibility it is to solve those problems at the end of the meeting)

In an agile environment, teams hold frequent retrospectives to improve practices while information radiators are used to communicate critical project information to avoid surprises. Information radiators are entities (sometimes automated tools, sometimes just stickies on a board) that provide status and ensrue an open and transparent flow of information.  Documents serve to feed conversation among team members. Agile organizations produce enough documentation required to meet DoD acquisition regulations, which is highly dependent on product context.

What's Ahead

The first posting in this series summarized discussions by Anita Carleton, director of the SEI’s Software Engineering Process Management program, and Teri Takai, chief information officer for the DoD. Carleton provided an overview of the forum and discussed areas where SEI work is focused on applying agile methods at-scale. Takai then discussed how agile methods have been introduced into the DoD software acquisition and development environment.

Our next posts in this series will summarize discussions of three SEI researchers, including myself, at the Agile Research Forum who examined aspects of applying agile methods at-scale in mission-critical development environments:

  • Ipek Ozkaya discussed the use of strategic, intentional decisions to incur architectural technical debt. The technical debt metaphor describes the tradeoff between taking shortcuts in software development to speed up product delivery and slower—but less risky—software development.
  • James Over noted that lack of teamwork can critically impede agility. He advocated, among other principles, the building of self-managed teams, planning and measuring project process, designing before building, and making quality the top priority for achieving agility at-scale.
  • Finally, I wrapped up the forum with a discussion on the importance of applying agile methods to crucial common operating platform environments (COPEs) at the DoD. I explained how agile methods can encourage more effective collaboration between users, developers, testers, and certifiers to help the DoD successfully build integrated, interoperable software systems.

We look forward to hearing your thoughts on applying agile at-scale in the comments section below.

Additional Resources

The slides and recordings from the SEI Agile Research Forum can be accessed at

To read Lapham’s SEI blog posting on Using Agile Effectively in DoD Environments, please visit

To read the SEI technical note, Considerations for Using Agile in DoD Acquisition, please visit

To read the SEI technical report, Agile Methods: Selected DoD Management and Acquisition Concerns, please visit

To read the SEI technical report, A Closer Look at 804: A Summary of Considerations for DoD Program Managers, please visit

To read an article in Crosstalk by Lapham, DoD Agile Adoption: Necessary Considerations, Concerns, and Changes, please visit

Share this

Share on Facebook Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Save this page on your Google Home Page 

8 responses to “Agile Methods: Tools, Techniques, and Practices for the DoD Community”

  1. Akhila E K Says:
    Informative article!!
    In between, I have a query.
    The article talks about "Just enough" documentation. Also many a time I have heard similar thing in agile. What does it actually imply..? Whether the other ISO quality standards or CMMI like models requires additional documentation.. I believe, it won’t be intended. Then what is actually said " as just enough documentation " in agile.. compared to CMMI like models?

  2. Mary Ann Lapham Says:

    Just enough documention is related to the environment in which you are developing the software. It's context dependent or another way to think of it is what is my domain. For instance, enough documentation in a safety critical domain (such as medical devices) is totally different than one for a less life critical application (such as an automated teller machine). Most standards allow you to tailor the documentation to your environment. To get just enough documentation, you need to tailor the required documenation (which will most likely require reviews and approvals).

    Good question.


    Mary Ann
  3. Akhila E K Says:
    Thanks Ms Lapham for your genuine reply.
  4. Akhila E K Says:

    Somewhere I have read some relations between Agile methods and TSP frameworks.
    Can you please provide me some insights in those lines…
    I have read some articles on TSP where in which it says that TSP and CMMI are complementary and both of them together can bring in high performance., but still not able to understand the real essence of TSP above to CMMI.. Could you please guide me further reading and understanding.

  5. Douglas C. Schmidt Says:
    Hi Akhila, Please check out for a presentation about the relationship between agile methods and TSP. Thanks, Doug
  6. Timothy A. Chick Says:
    In Capers Jones latest book “Software Engineering Best Practices," he conducts an independent comparison of several methods such as Agile and the Rational Unified Process (RUP) and states that for “large [and medium] applications, the Team Software Process (TSP) and Personal Software Process (PSP) have the greatest success”. He goes on to state that his conclusions are based “on quantitative data rather than on subjective opinions.” His book also summarizes the features TSP and Agile development methodologies support, based on his research. As shown below, TSP addresses all 8 of Agile’s features, plus much more:
    1.   Team organization
    2.   Project management – planning and estimating
    3.   Change control
    4.   Requirements
    5.   Design
    6.   Code development
    7.   Configuration control
    8.   Testing

    1.   Team organization
    2.   Specialization of team members
    3.   Project management – planning and estimating
    4.   Project management – tracking and control
    5.   Change control
    6.   Requirements
    7.   Design
    8.   Reusability
    9.   Code development
    10.   Configuration control
    11.   Quality assurance
    12.   Inspections
    13.   Static analysis
    14.   Testing
    15.   Security
    16.   Documentation and training

    For an explanation of how TSP and CMMI work together I would recommend the following reports:
    1. Guide for SCAMPI Appraisals: Accelerated Improvement Method, SEI-2010-SR-021 (

    2. Implementation Guidance for the Accelerated Improvement Method (AIM), SEI-2010-SR-032 (
  7. George Hare Says:
    You have made some good points, but maintaining cross functional teams has been a big problem for us. We have tried TFS, JIRA, SmartBear and are currently running Countersoft Gemini. It really is tough improving cross team functionality.
  8. Mary Ann Lapham Says:
    You only mention the tools that you have tried to use to improve cross team functionality. There's more to creating an Agile cross functional team than the tools. Agile is a philosophy which is quite different from the traditional mindset that many software personnel learned or have employed. Without knowing what kinds of organizational changes you have employed it is hard to tell what still needs to be done. You many want to look at our second paper that talks about being agile versus doing agile. See Section 6 of Agile Methods: Selected DoD Management and Acquisition Concerns
    Hopefully this will give you some ideas on how to proceed.

Add Comment

Leave this field empty: