This 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
http://saturnnetwork.wordpress.com/category/architecture-and-agile/