Building a Foundation for Agile (To Enable Rapid Change)

Acquisition , Agile , Architecture Add comments

by Stephany Bellomo
Chief Engineer for Civil & Defense Agencies, Acquisition Support Program

Stephany BellomoThis is a second in a series of posts focusing on Agile software development. In the first post, “What is Agile?” we provided a short overview of the key elements of the Agile approach, and we introduced the Agile Manifesto. One of the guiding principles from the manifesto emphasizes valuing people over developing processes. While the manifesto clearly alludes to the fact that too much focus on process (and not results) can be a bad thing, we introduce the notion here that the other end of the spectrum can also be bad. This blog explores the level of skill that is needed to develop software using Agile (do you need less skill or more?), as well as the importance of maintaining strong competency in a core set of software engineering processes.

When applied properly in the right context, Agile can accelerate the delivery of high value software capability. The challenge is that Agile is also seen by some as an opportunity to stop doing things they don’t want to do.  For example, we interviewed a multi-billion dollar Internet company who areusing Agile.  Representatives of the organization we interviewed said they ran into several cases where programmers used Agile as an excuse to avoid following steps in the software development process they didn’t like or don’t have strong enough skill sets to do well.  Not only do these shortcuts make Agile look bad as a development approach, but when the half-hearted application of Agile methods yields poor quality software it hurts other projects that want to follow Agile methods more faithfully.

Successful Agile projects require programmers with both BETTER-than-average software engineering skills and process rigor across a core set of processes. The reason for the need for stronger skillset (not in all processes, just a core set) is that when you are under stress–in a fast-paced environment with lots of change–it is critical to have solid ingrained, habitual engineering practices. Otherwise, when the pace picks up things tend to drift from slightly out-of-control into total chaos.

Here is a quick analogy. I decided to learn to become a good swimmer late in life (in my 40s). I quickly learned that swimming is all about technique. Initially, I tried to swim fast without bad technique and ended up falling apart, flailing about, and going nowhere fast. The same is true with Agile. When key engineering processes aren’t habitual and you enter into stressful situations—such rapidly changing requirements—things can fall apart pretty quickly and you’ll end up with very bad software very quickly.

So, how can you successfully apply the right level of process discipline? The trick is to identify and focus on a subset of key processes that are critical for enabling change, rather than treating all software processes equally. Based on the Agile projects we’ve been involved with at the SEI, some key processes that I’ve found essential to incremental-development approaches like Agile include configuration management, capability planning, requirements management, testing, and architectural analysis. While you don’t have to be an expert at every software engineering process, Agile does require more discipline in a core set of areas. If you don’t see discipline these areas, therefore, it might be time revisit your core processes and make sure you are ready to swim in the big and unpredictable waves of change without falling apart.

The SEI has recently began a new Agile-focused research initiative focused on providing guidance for DoD programs. This research will use findings from DoD programs that use Agile methods to develop a model—we refer to it as an Agile Contingency Model—for determining when Agile might be a good fit for a DoD software development project. In addition, the research team will develop guidance on applying agile methods to software development projects in the DoD context. The Agile Contingency Model, coupled with the Agile DoD Guidance, will give government program managers a set of guideposts to use when considering Agile for their project and, if they choose to use Agile, for applying Agile methods in the DoD.

For more information:
If you are interested in reading more about Agile, we encourage you to check the SEI SATURN blog discussion on architecture and agile at

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 

4 responses to “Building a Foundation for Agile (To Enable Rapid Change) ”

  1. MIchael Pochan Says:
    I believe this is an incredibly important blog because of what you said; there are few standards for what "Agile" is. Just like SEI defined CMM, Agile could use some lasting constructs, industry-accepted definitions and rules to follow.

    My background and thus viewpoint is a Carnegie Mellon ChE with Tepper MBA who architected, designed, coded, tested and implemented business application software for companies like Ford Credit and Toyota Motor Finance. The software was mission-critical to their day-to-day business operations. The big projects were in $millions. At stake per quality were $ hundreds of thousands and customer satisfaction. We were a for-profit entrepreneurial company.

    We grew up at CMU with the "waterfall" process. It was too slow so we embraced RAD - Rapid Application Development - which was iterative and constantly showing the Customer intermediate builds for feedback. RAD didn't have a lot of specified rules; it was more an "art" than a "science" ( software engineering was still 5 years off in future ).

    The "artists" got out of hand over time, so we evolved into what now looks like our own variation of 'agile scrum', and we called it PADDT - Parallel Analysis Design Development & Testing.

    Three things I did not see mentioned so far that made a difference for our success:

    (1) the team needs a strong leader that can pull together all the members and their expertise
    (2) deep domain knowledge of the Customer's business and use of the software
    (3) requirements analysis managed by the entire team that identifies all the stakeholders.

    Anyway, keep up the good work.
  2. Stephany Bellomo Says:
    As a software developer, I too went down the same yo-yo path in my career from super stuctured software processes (and slow) to wild west (and probably too fast) and landed somewhere in the middle. I actually have a historical timeline slide that shows some of the forces that led to the "artsy era" you mention. I could not agree more with your three things, I just ran out of space (they limited me to 1000 characters). Maybe the next blog I do! I think the domain knowledge is an interesting critical success factor that I had not really thought about talking with respect to Agile. That's not often mentioned as an Agile critical success factor, but I would definately agree it is key to software success no matter what the method. Very helpful. Thanks for the input!
  3. Rich McCabe Says:
    I have seen this sort of thesis put forth elsewhere on various occasions and have never found it very compelling. What are you saying? That a non-agile process can be just as successful as an agile process while employing developers with less skill and discipline? Is this really your point?
    I didn't think the CMMI endorsed that view, although there seems to be a number of managers that take that view. One said to me "I need CMMI processes because I have no control of who I get for a project. I need to have a process that let's me plug in mediocre developers and still succeed."
    I grant that developers who succeed in an agile approach differ in their mindset and tend to emphasize different skills, but I am extremely skeptical of any assertion that agile development demands "higher than average quality" developers to succeed. Unless you want to argue that the "average developer" (whatever that means) is insufficient for success on *any* project.
  4. Stephany Bellomo Says:
    I can see how you could take that away from what I wrote, but that's definately not what I meant. Let me try and explain myself better. I was really talking about having a core set of skills across a team and less about the individual developer skill level. The point I am trying to make is that across a team using incremental rapid application lifecycle, I believe it improves the probablity of success if the team is really good at a few things - in other words, can almost do them with their eyes closed. Take configuration management (CM), for example. In a 4 to 6 week sprint cycle, the team needs (somebody on the team at least) to be able to branch, merge and manage concurrent baselines pretty well. I know that probably sounds like the a basic CM requirement for any software team, but in some government environments I go into a configuration management tool isn't used to manage sometimes millions of lines of source code and, even worse, I get a quizzical look when I ask where the configuration manager is (sometimes I get pointed to a documentation specialist). I guess you could argue AND non-agile projects should have this capablity. I won't argue with you there! On the other hand, having been a developer for on a project for three years that released every 4 weeks I can tell you that we lived or died by our ability to roll back and do complex merges. Not only did we need to be good at CM, we needed to be great at it...and we learned that the hard way believe me! Whether a project takes a junior developer and mentors them on the skills needed on the project or whether the plan is to hire in or build the core skills person by person, I leave that choice to the project. I guess the bottom line is that I get a knot in my stomach when I think about being a developer or software project manager for a project considering moving to a very rapid release cycle (external release cycle) without knowing the team has, or will develop, a core set very solid skills in a few areas like requirements management (e.g., rapid prioritization of requirements), CM, project planning (e.g., epic planning), rapid architectural analysis and testing with automated test tools.

Add Comment

Leave this field empty: