While 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
www.sei.cmu.edu/go/agile-research-forum/.

To read Lapham's SEI blog posting on Using Agile Effectively in DoD Environments, please visit
/blog/using-agile-effectively-in-dod-environments/.

To read the SEI technical note, Considerations for Using Agile in DoD Acquisition, please visit
www.sei.cmu.edu/library/abstracts/reports/10tn002.cfm.

To read the SEI technical report, Agile Methods: Selected DoD Management and Acquisition Concerns, please visit www.sei.cmu.edu/library/abstracts/reports/11tn002.cfm.

To read the SEI technical report, A Closer Look at 804: A Summary of Considerations for DoD Program Managers, please visit www.sei.cmu.edu/library/abstracts/reports/11sr015.cfm.

To read an article in Crosstalk by Lapham, DoD Agile Adoption: Necessary Considerations, Concerns, and Changes, please visit www.crosstalkonline.org/storage/issue-archives/2012/201201/201201-Lapham.pdf.