Today’s fast-paced business environment requires an organization’s development process to be flexible and adaptable to changing needs. So increasingly more companies are using “Agile” methodologies in their projects to reduce risk and deliver value to the business early. In so doing, values are overlooked often and mistakes are made.

The needs of the average business will change by 35 percent during the software development process, according to Simon Townsend, director of consulting at Valtech. As such, months’ of work often becomes redundant. In today’s fast-paced business environment, an organization’s development process must be flexible and adaptable to changing needs.

Software development has traditionally taken a mass-engineering approach, following a specific blueprint to build the same design repeatedly. Yet uncharted territory requires a different process. With software development, the traditional approach of defining the requirements, building and integrating the software, and testing the system leaves no room for change. So software systems, in being flexible, should be built using processes that embrace change, Townsend recently wrote for CRN (via VNUnet).

Recent surveys show that use of Agile methodologies is growing. For instance, enterprise project and lifecycle management solutions provider VersionOne Software recently conducted and offered its “State of Agile Development” Survey Results, co-sponsored by The Agile Alliance. The survey indicates that the key reason people are adopting Agile is twofold: managing changing requirements and priorities, and accelerating time-to-market.

Many agree that adoption of Agile methods in general is on the increase, and not only in number of instances of adoption but in terms of scale, too. In March Scott Ambler, the Practice Leader Agile Development with the IBM Methods group, got real-world feedback from 4,232 respondents on their Agile process implementations. Ambler’s respondents reported that:

• Sixty-five (65) percent work in organizations that have adopted one or more agile development techniques,
• Forty-one (41) percent work in organizations that have adopted one or more agile methodologies,
• Sixty (60) percent report increased productivity,
• Sixty-six (66) percent report increased quality,
• Fifty-eight (58) percent report improved stakeholder satisfaction.

There is a down side, however, according to InfoQ.com:

Agile also risks what one practitioner calls “dying the death of a thousand copies,” if teams copy practices rather than growing them, implementing what worked elsewhere without understanding how to use continuous improvement to make the process suitable for their own unique context.

Agile teams ideally must learn Agile practices and Agile values together, to make their process their own and really excel. The Agile Manifesto consists of four values supplemented by 12 principles. These are not suggestions: they define Agile software development, just as the Java api defines the behaviors of application servers that implement it. The methodologies are simply different implementations, interpretations, so one would expect them to evolve and improve over time.

The four Agile values are as follows:

• Individuals and interactions over processes and tools;
• Working software over comprehensive documentation;
• Customer collaboration over contract negotiation; and
• Responding to change over following a plan.

While agile software development may seem straightforward at first, the transition period can be particularly challenging, writes Levent Gurses, a technology consultant and cofounder of Jacoozi, at Dr. Dobb’s Portal. In recently exploring the 10 most common mistakes in the transition from legacy development methodologies to agile, Gurses noted that, “In this transition, many companies face unique challenges and make mistakes.”

Such mistakes include failing to define roles, poor planning and analysis, ignoring the corporate culture, impatience and going all in.

Moreover, making Agile the new religion — evangelizing this “new” way of doing things at every chance and making sure to promise great things — is another notable mistake. As with Lean and Six Sigma and every other methodology, the time comes when someone asks for all the promises; that alone is a great opportunity to lose personal credibility and faith in the process. Further, this is a good way to make Agile the scapegoat of a failed project or failed leadership, Gurses points out.

All said, taking the plunge to use agile methodologies for new system development is not a simple step to take. It requires a significant change in the mind of the user. One thing to remember, Gurses writes, is that “while books and articles can teach a lot, a little up-front analysis and constant real-time monitoring are key factors in every agile transition.”