search menu icon-carat-right cmu-wordmark

Applying the 12 Agile Principles in the Department of Defense

Headshot of Suzanne Miller.
PUBLISHED IN
CITE

In 2010, the Office of Management and Budget (OMB) issued a 25-point plan to reform IT that called on federal agencies to employ "shorter delivery time frames, an approach consistent with Agile" when developing or acquiring IT. OMB data suggested Agile practices could help federal agencies and other organizations design and acquire software more effectively, but agencies needed to understand the risks involved in adopting these practices.

Two years later, OMB directed agencies to consider Agile development in its 2012 contracting guidance. As organizations work to become more agile, they can employ the 12 principles outlined in the Agile Manifesto to assess progress. I work with a team of researchers at the SEI who explore the barriers and enablers to applying Agile in government settings. We have found that each of these principles plays out differently in the federal landscape. While some principles are a natural fit, others are harder to implement. This blog post introduces a series of discussions recorded as podcasts about the application (and challenges) of the 12 Agile principles across the Department of Defense (DoD).

First Agile Principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Below is an excerpt from our podcast:

Mary Ann: The problem I see is for those in the field, if this is already a fielded system, or even if it's being developed, they can't deal with that frequent of a release. So, they lump releases together, and then they send them out every 8 months, 9 months, 18 months, whatever it is that works for them from a deployment viewpoint.
Suzanne: So, even though we're producing valuable software as a program, we may not actually get to deliver it, in the way that commercial settings might be able to deliver it.
Mary Ann: Correct.
Suzanne: I've seen what we call a "sandbox" as one of the ways that we deal with that. So, in a sandbox setting, I will put each iteration's software into what we call "a sandbox area." That area could allow user access, but it isn't a full deployment.

To listen to the complete podcast, please click here.

Second Agile Principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Below is an excerpt from our podcast:

Suzanne: One of the ways to get it out to the field faster is to not presuppose that all of the requirements that we think of at the beginning have to be designed and implemented. We need to prioritize them in a way that allows us to get something out there that the people can try, so the learning can occur.
Mary Ann: One of the key things, if you're going to use Agile methods, is have enough definition up front of what you want to do, but not so much detail that you can't learn, that it can't change, because your environment changed.

To listen to the complete podcast, please click here.

Third Agile Principle: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Below is an excerpt from our podcast:

Suzanne: What we see in a lot of acquisitions is we get lots of deliveries, but the early deliveries are more documentation, more review meetings, more review meeting slide decks. That's a really different focus for a lot of people in the contract settings where, you know, working software comes after all that stuff is delivered. So this is saying, Don't wait to actually deliver working software. So, you've got to really go from a document-centric lifecycle, and view of the world, to an implementation-centric focus.
Mary Ann: That's true.
Suzanne: And that's a culture change for the acquisition systems also, isn't it?

To listen to the complete podcast, please click here.

Fourth Agile Principle: Business people and developers must work together daily throughout the project.

Below is an excerpt from our podcast:

Suzanne: So, from their view point, business people are essentially the marketing people that understand what the market is, what market they are trying to penetrate. It's the end users who are actually going to use the product. So, they are looking at business people in a little different way than we do in the DoD. So, they don't necessarily have quite that same difference between he who pays for it or she who pays for it and the person that's using it.
Mary Ann: And, the thing is with the DoD environment, you obviously have to have the acquirers because those are the people that are trained to do the acquisition. And, they have the warrants, if you will: the permissions and the legal authorities to do it. However, they need to be working with the end users. And, typically, in a traditional environment, they do. They go out. They gather all the information from all the different end users, and they can be multiple groups.

To listen to the complete podcast, please click here.

Fifth Agile Principle: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Below is an excerpt from our podcast:

Mary Ann: ...Trust, but verify. That's very much the moniker of today. However, some organizations trust more than others. In many cases trust is just not there at all. In that environment it would be very difficult to do an agile-type of development without a lot of change in culture.
Suzanne: So, you and I have both seen some settings where a development organization, usually a contractor, is trying to use Agile principles. Yet, at the same time, they are being asked to do, at least the same if not more, documentation than they had in the past. They are asked for the detailed team metrics not just the typical management metrics. They are being asked for a lot of information that would make you think they are not very trusted. In those settings we've seen not very good success with Agile methods. I would assert that that's actually one of the reasons--that there isn't a feeling of trust.

To listen to the complete podcast, please click here.

Sixth Agile Principle: The most efficient and effective method of conveying information to and within a development teams is face-to-face conversation.

Below is an excerpt from our podcast:

Suzanne: If the primary means of communication is phone only--without some other screen sharing, without some other way of understanding what's going on or tons of email and not a lot of even voice communication--you really are reducing the bandwidth, and you are going to reduce the ability of the team to deal with problems and to deal with the issues that inevitably come up because that's when you need people to have your back.
This is a principle that in my mind--you can get support for it, I think, better than maybe some of the other principles--but you've got to ask for it. You've got to know that that's what you need to pay attention to, and you've got to pay attention to it.
Mary Ann: Well, and getting the support may require a little bit of investment in infrastructure because not everybody will have those tools available.

To listen to the complete podcast, please click here.

Seventh Agile Principle: Working software is the primary measure of progress.

Below is an excerpt from our podcast:

Suzanne: There is a huge amount of time where you are working on design documents, working on requirements refinement, working on interface descriptions, working on everything, working on essentially everything but the software itself. So, this mindset that working software essentially takes precedence over some of the other artifacts that we are accustomed to. This is a very big shift for our DoD audience.
Mary Ann: It is a big shift. The other thing that this makes me think of when you start talking about measuring, most of the very large systems by mandate are required to do earned value management. It is a fairly rigid system where everything's defined and you don't change things. But, if you're going to do it on working software...
Suzanne: ...and, if you're allowed to change requirements at the lower level.
Mary Ann: ...and, you're allowed to change things, then how does that go? That has all kinds of implications on how you do that.

To listen to the complete podcast, please click here.

Eighth Agile Principle: Agile processes promotes sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Below is an excerpt from our podcast:

Mary Ann: There is one program we are aware of--they are into mostly what we would probably consider more sustainment--the software is already out in the field, but they are enhancing it. They are updating it and fixing bugs and so forth. Every cycle they do, they do it by release. They have 1,200 (what they call) "program points," and their users know they have 1,200 points, and so they know how much each of their wish-list things are worth. There is a lot of horse trading going on behind the scenes, so they get their 1,200 points, but they get what they need. But, they know we only can get 1,200 points--no more, no less--and it is constant.
Suzanne: Part of this is setting up reasonable expectations with the end users and the customer community as well as the sponsor community. If there is a good understanding between the developers and the sponsors of the project as to what actually can be accomplished, then we have got a chance at sustainable development.

To listen to the complete podcast, please click here.

Ninth Agile Principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Below is an excerpt from our podcast:

Suzanne: We talk about Agile allowing good teams to really have superior performance. That is one of the basic aspects of Agile; there is an assumption that the people on the team are competent at what they do. So, you have got to have that competency for coding. You have got to have some competency for design, for detailed design. You have got to have some competency in unit testing. You have got to have some competency in integration. So, there are assumptions about what kinds of things your cross-functional team is capable of, and those are things that if you have them, it will enhance what you are able to do. If you don't have them, you are going to build technical debt. You are going to build in defects....
Mary Ann: It gets into the question that a lot of people say, Well, a good Agile team has to be very highly skilled. Bring your A game, if you will, your A players. An average kind of guy really won't play well in an Agile team. Well, that's not true. People will rise to what you expect them to do.

To listen to the complete podcast, please click here.

Tenth Agile Principle: Simplicity--the art of maximizing the amount of work not done--is essential.

Below is an excerpt from our podcast:

Mary Ann: It means maximizing on your return on investment, and getting the value you need, and then determining if some of the bells and whistles aren't needed.
Suzanne: We are also talking about the difference between creating complex architectures and complex ways of solving a problem and looking at, What is the simplest way?
Often, when we say, What is the simplest way to do something? we actually stop having to do a lot of the work that goes along with implementing the complex way. So, the simplicity is not just about looking at getting value, it is also about reducing complexity. We are very good as engineers in figuring out lots of convoluted ways to make things work. So, this is really saying, Don't go there if you don't need to. I go back to the old Einstein quote, Make everything as simple as possible; but no simpler.

To listen to the complete podcast, please click here.

Eleventh Agile Principle: The best architectures, requirements, and designs emerge from self-organizing teams.

Below is an excerpt from our podcast:

Mary Ann: When you hear the principle best architectures, requirements and designs emerge from self-organizing teams, any self-respecting DoD manager would run screaming from the room. What do you mean emerge from a self-organizing team? Oh my gosh! You have to understand what those terms mean. That is the key to understanding what this means. It doesn't mean chaos and people are just saying, Go do something. Heavens no. Self-organizing means you give the team boundaries.
And, say, OK. Here is the problem. You give them an initial skeleton, if you will, of an architecture. You don't just say, Go make one up. It is stuff that people would call maybe sprint zero, depending on who you talk to. Then, you let them go solve the problem.
Suzanne: Let's talk a little bit about the architecture thing because that, in the larger Agile community, has been a topic of debate for some years. Although I think we are seeing some resolution of that where most Agile teams in commercial settings are starting to acknowledge the role of architecture, not just emergent architecture but actually some design up front. They call it just enough design up front as opposed to big design up front.

To listen to the complete podcast, please click here.

Twelfth Agile Principle: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Below is an excerpt from our podcast:

Suzanne: One of the things you often have when you get into DoD settings is to have multiple teams running. So, one of the things that teams in DoD settings have to be aware of is improvements locally to their own work may affect others. Usually at release time is when you will do larger retrospectives where you look across the teams that are working on a release and get everybody together and say, What do we need to change as a whole group, not just as an individual team?
Mary Ann: That is true. Release time is when they usually do that, but you might want to consider doing it at the end of iterations or sprints. Because, for instance, say you have three or four different teams. And, team A and team B worked really well together, and they had some kind of cool technology they were using. But, team A and C didn't have that, but they were doing similar kinds of interfaces. They might want to identify that and say, Why don't we use this for our interface too or our tool?
That way you are not waiting until the very end of the release to upgrade the whole group as opposed to just your team. It gets a little more complicated but it's like Scrum of Scrums.
Suzanne: This is one of the roles of a Scrum Master, to help identify these places where as the different Scrum Teams come up with things, the Scrum Masters get together and help identify where these opportunities are. That is one of the important things about this: tuning, this idea of tuning our work, is about taking advantage of the learning in the moment. It is really about that plan-do-act-check cycle over and over and over again and getting people accustomed to looking at their work from that viewpoint.

To listen to the complete podcast, please click here.

We welcome your feedback on this series as well as ideas for future topics.

Get updates on our latest work.

Each week, our researchers write about the latest in software engineering, cybersecurity and artificial intelligence. Sign up to get the latest post sent to your inbox the day it's published.

Subscribe Get our RSS feed