agile

There continues to be a lot of debate on whether Agile is mainstream. According to a Forrester report published in early 2010, while widespread “Agile” use of the iterative software development processes is found, " teams are not adopting scrum, extreme programming, or another specific Agile approach, but are embracing agile as an ethos or philosophy and cherry-picking the best bits from many different process models to develop a formula unique to their own situation." However, the largest category in the survey – and the one that is the most telling is that 30.6% of the respondents said they do not use a formal process methodology. Add to this my own experience implementing Agile, reading the latest Agile literature (e.g., articles, research, books, etc.), and discussing Agile (and Agile implementations) with people across numerous companies in North America, Europe, and Asia, and what this indicates to me is that:

As compared to other development methods, agile is clear, straightforward, and rewarding for all of those who are involved in the process. Most of you know this already—that’s why you’re here! Clearly, a successful transition to agile requires a strong organizational commitment and a number of management and development changes. With that in mind, the white-hot movement to this trend over the past year continues to amaze me. In striking parallel, the industry has seen this same sort of resonance around the trend to the “cloud”—secure anywhere access by distributed teams to a centralized set of services and compute resources that span the complete lifecycle of the development and deployment process.

If Agile is going to make a difference to an organization, it must accomplish two things. First, it must assist us in being driven by business needs—not the development organization. Second, it must help us with the entire value stream—not merely part of it. Lean-agile practices presents us with an opportunity to reunite the business and software development organizations so our Application Lifecycle Management (ALM) can focus on value, not merely delivered software.

The components of software processes work together in important and sometimes unrecognized ways. The removal of one of those components will affect the others. In this article, which originally appeared in the August 2010 issue of the Iterations eNewsletter, Jennitta Andrea takes a look at the value of acceptance test-driven development and the costs of making it an optional practice.