The Agile Difference for SCM

 we describe what we believe are the root causes of some key differences between agile and traditional development, and how they change certain assumptions SCM has about software development.

Should I be Worried about Agile Development?

Agile development practices can significantly impact software development practices. Of course, any significant process change is ultimately a change in the organization’s culture. And underlying any cultural change is a set of values and beliefs that define and sustain the change in behaviors and mindsets. How will such changes affect us as SCM professionals?

• Should SCM professionals be worried about agile projects running out of control?
• Should agile teams be worried about SCM cramping their style and entangling them in red tape?

Our answer is hopefully reassuring to both camps! Agile software advocates push for lean, people-oriented, adaptable development processes. At an XP conference in London recently, one of us met both the wild enthusiasts fired up with XP fervor, and the more cautious people trying to find out what it was all about and take back some useful ideas.

This represents the real world: although there are increasing numbers of "pure" agile projects out there, there are a much larger number of projects and organizations which are taking agile practices and looking to introduce them to their current development processes. Some opt for a revolutionary approach to introduce agility into the workplace. However more and more are finding that an evolutionary approach to adopting methods from the agile camp is what is going to have the widest applicability and success.

Agile Software Development - What’s the Big Deal?

Led by the popularity and success of eXtreme Programming (XP), and espoused by the same respected experts who introduced software designers to patterns, agile methods like XP, Scrum, and FDD have gained increasing popularity and notoriety! Agile methods emphasize people, and a "lean" approach to process and documentation. James Highsmith writes:

Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.

Responding quickly and effectively to change is easiest to do when we can minimize the following:

• the cost of high fidelity knowledge-transfer between individuals

• the amount of knowledge that must be captured in intermediate artifacts
• the duration of time between making a project decision, and exploring its results to learn the consequences of implementing that decision (feedback & learning latency period)

So achieving agility hinges upon reducing the time and cost of effective communication and learning (and, ultimately, the creation, transfer, and codification of executable knowledge) .

Agile Development Characteristics

On the surface, most agile development practices are not new (iterative development, pair-programming, refactoring, test-driven development, and others have all been around in some form or another for at least a couple decades). Referring again to Highsmith:

What is new about agile methods is not the practices they use, but their recognition of people as the primary drivers of project success, coupled with an intense focus on effectiveness and maneuverability.

For this reason, agile methods focus upon the strengths of people and teams more than they do upon rigorous processes or detailed documentation. Projects employing the methods founded upon these "agile" principles and values share the following key characteristics:

• Adaptive - plans, designs, and processes are regularly tuned and adjusted to adapt to changing needs and requirements (as opposed to being predictive)
  
• Goal-driven - focus on producing end-results (tangible working functionality) in order of highest business value/priority. "Agile approaches plan features, not tasks, as their first priority because features are what customers understand."

• Iterative - short development cycles, frequent releases, regular