Over the past few years, organizations have not only adopted agile to improve their software development process, they have also adapted themselves to fit the essentials of agile. New attitudes have transformed individual contributors into team players. Work environments have changed, with some teams moving out of separate offices into a more open working environment.

These changes, however, can also be difficult to implement and often expose problems within an organization. In May 2010, we reached out to Forrester’s Application Development & Delivery Community to ask members about their experiences in adopting agile. While there are many potential hurdles, community members consistently brought up challenges related to three categories: Business’ lack of understanding leading to resistance to change; IT’s uncertainty leading to confusion regarding how functions integrate; and agile not being one-size-fits-all.

But all is not lost: Effective communication and customization of agile to your environment will make your adoption more successful. Core to the emphasis on business value, the concept of building an organization, software and processes that adapt to change is fundamental to agile. Forrester offers the following advice to help application development pros overcome the hurdles to effective agile adoption through the use ongoing communication and adaptation.

Educate the business early and often
Adopting agile is obviously a significant change for development organizations, but many members pointed out that they are facing some resistance from the business side too, ranging from a lack of knowledge of the basic concepts of agile and iterative development to more deeply rooted issues from a fear of organizational change. Particularly at an organizational level (rather than at a team level), overcoming business resistance requires application development organizations to make a concerted effort to sit down with and educate upper and middle management.

On the first day with business partners, introduce agile concepts and the general cadence of an agile project. Highlight the fact that agile is not the end goal, but instead is for delivering business value, faster and of a higher quality.

After the first iteration, continue to add to the basics with additional techniques such as test-driven development, and continuous integration and build. Education is often a two-way street, with the end goal of building a collective understanding of the agile process.

When organizations look to agile, they tend to focus significantly on application development and the business—and rightly so. However, the relationship with the business is not the only thing that changes.

As an application development shop adopts new methodologies, it also changes the way it works with the rest of IT. To help your IT organization adjust to these changes, you need to first define the interdependencies. Ask your team: “How do you project managers need to adjust? How do you ensure that your projects still fit within your project governance? Do you need to automate product deployments on the infrastructure side?”

Once you know how everyone will work together, it’s time to get the word out. Publish an agile approach that all IT people can use to understand how agile affects them. Ideally, business leadership will reference this as the guide that describes the principles of agile adoption. Consider using a living and breathing document, such as a wiki, that encourages change and evolution.

Move to agile, but be ready to adapt
Many development pros believe that all organizations adopt agile in the same way—that it is a simple checklist. But agile adoption doesn’t happen in a vacuum, and not every aspect of agile will work for your organization. The goal is not about adopting as many characteristics of agile as possible; it is about improving cycle times, producing higher-quality software, and delivering more value to happier clients, and agile is a tool to achieve these goals. Some shops, for instance, find that they need to be more flexible with resources than a standard agile shop would be. The key is to walk the line between being agile and managing the realities of the organization.

Consider documentation: If you are developing software in a highly regulated industry, a simple story must be augmented with more-detailed specifications that should be written in parallel with development. But many agile purists would argue that this is not agile because the regulations are wrong within an agile process.

Right and wrong are immaterial to the larger idea of doing what is best for your environment. The real question is, “Are you delivering software that your customer loves, and is that process getting faster?”

Dave West is a principal analyst at Forrester Research, and a leading expert on software development process, agile development and project management.