Rapid Lifecycle Development in an Agile Context

Acquisition , Agile Add comments

By Robert Nord,
Senior Member of the Technical Staff
Research, Technology, & System Solutions

Robert NordNew acquisition guidelines from the Department of Defense (DoD) aimed at reducing system lifecycle time and effort are encouraging the adoption of Agile methods. There is a general lack, however, of practical guidance on how to employ Agile methods effectively for DoD acquisition programs. This blog posting describes our research on providing software and systems architects with a decision making framework for reducing integration risk with Agile methods, thereby reducing the time and resources needed for related work.

The DoD chief information officer (CIO)’s office has recently released a 10 Point Plan to reform DoD information technology (IT).  Point number 4 is “Enable Agile IT.” The key tenets of Agile IT include

  • Emphasize incremental introduction of mature technology by delivering useful capability every 6 to 12 months to reduce risk through early validation to users.
  • Require tight integration of users, developers, testers, and certifiers throughout the project life cycle to meet Agile IT’s promise of rapid delivery in lieu of extensive up front planning.
  • Leverage common development, test and production platforms and enterprise products to deliver IT capabilities faster, cheaper, and more interoperable, without redundant infrastructure and documentation. 
  • Establish a change-tolerant design environment enabled by discovery learning that promotes decisions based on facts rather than forecasts.

Program managers and acquisition executives are responding to this plan by applying industry practices, such as Agile methods. At the same time, related DoD guidelines encourage system development via a more open, modular software architectural style, such as loosely-coupled service-oriented architectures. The impact of these architectural decisions becomes more critical in an agile context because they promote or inhibit the ability to achieve agile goals, such as rapid feedback, responding to change, and team communication. Architectural decisions influence agile development properties, such as the length of an iteration, the allocation of stories to iterations, and the structure of the teams and their work assignments with respect to the architecture. What is needed, therefore, is research on eliciting and employing these properties and determining their relative importance in promoting rapid lifecycle development.

To address this need, I and other SEI technologists, Ipek Ozkaya, Stephany Bellomo, and Mary Ann Lapham, are conducting research that focuses on the implications of decisions made over the course of the software and systems lifecycle. We are examining when these decisions are made and the time when the implications surface to validate the following hypotheses:

  1. The fundamental early decisions made during the pre-engineering and manufacturing development (pre-EMD) phase have an impact throughout the lifecycle. Acquisition programs lack the techniques needed to elicit and preanalyze the implications of which fundamental architectural decisions will enable or inhibit their ability to adopt an agile lifecycle. For example, architectural decisions that relate to decomposition and dependencies influence teaming structure, the capability to rapidly and confidently deliver features, and the ability to rapidly integrate new components among other factors.
  2. The implications of the early decisions often surface in the final stages of the lifecycle, downstream from development.  For example, unexpected rework related to correcting integration defects. When these problems are discovered further downstream from where they were injected in the lifecycle, they are more expensive to correct and this often causes cost overruns and delays project completion.

  Identifying Critical Properties

A primary objective of our research is identifying critical properties of Agile software development influenced by architectural decisions that reduce lifecycle time.  Identifying these properties is an important first step to give stakeholders the tools they need to make informed decisions that manipulate the settings of the properties to control for better outcomes.

Our approach involves examining the implications of possible change scenarios. One such scenario examines the impact of introducing an emerging multi-core technology to the mission processor software of the Apache helicopter, which is a US Army/Boeing program. Applications are increasingly favoring multi-core processors, a single integrated computing element with two or more independent processors, called “cores,” allowing for greater processing capacity. The scenario explores questions that include

  • Will the multi-core technology change the architectural design (e.g., patterns, tactics, and architectural approaches)?
  • If so, which architectural decisions will change?
  • Are there engineering practices (such as Agile) that must be customized as a result of architectural decisions in support of a rapid lifecycle?
  • How will continuous integration be ensured?
  • How will team communication be impacted?

A key component of our work involves determining the critical decisions that will influence Agile practices. These decisions provide the rationale for how software and system architects design an architecture. 

To expand our view, we will again collaborate with Philippe Kruchten, a professor of software engineering in the Department of Electrical and Computer Engineering of the University of British Columbia, who is active within Agile development and architecture decision making research communities. Another facet of our approach involves interviewing DoD programs and gathering data from members of the SEI Agile Collaboration Group

Creating a Model

Rework must be considered early when reasoning about how to enable rapid lifecycle development. After we review the findings identified in the first phase of our work with collaborators, we will create an architectural decision model that allows software or systems architects to analyze the ramifications of their decisions. Based on our prior work, we anticipate that highly impactful architectural decisions will include

We plan to use the Multiple Domain Matrix (MDM) to represent the decision model and to analyze the impact of architectural decisions on rapid lifecycle development. The MDM approach considers decision dependencies that provide visibility into how the ordering of decisions influences when development can be started and how changes propagate and may require rework of software elements. This approach will allow us to test our hypothesis that modeling architectural decisions during early stages of development (similar to pre-EMD) will reduce cycle time.  Cycle time could be reduced upstream by enabling an earlier start of development, thus minimizing the time spent at the pre-EMD phase or reduced downstream by decreasing rework costs attributed to architectural decisions that affect integration.

Another component of our research will explore strategies for improving the relationship between architecture decision making and complex collaborative team interaction. A barrier that often arises is that decisions made by architects about partitioning the architecture are not aligned with the networks of agile teams at scale and for the kinds of systems relevant to the DoD. Another barrier is alignment with the teams that span the lifecycle beyond the development teams traditionally associated with agile and include system engineering, testing, validation and verification, certification and accreditation. We have observed the ramifications of this misalignment during the integration of components built by different teams, where incompatibilities lead to significant rework.

To map, analyze, and support the architectural decisions of industry collaborators, we plan to map our MDM approach into a conceptual model developed by Kevin Sullivan of the University of Virginia, who is working on creating a cyber-social conceptual model. Sullivan’s work focuses on the social networks and the value of relationships between decision makers in a system.


A primary technical challenge that we face in this approach involves scaling. As a practice, Agile has been successful in helping to solidify the efficiency of development teams when projects involve small teams. Applying these same concepts to large-scale distributed systems— including the rest of the organization that has priorities larger than the development team—will be critical for success, but it will also present some of the greatest challenges. To address the challenge of scaling, we are looking at the influence architecture exerts on managing teams and how to provide practical guidance on what amount of architecture is needed and when. On the one hand, early or overproduction of architecture can create delay. On the other hand, not enough production of architecture can result in integration defects leading to rework. The focus of lean thinking on improving cycle time by eliminating waste, in the form of delay or unnecessary rework, in conjunction with architecture, has shown great potential for improving management of software development projects and increasing flow of value delivered to the customer.

Next Steps

We are in the process of conducting a survey of critical agile development properties and will write about the results in a future blog posting.

Additional Resources:   

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


Share this

Share on Facebook Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

13 responses to “Rapid Lifecycle Development in an Agile Context ”

  1. Larry Babb Says:
    Having been on software development efforts in the context of a large hardware (e.g., aircraft, satellite) effort, I often found that the hardware waterfall model drove the software approach.

    There was no mention of decoupling in the blog post.
  2. David Vidal Says:
    In my opinion, one key aspect is the communication of the teams with the architect. I think that the number of concurrent projects in a middle or big size company makes unfeasible that an expert or architect takes an active participation in many of them. Also, to write some guidelines about architecture is something difficult to follow or monitor across the projects. Even if I haven't implement this idea, I think that a possible approach to address this issue is to let software engineers to express architecture requirements by themselves in a simple notation(for example a table) and to validate or analyze them as automatic as possible.

    In other words, I think that a challenge is how to make that an architect analyze technical designs or requirements with little intervention or with little demand for his attendance in all meetings.
  3. Trevor Harrison Says:
    My PhD research topic is on the very broad topic of software system architecture decisions in large Australian defense projects, so I always have many literature references at hand!

    I came across something very similar to the use of “change scenarios” to explore questions in the Perspective Based Architecture method (PBA Method) developed by Lewis Curtis and George Cerbone. The claimed benefits from using the PBA Method seem similar to your desired research outcomes i.e. a quality architecture in terms of less re-work, and later on, adaptability of the architectural design. Listening to a podcast of Curtis & Cerbone, they claimed that quality system architectures came about from those architects who said to themselves “before finalizing this particular decision, I wonder what other questions I should be asking?”. The greater the range of related questions, the more the ‘perspective’ the architect had / has.

    (Appropriate application & usage of decision analysis techniques can be seen in Preston Smith’s “Flexible Product Development : Building Agility for Changing Markets”. A good example is the use of decision trees; it follows that a decision tree is more useful for the insight it provides and the questions it raises than it is for actually helping you to make a decision. Consequently, actually creating a decision tree or analyzing it is more instructive than looking at one created by someone else [p.163].)

    The center piece of my thesis-in-draft is a model similar to Kevin Sullivan’s focus on social networks. I encountered much literature to say that architecture is a dynamic web of decisions. Whereas Sullivan is exploring the relationships between decision makers, I am exploring the relationships between decisions. Sullivan has a network of decision makers. I have a network of a few decision makers and many thousands of decisions.

    I would be happy to collaborate on this research. Some may find my work the anti-thesis on architecture decisions though. My adopted definition of a “good decision” in large Government projects is one that commands support, and may have little to do with the technical merit of the solution. I also uncover much literature, from social science to philosophy to operating system design, that says rational decision-making and associated capturing of rationale is inappropriate (for a variety of reasons) in the earliest stages of architectural design. For those readers utterly perplexed by the last two sentences, here is the link to a thesis chapter on research design:
  4. Robert Nord Says:
    Larry, we have observed similar phenomenon with respect to system-level decisions influencing the software architecture. These decisions often have to do with coupling/decoupling or partitioning that can hinder or support feature delivery, technology upgrades, contracting options, effective teaming, and so on. To help us make better decisions we first want to understand how we can better identify those highly impactful decisions as they are being made so that they can be the focus of further analysis. We would be interested in hearing about such early decisions you have made and might have reconsidered if you knew at the time the impact they would later have. Other readers are invited to do the same.
  5. Robert Nord Says:
    David, you raise an important issue about the architect in the teaming structure. As projects scale, more demands are placed on the architect. We have observed similar challenges for the product owner as well. The problem can be tackled from a number of perspectives including decoupling the role from the person to get more people involved and using automation as you suggest. We have some experience with combining automated analysis techniques such as model-based technical risk assessment with evaluation techniques such at the Architecture Tradeoff Analysis Method(R) (ATAM(R)) that rely on the expertise of the architect. Another approach is to take a lesson from lean software development and seek to eliminate wasteful activities that do not add value as it pertains to the architecture. This will provide more opportunity for the architect to interact and communicate with the teams at times that do add value.
  6. Robert Nord Says:
    Trevor, this research is a joint project between the Research, Technology, and System Solutions (RTSS) program and the Acquisition Support Program (ASP). Our combined interests are to address the topic from an acquisition and technical perspective so your work and definition of a “good decision” is of interest. It is true that the technical merit of the solution isn’t always sufficient in solving a problem, it occurs in a context that need to be considered. The feedback we get from the government programs we work with is that social aspects, such as fostering collaboration and communication, of the techniques we employ are as important as the technical results. Our partners in ASP have written about the challenges and opportunities of using new technologies in the DoD acquisition life cycle. Granted there are many decisions made that may have little to do with the technical merit of the solution. Architects have brought us examples of technology decisions made during the pre-EMD phase and challenged us to consider the question how these decisions might be improved. We are focusing on bringing visibility to the implications on the architecture and their impact on software development.
  7. Michael Keeling Says:
    "A barrier that often arises is that decisions made by architects about partitioning the architecture are not aligned with the networks of agile teams at scale and for the kinds of systems relevant to the DoD."

    It sounds like you are suggesting that architecture inhibits teams from self-organization. The common thinking is that self-organization is critical to the success of Agile teams. Is this really supported by your research? What is your opinion/findings on self-organization as it relates to architecture? Allowing for self organization "at scale" or within the DoD is another issue and one that likely needs to be understood before "true" agile adoption can happen, I'd think.

    Interestingly, Philippe Kruchten claims there is no connection... "Self-organizing teams have very little to do with the architecture of your system." - slightly out of context quote from http://philippe.kruchten.com/2011/11/01/agility-and-architecture-koan/. I don't completely agree with him on this.
  8. Philippe Kruchten Says:
    Michael Keeling really quotes me out of context, here. :-)
    I was reacting to this:
    “Self-organizing teams can decide everything by themselves. So they don’t need an architect.” writes Samudra Kanankearachchi
    Yes, you do organize based on an architecture. Yes, some congruence between the people structure and the system structure is useful. But claiming that because you are "self-organizing" you do not need an architect was pushing it a bit far for me...
  9. Robert Nord Says:
    Michael, we have been looking at the impact that architecture has on enabling or inhibiting team structures. Ipek Ozkaya reported on preliminary findings in her presentation on “Agile Development and Architecture: Understanding Scale and Risk” at the SEI Technologies Forum (http://www.sei.cmu.edu/go/technologies-forum/). Additional information will appear in an article on “Architectural Tactics to Support Rapid and Agile Stability” in the May/June 2012 issue of CrossTalk. So far we have observed properties such as the size, composition, and structure of the teams, how they are aligned with the architecture, and how these structures may change over time. How the teams are organized, as self-organizing or not, as you suggest is another interesting property to investigate. We would frame the question a little differently in terms of how do these properties affect the alignment of architecture and team structures in support of the overall goal of rapid lifecycle development. We view agile as a possible means to this goal and not the end goal itself.
  10. Kevin Sullivan Says:
    Trevor Harrison says: "I encountered much literature to say that architecture is a dynamic web of decisions. Whereas Sullivan is exploring the relationships between decision makers, I am exploring the relationships between decisions. Sullivan has a network of decision makers. I have a network of a few decision makers and many thousands of decisions."

    Trevor, Thanks very much for your comments. Historically our work has focused on formalization and formal analysis of networks of decisions. Search for papers I've written with Yuanfang Cai. Our current work seeks to connect such decision networks to social networks, following lines of thought by the likes of James Herbsleb, Carliss Baldwin, Sosa, etc. I'd be happy to discuss all of this with you!
  11. Ipek Ozkaya Says:
    Trevor, it is good to hear that the focus on managing design uncertainty through decision relationships is still continuing. Through our early work we observed that understanding the functions the decision makers represent are as critical as the network of decision makers since those functional relationships provide key insights into how the rapid lifecycle development is inhibited or enabled. For example, the boundaries between system engineering and software engineering functions have many critical decisions during the early phases of a project for our government stakeholders for the pre-EMD phase. The decisions made around such boundaries have enduring impact on the overall system lifecycle. Another challenging boundary that our early work revealed is between external assurance, verification and validation entities and the software development teams. As Rod Nord mentioned, we are focusing on bringing visibility to the implications on the architecture and their impact on software development. Our work aims to reveal through architecture decision modeling areas with risky decisions in order to allow development teams to work on removing inhibitors to rapid development.
  12. David Sharp Says:
    The stated hypotheses seem true, but describe the same problem that drove "risk-based development planning" approaches of the past. They seem tangential to the targeted problem, or at least seem to miss what is new about it.

    It seems like the core problem is "how to do architecture decision planning for large-scale agile projects". Or maybe it's "how to do architecture in general for large-scale agile projects".

    What would you say is the summary problem statement?
  13. Robert Nord Says:
    David Sharp says: It seems like the core problem is "how to do architecture decision planning for large-scale agile projects".

    David, this is the context. Looking at architecture as a collection of decisions is a new focus and Ipek Ozkaya has commented above on some of the challenges as we move across the boundaries of software development to the rest of the organization. Looking at scale from a decision perspective across the dimensions of scope, time, and team allows us to see how decisions align. A recurring issue we see is how decisions about architecture partitioning (related to scope), architecture increments (over time), and team structures influence each other for good or for bad. If part of the problem is due to a mismatch, in which architectural decisions fail to support business goals including agility, then part of the solution is to introduce architecture in a coherent way. This core problem is described in more detail an article on “Architectural Tactics to Support Rapid and Agile Stability” that will appear in the May/June 2012 issue of CrossTalk.

Add Comment

Leave this field empty: